date:20180226

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/21543/
Java: 32bit/jdk1.8.0_162 -server -XX:+UseG1GC

8 tests failed.
FAILED:  junit.framework.TestSuite.org.apache.solr.cloud.SSLMigrationTest

Error Message:
ObjectTracker found 2 object(s) that were not released!!! [InternalHttpClient, 
InternalHttpClient] 
org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: 
org.apache.http.impl.client.InternalHttpClient  at 
org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42)
  at 
org.apache.solr.client.solrj.impl.HttpClientUtil.createClient(HttpClientUtil.java:289)
  at 
org.apache.solr.client.solrj.impl.HttpClientUtil.createClient(HttpClientUtil.java:298)
  at 
org.apache.solr.client.solrj.impl.HttpClientUtil.createClient(HttpClientUtil.java:236)
  at 
org.apache.solr.client.solrj.impl.HttpClientUtil.createClient(HttpClientUtil.java:223)
  at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.constructClient(LBHttpSolrClient.java:292)
  at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.(LBHttpSolrClient.java:270)
  at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient$Builder.build(LBHttpSolrClient.java:967)
  at 
org.apache.solr.SolrTestCaseJ4.getLBHttpSolrClient(SolrTestCaseJ4.java:2473)  
at 
org.apache.solr.cloud.SSLMigrationTest.setUrlScheme(SSLMigrationTest.java:132)  
at 
org.apache.solr.cloud.SSLMigrationTest.testMigrateSSL(SSLMigrationTest.java:66) 
 at org.apache.solr.cloud.SSLMigrationTest.test(SSLMigrationTest.java:61)  at 
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)  at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)  
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
  at java.lang.reflect.Method.invoke(Method.java:498)  at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
  at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
  at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
  at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
  at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:993)
  at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:968)
  at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
  at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
  at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
  at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
  at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
  at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
  at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
  at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
  at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
  at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
  at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943)
  at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
  at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
  at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
  at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
  at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
  at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
  at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
  at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
  at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
  at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
  at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
  at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
  at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
  at

[jira] [Commented] (SOLR-11500) MOVEREPLICA api missing in V2

2018-02-26 Thread Shalin Shekhar Mangar (JIRA)


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

Shalin Shekhar Mangar commented on SOLR-11500:
--

Yes, let's add it to CHANGES.txt under the 7.2 section

> MOVEREPLICA api missing in V2
> -
>
> Key: SOLR-11500
> URL: https://issues.apache.org/jira/browse/SOLR-11500
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Trivial
> Fix For: 7.2
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[JENKINS] Lucene-Solr-SmokeRelease-7.x - Build # 159 - Still Failing

Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-7.x/159/

No tests ran.

Build Log:
[...truncated 28782 lines...]
prepare-release-no-sign:
[mkdir] Created dir: 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/lucene/build/smokeTestRelease/dist
 [copy] Copying 491 files to 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/lucene/build/smokeTestRelease/dist/lucene
 [copy] Copying 215 files to 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/lucene/build/smokeTestRelease/dist/solr
   [smoker] Java 1.8 JAVA_HOME=/home/jenkins/tools/java/latest1.8
   [smoker] Java 9 JAVA_HOME=/home/jenkins/tools/java/latest1.9
   [smoker] NOTE: output encoding is UTF-8
   [smoker] 
   [smoker] Load release URL 
"file:/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/lucene/build/smokeTestRelease/dist/"...
   [smoker] 
   [smoker] Test Lucene...
   [smoker]   test basics...
   [smoker]   get KEYS
   [smoker] 0.2 MB in 0.01 sec (38.9 MB/sec)
   [smoker]   check changes HTML...
   [smoker]   download lucene-7.3.0-src.tgz...
   [smoker] 31.7 MB in 0.03 sec (1214.7 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download lucene-7.3.0.tgz...
   [smoker] 73.2 MB in 0.07 sec (1043.8 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download lucene-7.3.0.zip...
   [smoker] 83.8 MB in 0.08 sec (1065.5 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   unpack lucene-7.3.0.tgz...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] test demo with 1.8...
   [smoker]   got 6290 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] test demo with 9...
   [smoker]   got 6290 hits for query "lucene"
   [smoker] checkindex with 9...
   [smoker] check Lucene's javadoc JAR
   [smoker]   unpack lucene-7.3.0.zip...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] test demo with 1.8...
   [smoker]   got 6290 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] test demo with 9...
   [smoker]   got 6290 hits for query "lucene"
   [smoker] checkindex with 9...
   [smoker] check Lucene's javadoc JAR
   [smoker]   unpack lucene-7.3.0-src.tgz...
   [smoker] make sure no JARs/WARs in src dist...
   [smoker] run "ant validate"
   [smoker] run tests w/ Java 8 and testArgs='-Dtests.slow=false'...
   [smoker] test demo with 1.8...
   [smoker]   got 217 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] generate javadocs w/ Java 8...
   [smoker] 
   [smoker] Crawl/parse...
   [smoker] 
   [smoker] Verify...
   [smoker] run tests w/ Java 9 and testArgs='-Dtests.slow=false'...
   [smoker] test demo with 9...
   [smoker]   got 217 hits for query "lucene"
   [smoker] checkindex with 9...
   [smoker]   confirm all releases have coverage in TestBackwardsCompatibility
   [smoker] find all past Lucene releases...
   [smoker] run TestBackwardsCompatibility..
   [smoker] success!
   [smoker] 
   [smoker] Test Solr...
   [smoker]   test basics...
   [smoker]   get KEYS
   [smoker] 0.2 MB in 0.00 sec (246.8 MB/sec)
   [smoker]   check changes HTML...
   [smoker]   download solr-7.3.0-src.tgz...
   [smoker] 54.1 MB in 0.06 sec (917.6 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download solr-7.3.0.tgz...
   [smoker] 151.0 MB in 0.17 sec (867.5 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download solr-7.3.0.zip...
   [smoker] 152.0 MB in 0.17 sec (903.3 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   unpack solr-7.3.0.tgz...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] unpack lucene-7.3.0.tgz...
   [smoker]   **WARNING**: skipping check of 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/lucene/build/smokeTestRelease/tmp/unpack/solr-7.3.0/contrib/dataimporthandler-extras/lib/javax.mail-1.5.1.jar:
 it has javax.* classes
   [smoker]   **WARNING**: skipping check of 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/lucene/build/smokeTestRelease/tmp/unpack/solr-7.3.0/contrib/dataimporthandler-extras/lib/activation-1.1.1.jar:
 it has javax.* classes
   [smoker] copying unpacked distribution for Java 8 ...
   [smoker] test solr example w/ Java 8...
   [smoker]   start Solr instance 
(log=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/lucene/build/smokeTestRelease/tmp/unpack/solr-7.3.0-java8/solr-example.log)...
   [smoker] No process found for Solr node running on port 8983
   [smoker]   Running techproducts example on port 8983 from 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/lucene/build/smokeTestRelease/tmp/unpack/solr-7.3.0-java8
   [smoker] *** [WARN] *** Your open file

[jira] [Resolved] (SOLR-10858) Make UUIDUpdateProcessorFactory as Runtime URP; take params(s) with request


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

Noble Paul resolved SOLR-10858.
---
   Resolution: Fixed
Fix Version/s: (was: 7.3)
   (was: master (8.0))
   7.0

> Make UUIDUpdateProcessorFactory as Runtime URP; take params(s) with request
> ---
>
> Key: SOLR-10858
> URL: https://issues.apache.org/jira/browse/SOLR-10858
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: update
>Reporter: Amrit Sarkar
>Assignee: Noble Paul
>Priority: Minor
> Fix For: 7.0
>
> Attachments: SOLR-10858.patch, SOLR-10858.patch, SOLR-10858.patch, 
> SOLR-10858.patch, SOLR-10858.patch, SOLR-10858.patch, SOLR-10858.patch, 
> SOLR-10858.patch
>
>
> We are trying to get rid of processor definitions in SolrConfig for all URPs 
> and take parameters in the request itself.
> UUIDUpdateProcessorFactory will be able to execute by sample curl like below:
> {code}
>  curl -X POST -H Content-Type: application/json  
> http://localhost:8983/solr/test/update/json/docs?processor=uuid=id=true
>  --data-binary {"title": "titleA"}
> {code}
> {code}
>  curl -X POST -H Content-Type: application/json  
> http://localhost:8983/solr/test/update/json/docs?processor=uuid=true 
> --data-binary {"id":"1","title": "titleA"}
> {code}
> {code}
>  curl -X POST -H Content-Type: application/json  
> http://localhost:8983/solr/test/update/json/docs?processor=uuid=id=true
>  --data-binary {"id":"1","title": "titleA"}
> {code}
> Configuration for UUIDUpdateProcessorFactory in solrconfig.xml is optional.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Resolved] (SOLR-10876) Regression in loading runtime UpdateRequestProcessors


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

Noble Paul resolved SOLR-10876.
---
   Resolution: Fixed
Fix Version/s: 7.0

> Regression in loading runtime UpdateRequestProcessors
> -
>
> Key: SOLR-10876
> URL: https://issues.apache.org/jira/browse/SOLR-10876
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 6.6
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
> Fix For: 7.0
>
> Attachments: SOLR-10876.patch
>
>
> This was introduced as a part of SOLR-9530



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Resolved] (SOLR-10954) Refactor code to standardize replica assignment


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

Noble Paul resolved SOLR-10954.
---
   Resolution: Fixed
Fix Version/s: 7.2

> Refactor code to standardize replica assignment
> ---
>
> Key: SOLR-10954
> URL: https://issues.apache.org/jira/browse/SOLR-10954
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Noble Paul
>Priority: Major
> Fix For: 7.2
>
>
> Today, we have different mechanisms to assign replicas to nodes
> # the default
> # rules based replica placement
> # policy based replica placement
> different commands such as add-replica, add shard, create collection etc uses 
> different code paths to assign replicas to nodes. it should be refactored to 
> unify all this into a single method, if possible



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Resolved] (SOLR-11062) Add support for spins metric in Policy


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

Noble Paul resolved SOLR-11062.
---
Resolution: Fixed

> Add support for spins metric in Policy
> --
>
> Key: SOLR-11062
> URL: https://issues.apache.org/jira/browse/SOLR-11062
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: AutoScaling, metrics
>Reporter: Shalin Shekhar Mangar
>Assignee: Noble Paul
>Priority: Major
> Fix For: master (8.0), 7.3
>
>
> SOLR-11061 exposes the spin metrics. This issue is to support this metric in 
> the Policy clauses.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Created] (SOLR-12038) SPLITSHARD should check disk space before performing the operation

Noble Paul created SOLR-12038:
-

 Summary: SPLITSHARD should check disk space before performing the 
operation
 Key: SOLR-12038
 URL: https://issues.apache.org/jira/browse/SOLR-12038
 Project: Solr
  Issue Type: Sub-task
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Noble Paul


SPLITSHARD should first check if it has enough space to do the split before it 
accepts the operation



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Resolved] (SOLR-11064) Collection APIs should provide disk space hint to Policy when possible


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

Noble Paul resolved SOLR-11064.
---
Resolution: Fixed

> Collection APIs should provide disk space hint to Policy when possible
> --
>
> Key: SOLR-11064
> URL: https://issues.apache.org/jira/browse/SOLR-11064
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: AutoScaling, SolrCloud
>Reporter: Shalin Shekhar Mangar
>Assignee: Noble Paul
>Priority: Major
> Fix For: master (8.0), 7.3
>
>
> SOLR-11063 added disk space hint to Policy. The ADDREPLICA, MOVEREPLICA, 
> SPLITSHARD and REPLACENODE APIs can provide this hint.
>  # ADDREPLICA can query the size of the leader's data direcoty for the same 
> shard and pass it to policy
>  # MOVEREPLICA again knows the size of the replica being moved
>  # REPLACENODE can compute the sum of disk usage of all the replicas' data 
> directories
> We should probably include both index and tlog size in the hint to ensure 
> that we have ample space on target nodes.
> We should also take care of HDFS because for movereplica and replacenode, 
> there are no disk space requirements because the original replica's HDFS data 
> and ulog directories are used by the new replicas.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (SOLR-11064) Collection APIs should provide disk space hint to Policy when possible


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

Noble Paul commented on SOLR-11064:
---

SPLITSHARD should handle this in a new ticket

> Collection APIs should provide disk space hint to Policy when possible
> --
>
> Key: SOLR-11064
> URL: https://issues.apache.org/jira/browse/SOLR-11064
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: AutoScaling, SolrCloud
>Reporter: Shalin Shekhar Mangar
>Assignee: Noble Paul
>Priority: Major
> Fix For: master (8.0), 7.3
>
>
> SOLR-11063 added disk space hint to Policy. The ADDREPLICA, MOVEREPLICA, 
> SPLITSHARD and REPLACENODE APIs can provide this hint.
>  # ADDREPLICA can query the size of the leader's data direcoty for the same 
> shard and pass it to policy
>  # MOVEREPLICA again knows the size of the replica being moved
>  # REPLACENODE can compute the sum of disk usage of all the replicas' data 
> directories
> We should probably include both index and tlog size in the hint to ensure 
> that we have ample space on target nodes.
> We should also take care of HDFS because for movereplica and replacenode, 
> there are no disk space requirements because the original replica's HDFS data 
> and ulog directories are used by the new replicas.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Updated] (SOLR-11064) Collection APIs should provide disk space hint to Policy when possible


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

Noble Paul updated SOLR-11064:
--
Description: 
SOLR-11063 added disk space hint to Policy. The ADDREPLICA, MOVEREPLICA, 
SPLITSHARD and REPLACENODE APIs can provide this hint.
 # ADDREPLICA can query the size of the leader's data direcoty for the same 
shard and pass it to policy
 # MOVEREPLICA again knows the size of the replica being moved
 # REPLACENODE can compute the sum of disk usage of all the replicas' data 
directories

We should probably include both index and tlog size in the hint to ensure that 
we have ample space on target nodes.

We should also take care of HDFS because for movereplica and replacenode, there 
are no disk space requirements because the original replica's HDFS data and 
ulog directories are used by the new replicas.

  was:
SOLR-11063 added disk space hint to Policy. The ADDREPLICA, MOVEREPLICA, 
SPLITSHARD and REPLACENODE APIs can provide this hint.

# ADDREPLICA can query the size of the leader's data direcoty for the same 
shard and pass it to policy
# MOVEREPLICA again knows the size of the replica being moved
# SPLITSHARD knows the size of the split indexes before it calls addreplica to 
create replicas of the sub-shards
# REPLACENODE can compute the sum of disk usage of all the replicas' data 
directories

We should probably include both index and tlog size in the hint to ensure that 
we have ample space on target nodes.

We should also take care of HDFS because for movereplica and replacenode, there 
are no disk space requirements because the original replica's HDFS data and 
ulog directories are used by the new replicas.


> Collection APIs should provide disk space hint to Policy when possible
> --
>
> Key: SOLR-11064
> URL: https://issues.apache.org/jira/browse/SOLR-11064
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: AutoScaling, SolrCloud
>Reporter: Shalin Shekhar Mangar
>Assignee: Noble Paul
>Priority: Major
> Fix For: master (8.0), 7.3
>
>
> SOLR-11063 added disk space hint to Policy. The ADDREPLICA, MOVEREPLICA, 
> SPLITSHARD and REPLACENODE APIs can provide this hint.
>  # ADDREPLICA can query the size of the leader's data direcoty for the same 
> shard and pass it to policy
>  # MOVEREPLICA again knows the size of the replica being moved
>  # REPLACENODE can compute the sum of disk usage of all the replicas' data 
> directories
> We should probably include both index and tlog size in the hint to ensure 
> that we have ample space on target nodes.
> We should also take care of HDFS because for movereplica and replacenode, 
> there are no disk space requirements because the original replica's HDFS data 
> and ulog directories are used by the new replicas.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Updated] (SOLR-11879) prevent EOFException in FastinputStream


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

Noble Paul updated SOLR-11879:
--
Summary: prevent EOFException in FastinputStream  (was: avoid creating a 
new Exception object for EOFException in FastinputStream)

> prevent EOFException in FastinputStream
> ---
>
> Key: SOLR-11879
> URL: https://issues.apache.org/jira/browse/SOLR-11879
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
> Environment: FastI
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Trivial
> Attachments: SOLR-11879.patch, SOLR-11879.patch, SOLR-11879.patch, 
> Screen Shot 2018-01-24 at 7.26.16 PM.png
>
>
> FastInputStream creates and throws a new EOFException, every time an end of 
> stream is encountered. This is wasteful as we never use the stack trace 
> anywhere 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (SOLR-11500) MOVEREPLICA api missing in V2


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

Noble Paul commented on SOLR-11500:
---

It was fixed in 7.2 . slipped through the cracks and didn't get into 
CHANGES.txt. Is it OK to add it now?

> MOVEREPLICA api missing in V2
> -
>
> Key: SOLR-11500
> URL: https://issues.apache.org/jira/browse/SOLR-11500
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Trivial
> Fix For: 7.2
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Resolved] (SOLR-11500) MOVEREPLICA api missing in V2


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

Noble Paul resolved SOLR-11500.
---
   Resolution: Fixed
Fix Version/s: 7.2

fixed in 7.2

> MOVEREPLICA api missing in V2
> -
>
> Key: SOLR-11500
> URL: https://issues.apache.org/jira/browse/SOLR-11500
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Trivial
> Fix For: 7.2
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Resolved] (SOLR-11648) Create a web UI to display and execute suggestions


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

Noble Paul resolved SOLR-11648.
---
   Resolution: Fixed
Fix Version/s: 7.3

> Create a web UI to display and execute suggestions
> --
>
> Key: SOLR-11648
> URL: https://issues.apache.org/jira/browse/SOLR-11648
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: AutoScaling
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
> Fix For: 7.3
>
> Attachments: no_suggestions.png, screen1.png, screen2.png, 
> screen3.png, screen4.png, sidebar.jpg, suggestions_table.jpg, 
> suggestions_table.jpg
>
>
> Steps to show suggestions
> {code}
> bin/solr start -e cloud
> #give the following inputs for prompts
> This interactive session will help you launch a SolrCloud cluster on your 
> local workstation.
> To begin, how many Solr nodes would you like to run in your local cluster? 
> (specify 1-4 nodes) [2]: 
> 4
> Please provide a name for your new collection: [gettingstarted] 
> mycoll
> How many shards would you like to split mycoll into? [2]
> 4
> How many replicas per shard would you like to create? [2] 
> 2
> #run the following command so that there are violating replicas
> curl http://localhost:8983/api/cluster/autoscaling -H 
> 'Content-type:application/json' -d '{
> "set-cluster-policy": [
>   {"replica": "0", "shard": "#EACH", "port": 7574}
>   ]
> }'
> #hit the suggestions end point at the url
> http://localhost:8983/api/cluster/autoscaling/suggestions
> {code}
> add an entry to the sidebar as follows
> !sidebar.jpg!
> use the output of the suggestions API to map to the table data
> !suggestions_table.jpg!



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Assigned] (SOLR-11440) TestLeaderElectionZkExpiry failures after autoscaling merges


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

Noble Paul reassigned SOLR-11440:
-

Assignee: Noble Paul

> TestLeaderElectionZkExpiry failures after autoscaling merges
> 
>
> Key: SOLR-11440
> URL: https://issues.apache.org/jira/browse/SOLR-11440
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: AutoScaling, Tests
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
> Fix For: 7.1
>
>
> {code}
>  [junit4]   2> NOTE: reproduce with: ant test  
> -Dtestcase=TestLeaderElectionZkExpiry 
> -Dtests.method=testLeaderElectionWithZkExpiry -Dtests.seed=936BBD073C4C1EE2 
> -Dtests.slow=true -Dtests.locale=fi -Dtests.timezone=Africa/Sao_Tome 
> -Dtests.asserts=true -Dtests.file.encoding=ISO-8859-1
>[junit4] ERROR   13.6s J11 | 
> TestLeaderElectionZkExpiry.testLeaderElectionWithZkExpiry <<<
>[junit4]> Throwable #1: 
> com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an 
> uncaught exception in thread: Thread[id=7154, 
> name=OverseerAutoScalingTriggerThread-98770164405436418-dummy.host.com:8984_solr-n_00,
>  state=RUNNABLE, group=Overseer autoscaling triggers]
>[junit4]> Caused by: org.apache.solr.common.SolrException: 
> org.apache.zookeeper.KeeperException$SessionExpiredException: KeeperErrorCode 
> = Session expired for /autoscaling/events/.auto_add_replicas
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([936BBD073C4C1EE2]:0)
>[junit4]>  at 
> org.apache.solr.cloud.ZkDistributedQueue.(ZkDistributedQueue.java:107)
>[junit4]>  at 
> org.apache.solr.cloud.autoscaling.TriggerEventQueue.(TriggerEventQueue.java:44)
>[junit4]>  at 
> org.apache.solr.cloud.autoscaling.ScheduledTriggers$ScheduledTrigger.(ScheduledTriggers.java:398)
>[junit4]>  at 
> org.apache.solr.cloud.autoscaling.ScheduledTriggers.add(ScheduledTriggers.java:149)
>[junit4]>  at 
> org.apache.solr.cloud.autoscaling.OverseerTriggerThread.run(OverseerTriggerThread.java:220)
>[junit4]>  at java.lang.Thread.run(Thread.java:745)
>[junit4]> Caused by: 
> org.apache.zookeeper.KeeperException$SessionExpiredException: KeeperErrorCode 
> = Session expired for /autoscaling/events/.auto_add_replicas
>[junit4]>  at 
> org.apache.zookeeper.KeeperException.create(KeeperException.java:127)
>[junit4]>  at 
> org.apache.zookeeper.KeeperException.create(KeeperException.java:51)
>[junit4]>  at 
> org.apache.zookeeper.ZooKeeper.exists(ZooKeeper.java:1102)
>[junit4]>  at 
> org.apache.solr.common.cloud.SolrZkClient$5.execute(SolrZkClient.java:323)
>[junit4]>  at 
> org.apache.solr.common.cloud.SolrZkClient$5.execute(SolrZkClient.java:320)
>[junit4]>  at 
> org.apache.solr.common.cloud.ZkCmdExecutor.retryOperation(ZkCmdExecutor.java:60)
>[junit4]>  at 
> org.apache.solr.common.cloud.SolrZkClient.exists(SolrZkClient.java:320)
>[junit4]>  at 
> org.apache.solr.common.cloud.ZkCmdExecutor.ensureExists(ZkCmdExecutor.java:93)
>[junit4]>  at 
> org.apache.solr.common.cloud.ZkCmdExecutor.ensureExists(ZkCmdExecutor.java:78)
>[junit4]>  at 
> org.apache.solr.cloud.ZkDistributedQueue.(ZkDistributedQueue.java:105)
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Resolved] (SOLR-11440) TestLeaderElectionZkExpiry failures after autoscaling merges


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

Noble Paul resolved SOLR-11440.
---
   Resolution: Fixed
Fix Version/s: 7.1

It is not failing anymore

> TestLeaderElectionZkExpiry failures after autoscaling merges
> 
>
> Key: SOLR-11440
> URL: https://issues.apache.org/jira/browse/SOLR-11440
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: AutoScaling, Tests
>Reporter: Noble Paul
>Priority: Major
> Fix For: 7.1
>
>
> {code}
>  [junit4]   2> NOTE: reproduce with: ant test  
> -Dtestcase=TestLeaderElectionZkExpiry 
> -Dtests.method=testLeaderElectionWithZkExpiry -Dtests.seed=936BBD073C4C1EE2 
> -Dtests.slow=true -Dtests.locale=fi -Dtests.timezone=Africa/Sao_Tome 
> -Dtests.asserts=true -Dtests.file.encoding=ISO-8859-1
>[junit4] ERROR   13.6s J11 | 
> TestLeaderElectionZkExpiry.testLeaderElectionWithZkExpiry <<<
>[junit4]> Throwable #1: 
> com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an 
> uncaught exception in thread: Thread[id=7154, 
> name=OverseerAutoScalingTriggerThread-98770164405436418-dummy.host.com:8984_solr-n_00,
>  state=RUNNABLE, group=Overseer autoscaling triggers]
>[junit4]> Caused by: org.apache.solr.common.SolrException: 
> org.apache.zookeeper.KeeperException$SessionExpiredException: KeeperErrorCode 
> = Session expired for /autoscaling/events/.auto_add_replicas
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([936BBD073C4C1EE2]:0)
>[junit4]>  at 
> org.apache.solr.cloud.ZkDistributedQueue.(ZkDistributedQueue.java:107)
>[junit4]>  at 
> org.apache.solr.cloud.autoscaling.TriggerEventQueue.(TriggerEventQueue.java:44)
>[junit4]>  at 
> org.apache.solr.cloud.autoscaling.ScheduledTriggers$ScheduledTrigger.(ScheduledTriggers.java:398)
>[junit4]>  at 
> org.apache.solr.cloud.autoscaling.ScheduledTriggers.add(ScheduledTriggers.java:149)
>[junit4]>  at 
> org.apache.solr.cloud.autoscaling.OverseerTriggerThread.run(OverseerTriggerThread.java:220)
>[junit4]>  at java.lang.Thread.run(Thread.java:745)
>[junit4]> Caused by: 
> org.apache.zookeeper.KeeperException$SessionExpiredException: KeeperErrorCode 
> = Session expired for /autoscaling/events/.auto_add_replicas
>[junit4]>  at 
> org.apache.zookeeper.KeeperException.create(KeeperException.java:127)
>[junit4]>  at 
> org.apache.zookeeper.KeeperException.create(KeeperException.java:51)
>[junit4]>  at 
> org.apache.zookeeper.ZooKeeper.exists(ZooKeeper.java:1102)
>[junit4]>  at 
> org.apache.solr.common.cloud.SolrZkClient$5.execute(SolrZkClient.java:323)
>[junit4]>  at 
> org.apache.solr.common.cloud.SolrZkClient$5.execute(SolrZkClient.java:320)
>[junit4]>  at 
> org.apache.solr.common.cloud.ZkCmdExecutor.retryOperation(ZkCmdExecutor.java:60)
>[junit4]>  at 
> org.apache.solr.common.cloud.SolrZkClient.exists(SolrZkClient.java:320)
>[junit4]>  at 
> org.apache.solr.common.cloud.ZkCmdExecutor.ensureExists(ZkCmdExecutor.java:93)
>[junit4]>  at 
> org.apache.solr.common.cloud.ZkCmdExecutor.ensureExists(ZkCmdExecutor.java:78)
>[junit4]>  at 
> org.apache.solr.cloud.ZkDistributedQueue.(ZkDistributedQueue.java:105)
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[JENKINS] Lucene-Solr-7.x-Linux (64bit/jdk1.8.0_162) - Build # 1437 - Failure!

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

No tests ran.

Build Log:
[...truncated 62601 lines...]
[repro] Jenkins log URL: 
https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/1437/consoleText

[repro] Revision: d5f670cd95d1947dca2522bcb3370afa72750aa5

[repro] Ant options: "-Dargs=-XX:+UseCompressedOops -XX:+UseParallelGC"
[repro] No "reproduce with" lines found; exiting.

[...truncated 8 lines...]
ERROR: Step ‘Publish JUnit test result report’ failed: No test report files 
were found. Configuration error?
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any
Setting 
ANT_1_8_2_HOME=/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Setting 
ANT_1_8_2_HOME=/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Setting 
ANT_1_8_2_HOME=/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Setting 
ANT_1_8_2_HOME=/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2

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

[jira] [Commented] (SOLR-12028) BadApple and AwaitsFix annotations usage

2018-02-26 Thread ASF subversion and git services (JIRA)


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

Erick Erickson commented on SOLR-12028:
---

OK, we'll see how this goes. I'm going to leave this JIRA open for the nonce, 
once tests are settled I'll close it and we can move on.

> BadApple and AwaitsFix annotations usage
> 
>
> Key: SOLR-12028
> URL: https://issues.apache.org/jira/browse/SOLR-12028
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Tests
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Major
> Attachments: SOLR-12016-buildsystem.patch, SOLR-12028.patch, 
> SOLR-12028.patch
>
>
> There's a long discussion of this topic at SOLR-12016. Here's a summary:
> - BadApple annotations are used for tests that intermittently fail, say < 30% 
> of the time. Tests that fail more often shold be moved to AwaitsFix. This is, 
> of course, a judgement call
> - AwaitsFix annotations are used for tests that, for some reason, the problem 
> can't be fixed immediately. Likely reasons are third-party dependencies, 
> extreme difficulty tracking down, dependency on another JIRA etc.
> Jenkins jobs will typically run with BadApple disabled to cut down on noise. 
> Periodically Jenkins jobs will be run with BadApples enabled so BadApple 
> tests won't be lost and reports can be generated. Tests that run with 
> BadApples disabled that fail require _immediate_ attention.
> The default for developers is that BadApple is enabled.
> If you are working on one of these tests and cannot get the test to fail 
> locally, it is perfectly acceptable to comment the annotation out. You should 
> let the dev list know that this is deliberate.
> This JIRA is a placeholder for BadApple tests to point to between the times 
> they're identified as BadApple and they're either fixed or changed to 
> AwaitsFix or assigned their own JIRA.
> I've assigned this to myself to track so I don't lose track of it. No one 
> person will fix all of these issues, this will be an ongoing technical debt 
> cleanup effort.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (SOLR-12028) BadApple and AwaitsFix annotations usage


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

ASF subversion and git services commented on SOLR-12028:


Commit 7a9b011d3eaaa4088257e5724e12e8d018923c19 in lucene-solr's branch 
refs/heads/branch_7x from Erick Erickson
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=7a9b011 ]

SOLR-12028: BadApple and AwaitsFix annotations usage

(cherry picked from commit 1fe4560)


> BadApple and AwaitsFix annotations usage
> 
>
> Key: SOLR-12028
> URL: https://issues.apache.org/jira/browse/SOLR-12028
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Tests
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Major
> Attachments: SOLR-12016-buildsystem.patch, SOLR-12028.patch, 
> SOLR-12028.patch
>
>
> There's a long discussion of this topic at SOLR-12016. Here's a summary:
> - BadApple annotations are used for tests that intermittently fail, say < 30% 
> of the time. Tests that fail more often shold be moved to AwaitsFix. This is, 
> of course, a judgement call
> - AwaitsFix annotations are used for tests that, for some reason, the problem 
> can't be fixed immediately. Likely reasons are third-party dependencies, 
> extreme difficulty tracking down, dependency on another JIRA etc.
> Jenkins jobs will typically run with BadApple disabled to cut down on noise. 
> Periodically Jenkins jobs will be run with BadApples enabled so BadApple 
> tests won't be lost and reports can be generated. Tests that run with 
> BadApples disabled that fail require _immediate_ attention.
> The default for developers is that BadApple is enabled.
> If you are working on one of these tests and cannot get the test to fail 
> locally, it is perfectly acceptable to comment the annotation out. You should 
> let the dev list know that this is deliberate.
> This JIRA is a placeholder for BadApple tests to point to between the times 
> they're identified as BadApple and they're either fixed or changed to 
> AwaitsFix or assigned their own JIRA.
> I've assigned this to myself to track so I don't lose track of it. No one 
> person will fix all of these issues, this will be an ongoing technical debt 
> cleanup effort.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (SOLR-10136) TestReqParamsAPI regularly fails on Policeman Jenkins

2018-02-26 Thread ASF subversion and git services (JIRA)


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

ASF subversion and git services commented on SOLR-10136:


Commit 3b6307368e16894d58a2b57c8b15674c6239a243 in lucene-solr's branch 
refs/heads/branch_7x from Erick Erickson
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=3b63073 ]

SOLR-12028: BadApple and AwaitsFix annotations usage. Removing of AwaitsFix on 
master never merged into 7x branch, SOLR-10136


> TestReqParamsAPI regularly fails on Policeman Jenkins
> -
>
> Key: SOLR-10136
> URL: https://issues.apache.org/jira/browse/SOLR-10136
> Project: Solr
>  Issue Type: Test
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Christine Poerschke
>Assignee: Noble Paul
>Priority: Major
> Attachments: logs.tar.gz
>
>
> {{org.apache.solr.handler.TestReqParamsAPI.test}} regularly fails though 
> interestly only on Policeman Jenkins and not on Apache Jenkins e.g. 
> https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/18962/testReport/junit/org.apache.solr.handler/TestReqParamsAPI/test/
> The Feb 9th SOLR-10032 report categorised the test as _flakey_.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (SOLR-12028) BadApple and AwaitsFix annotations usage

2018-02-26 Thread ASF subversion and git services (JIRA)


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

ASF subversion and git services commented on SOLR-12028:


Commit 3b6307368e16894d58a2b57c8b15674c6239a243 in lucene-solr's branch 
refs/heads/branch_7x from Erick Erickson
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=3b63073 ]

SOLR-12028: BadApple and AwaitsFix annotations usage. Removing of AwaitsFix on 
master never merged into 7x branch, SOLR-10136


> BadApple and AwaitsFix annotations usage
> 
>
> Key: SOLR-12028
> URL: https://issues.apache.org/jira/browse/SOLR-12028
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Tests
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Major
> Attachments: SOLR-12016-buildsystem.patch, SOLR-12028.patch, 
> SOLR-12028.patch
>
>
> There's a long discussion of this topic at SOLR-12016. Here's a summary:
> - BadApple annotations are used for tests that intermittently fail, say < 30% 
> of the time. Tests that fail more often shold be moved to AwaitsFix. This is, 
> of course, a judgement call
> - AwaitsFix annotations are used for tests that, for some reason, the problem 
> can't be fixed immediately. Likely reasons are third-party dependencies, 
> extreme difficulty tracking down, dependency on another JIRA etc.
> Jenkins jobs will typically run with BadApple disabled to cut down on noise. 
> Periodically Jenkins jobs will be run with BadApples enabled so BadApple 
> tests won't be lost and reports can be generated. Tests that run with 
> BadApples disabled that fail require _immediate_ attention.
> The default for developers is that BadApple is enabled.
> If you are working on one of these tests and cannot get the test to fail 
> locally, it is perfectly acceptable to comment the annotation out. You should 
> let the dev list know that this is deliberate.
> This JIRA is a placeholder for BadApple tests to point to between the times 
> they're identified as BadApple and they're either fixed or changed to 
> AwaitsFix or assigned their own JIRA.
> I've assigned this to myself to track so I don't lose track of it. No one 
> person will fix all of these issues, this will be an ongoing technical debt 
> cleanup effort.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (SOLR-12028) BadApple and AwaitsFix annotations usage

2018-02-26 Thread ASF subversion and git services (JIRA)


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

ASF subversion and git services commented on SOLR-12028:


Commit 1fe45606b91b368b5fcd20e3c86e401ab4f9c6a6 in lucene-solr's branch 
refs/heads/master from Erick Erickson
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=1fe4560 ]

SOLR-12028: BadApple and AwaitsFix annotations usage


> BadApple and AwaitsFix annotations usage
> 
>
> Key: SOLR-12028
> URL: https://issues.apache.org/jira/browse/SOLR-12028
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Tests
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Major
> Attachments: SOLR-12016-buildsystem.patch, SOLR-12028.patch, 
> SOLR-12028.patch
>
>
> There's a long discussion of this topic at SOLR-12016. Here's a summary:
> - BadApple annotations are used for tests that intermittently fail, say < 30% 
> of the time. Tests that fail more often shold be moved to AwaitsFix. This is, 
> of course, a judgement call
> - AwaitsFix annotations are used for tests that, for some reason, the problem 
> can't be fixed immediately. Likely reasons are third-party dependencies, 
> extreme difficulty tracking down, dependency on another JIRA etc.
> Jenkins jobs will typically run with BadApple disabled to cut down on noise. 
> Periodically Jenkins jobs will be run with BadApples enabled so BadApple 
> tests won't be lost and reports can be generated. Tests that run with 
> BadApples disabled that fail require _immediate_ attention.
> The default for developers is that BadApple is enabled.
> If you are working on one of these tests and cannot get the test to fail 
> locally, it is perfectly acceptable to comment the annotation out. You should 
> let the dev list know that this is deliberate.
> This JIRA is a placeholder for BadApple tests to point to between the times 
> they're identified as BadApple and they're either fixed or changed to 
> AwaitsFix or assigned their own JIRA.
> I've assigned this to myself to track so I don't lose track of it. No one 
> person will fix all of these issues, this will be an ongoing technical debt 
> cleanup effort.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Updated] (SOLR-12028) BadApple and AwaitsFix annotations usage


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

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

> BadApple and AwaitsFix annotations usage
> 
>
> Key: SOLR-12028
> URL: https://issues.apache.org/jira/browse/SOLR-12028
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Tests
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Major
> Attachments: SOLR-12016-buildsystem.patch, SOLR-12028.patch, 
> SOLR-12028.patch
>
>
> There's a long discussion of this topic at SOLR-12016. Here's a summary:
> - BadApple annotations are used for tests that intermittently fail, say < 30% 
> of the time. Tests that fail more often shold be moved to AwaitsFix. This is, 
> of course, a judgement call
> - AwaitsFix annotations are used for tests that, for some reason, the problem 
> can't be fixed immediately. Likely reasons are third-party dependencies, 
> extreme difficulty tracking down, dependency on another JIRA etc.
> Jenkins jobs will typically run with BadApple disabled to cut down on noise. 
> Periodically Jenkins jobs will be run with BadApples enabled so BadApple 
> tests won't be lost and reports can be generated. Tests that run with 
> BadApples disabled that fail require _immediate_ attention.
> The default for developers is that BadApple is enabled.
> If you are working on one of these tests and cannot get the test to fail 
> locally, it is perfectly acceptable to comment the annotation out. You should 
> let the dev list know that this is deliberate.
> This JIRA is a placeholder for BadApple tests to point to between the times 
> they're identified as BadApple and they're either fixed or changed to 
> AwaitsFix or assigned their own JIRA.
> I've assigned this to myself to track so I don't lose track of it. No one 
> person will fix all of these issues, this will be an ongoing technical debt 
> cleanup effort.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[JENKINS] Lucene-Solr-master-Linux (32bit/jdk1.8.0_162) - Build # 21542 - Still unstable!

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/21542/
Java: 32bit/jdk1.8.0_162 -server -XX:+UseG1GC

1 tests failed.
FAILED:  org.apache.solr.cloud.TestSegmentSorting.testSegmentTerminateEarly

Error Message:
expected: but was:

Stack Trace:
java.lang.AssertionError: expected: but was:
at 
__randomizedtesting.SeedInfo.seed([6137223F699FA748:B191E592B5CD3322]: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:147)
at 
org.apache.solr.cloud.TestSegmentSorting.createCollection(TestSegmentSorting.java:84)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:968)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:47)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:748)




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

[JENKINS] Lucene-Solr-Tests-master - Build # 2384 - Still Unstable

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

1 tests failed.
FAILED:  org.apache.solr.cloud.TestAuthenticationFramework.testBasics

Error Message:
Error from server at 
http://127.0.0.1:48364/solr/testcollection_shard1_replica_n3: Expected mime 
type application/octet-stream but got text/html.Error 404 
Can not find: /solr/testcollection_shard1_replica_n3/update  
HTTP ERROR 404 Problem accessing 
/solr/testcollection_shard1_replica_n3/update. Reason: Can not find: 
/solr/testcollection_shard1_replica_n3/updatehttp://eclipse.org/jetty;>Powered by Jetty:// 9.4.8.v20171121  
  

Stack Trace:
org.apache.solr.client.solrj.impl.CloudSolrClient$RouteException: Error from 
server at http://127.0.0.1:48364/solr/testcollection_shard1_replica_n3: 
Expected mime type application/octet-stream but got text/html. 


Error 404 Can not find: 
/solr/testcollection_shard1_replica_n3/update

HTTP ERROR 404
Problem accessing /solr/testcollection_shard1_replica_n3/update. Reason:
Can not find: 
/solr/testcollection_shard1_replica_n3/updatehttp://eclipse.org/jetty;>Powered by Jetty:// 9.4.8.v20171121




at 
__randomizedtesting.SeedInfo.seed([84CD21EF15133D38:B9158FC32DFD6348]:0)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:550)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1013)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:884)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:946)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:946)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:946)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:946)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:946)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:817)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:194)
at 
org.apache.solr.client.solrj.request.UpdateRequest.commit(UpdateRequest.java:233)
at 
org.apache.solr.cloud.TestAuthenticationFramework.collectionCreateSearchDeleteTwice(TestAuthenticationFramework.java:126)
at 
org.apache.solr.cloud.TestAuthenticationFramework.testBasics(TestAuthenticationFramework.java:74)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at

[jira] [Commented] (SOLR-12037) Reduce noise from flakey tests

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

Erick Erickson commented on SOLR-12037:
---

Rolling up comments from deleted SOLR-2016:

I'll mash all the comments together rather than have a bunch of individual
comments from SOLR-2016, they're in the original order:

Erick Erickson:
These are JIRAs linked to by current BadApple and AwaitsFix annotations.

-
Robert Muir:
I don't think the lucene tests marked with AwaitsFix belong here at all. Please
don't remove the annotations for these. They are simply tests that fail due to
known open bugs in jira. They aren't flaky at all.**

Yonik Seeley:
Also, I expect to add the annotation to some more tests for a few days as
infrequent failures occur.
Per the email discussion, this should happen after the default for "ant test"
is changed (the one that committers run manually before committing) so that
regressions will be caught before they are committed.

-
Erick Erickson:
Robert:
I was unclear. The only AwaitsFix annotations I was thinking of removing were
ones where the linked JIRA has been fixed. I don't think there are any in
Lucene that fit that criterion anyway...
I'll add annotations to reduce noise though, mostly in Solr. I think there are
a couple of occasionally-failing tests in Lucene, but I'll be sure to discuss
those ahead of time before adding any annotations there.

Yonik:
Right, I was thinking that we'd make any changes to the build system first,
then add any annotations or the like. My guess is there'll be a day or two
where things might be wonky but I'll be sure to let people know.
In fact, One possible outcome here is that the build system change is just to
add a tag to the subject line of e-mails indicating whether the build was run
with or without the tests disabled and not change the defaults at all That
decision has to be made first and coordinated with adding annotations.

-
Uwe Schindler:
Hi,
here is the patch for the build system changes: SOLR-12016-buildsystem.patch :
• Enables @BadApple tests by default. We should now make sure and review
all current @BadApple tests if they should maybe move to @AwaitsFix.
• Adds a missing help text in the ant test-help output
• Adds a new Jenkins job: ant jenkins-badapples
• No change to @AwaitsFix: Those stay disabled for jenkins and developers
and the test runner will just print the usual warning. So we should only be
used for tests that are definitely broken and fail 100% of the time (e.g. cause
is known). In contrast @BadApple should be used for tests that fail sometimes
(like <30% of all runs). For tests failing more often it's also good to move
them to @AwaitsFix, as those make no sense to run. In both cases a JIRA-Issue
has to be linked.
For Erick Erickson: We should maybe ad a precommit test that complains about
tests marked with any of those annotations, but the related JIRA issues is
resolved/closed.

-
Uwe Schindler:
IMHO, the smoke tester should also disable flakey tests, because those should
not stop releases. I'll add a patch.

Uwe Schindler:
I updated the patch, to disable badapples on smoketester. Maybe somebody
verifies this change, as I have no way to test it and my knowledge of python is
zero.

-
Erick Erickson:
Uwe Schindler This is excellent. I'm flip-flopping on whether to go ahead or
wait until 7.3 is cut. On the one hand it'd be nice to say "As of 7.3, the
noise is stopped". On the other, there wouldn't be much time for stuff to bake.
Yonik's comments about reducing test coverage are germane, especially just
before a release.
On the other-other hand, having the noisy tests silenced would make the 7.3
release smoother.
Opinions anyone?

-
Uwe Schindler:
I'd like to do the next release without the test noise. You may have noticed
that I did not help running smoke tester and I did not vote for past releases.
One of the reasonos was, that I was not able to get smoke tester running at
all! In addition, since 7.3, we will run Jenkins on both Java 8 and Java 9 to
make sure it runs with Java 9, too (MR-JARs,...). So the chance that it fails
is twice as high. So it's now impossible to pass smoke tester. See the jenkins
logs, we had not even one successful smoker run!
To do a relaese with 7.3 code base, we should get this in first. Thanks, Uwe

-
Erick Erickson:
Uwe Schindler The RMs job (and all volunteers who run smoke tests) is hard
enough as it is, so I'll start working on this. The initial cut shouldn't take
long at all given Hoss' reports.
The idea of a precommit test is a good one, but I confess I won't get to it.
I'll fold your build system changes in at the same time of course.

Uwe Schindler I have one suggestion though. Running with BadApple enabled on

[jira] [Created] (SOLR-12037) Reduce noise from flakey tests

Erick Erickson created SOLR-12037:
-

 Summary: Reduce noise from flakey tests
 Key: SOLR-12037
 URL: https://issues.apache.org/jira/browse/SOLR-12037
 Project: Solr
  Issue Type: Improvement
  Security Level: Public (Default Security Level. Issues are Public)
  Components: Tests
Affects Versions: 7.2
Reporter: Erick Erickson
Assignee: Erick Erickson


Recreating SOLR-12016. Please do NOT delete this without discussion. NOTE: 
Uwe's build system modifications originally on 12016 have been incorporated 
into SOLR-12028.

Current situation concerns:
> There is so much noise from flakey tests (particularly Solr tests) that they 
> are difficult to use.
> The number of tests that regularly fail is increasing
> Failures are being ignored
> The number of failing tests makes releasing more difficult.
> The number of failing tests make it harder to determine whether recent 
> changes actually caused problems. Running the tests again until they succeed 
> is used commonly at present, which is not robust.
> e-mail notifications of failing tests are largely being ignored.
Propsal:
> Mark all currently "flakey" tests as BadApple or AwaitsFix
> Run Jenkins jobs with BadApple (and/or AwaitsFix) enabled and disabled. 
> Frequency TBD, depends partly on whether we can label emails from these runs 
> for easy filtering of the two flavors.
>> Label these runs with something suitable in the subject line (wish list)
> Weekly reports on the tests labeled BadApple or AwaitsFix
>> Perhaps this could be incorporated in the reports linked below (wish list)
> Committers should enable BadApple (or AwaitsFix) regularly as a sanity check. 
> Leave these as defaults.
> We start getting much more aggressive about not allowing new flakey tests.
NOTE: It's perfectly acceptable to have failing flakey tests as long as someone 
is activey working on fixing them.
Concerns with solution
> Decreases test coverage
> Decreases visibility of flakey tests, making fixing them less likely.
> Some tools (see below) that report on bad tests will not see tests that are 
> annotated with BadApple or AwaitsFix.
> Running unit tests and reporting errors are being conflated
To be decided:
> Can we label e-mails with failing tests with something in the subject line 
> identifying whether they were run with BadApple/Awaits fix enabled or 
> disabled? Can someone volunteer?
> Is there any difference between BadApple and AwaitsFix? If not should we 
> deprecate one? I propose we just use AwaitsFix and deprecate BadApple.
> Can the automated reports (see below) be enhanced to also report tests 
> labeled BadApple or AwaitsFix?
Useful tools:
> Steve Rowe's work on a Jenkins job to reproduce test failures (LUCENE-8106) 
> Hoss has worked on aggregating all test failures from the 3 Jenkins systems 
> (ASF, Policeman, and Steve's), downloading the test results & logs, and 
> running some reports/stats on failures.
>> http://fucit.org/solr-jenkins-reports/
>> https://github.com/hossman/jenkins-reports/
>> http://fucit.org/solr-jenkins-reports/failure-report.html
I've assigned this JIRA to myslef, but all volunteers welcome, especially 
anything that changes the build system.
I've decided to make this a SOLR jira on the theory that most of the offending 
tests are in the Solr hive, any sub-tasks for touching the build system can go 
under LUCENE if wanted.
Also, I expect to add the annotation to some more tests for a few days as 
infrequent failures occur. Once we have stability (defined by there being 
little noise) that'll stop.
3 BadApple 23 AwaitsFix annotations are currently in the code, linked to these 
issues:

HADOOP-9893
LUCENE-3869
LUCENE-5575")
LUCENE-5595
LUCENE-5737
LUCENE-6709
LUCENE-7161
SOLR-2715
SOLR-6213
SOLR-6443
SOLR-6944
SOLR-10071
SOLR-10136
SOLR-10734
SOLR-11974
Solr JIRAS about bad tests
SOLR-2175
SOLR-4147
SOLR-5880
SOLR-6423
SOLR-6944
SOLR-6961
SOLR-6974
SOLR-8122
SOLR-8182
SOLR-9869
SOLR-10053
SOLR-10070
SOLR-10071
SOLR-10139
SOLR-10287

SOLR-11911




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (LUCENE-8159) Add a copy constructor in AutomatonQuery to copy directly the compiled automaton

2018-02-26 Thread David Smiley (JIRA)


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

David Smiley commented on LUCENE-8159:
--

bq. expose an expert constructor that takes a compiled automaton and expect 
users to compile the automaton themselves if they plan to reuse it in multiple 
queries?

+1 but I think it would be helpful to also provide access to the 
CompiledAutomaton from an existing AutomatonQuery -- e.g. 
AutomatonQuery.getCompiledAutomaton().  Not only would that be useful for 
rewriting an AutomatonQuery to change the field, but it would also be useful in 
the UnifiedHighlighter's MultiTermHighlighting line ~144 to avoid rebuilding 
the CompiledAutomaton from an existing AQ.

> Add a copy constructor in AutomatonQuery to copy directly the compiled 
> automaton
> 
>
> Key: LUCENE-8159
> URL: https://issues.apache.org/jira/browse/LUCENE-8159
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/search
>Affects Versions: trunk
>Reporter: Bruno Roustant
>Assignee: David Smiley
>Priority: Major
> Attachments: 
> 0001-Add-a-copy-constructor-in-AutomatonQuery-to-copy-dir.patch, 
> LUCENE-8159.patch
>
>
> When the query is composed of multiple AutomatonQuery with the same automaton 
> and which target different fields, it is much more efficient to reuse the 
> already compiled automaton by copying it directly and just changing the 
> target field.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

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

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

6 tests failed.
FAILED:  org.apache.solr.cloud.TestAuthenticationFramework.testBasics

Error Message:
Error from server at 
https://127.0.0.1:33519/solr/testcollection_shard1_replica_n3: Expected mime 
type application/octet-stream but got text/html.Error 404 
Can not find: /solr/testcollection_shard1_replica_n3/update  
HTTP ERROR 404 Problem accessing 
/solr/testcollection_shard1_replica_n3/update. Reason: Can not find: 
/solr/testcollection_shard1_replica_n3/updatehttp://eclipse.org/jetty;>Powered by Jetty:// 9.4.8.v20171121  
  

Stack Trace:
org.apache.solr.client.solrj.impl.CloudSolrClient$RouteException: Error from 
server at https://127.0.0.1:33519/solr/testcollection_shard1_replica_n3: 
Expected mime type application/octet-stream but got text/html. 


Error 404 Can not find: 
/solr/testcollection_shard1_replica_n3/update

HTTP ERROR 404
Problem accessing /solr/testcollection_shard1_replica_n3/update. Reason:
Can not find: 
/solr/testcollection_shard1_replica_n3/updatehttp://eclipse.org/jetty;>Powered by Jetty:// 9.4.8.v20171121




at 
__randomizedtesting.SeedInfo.seed([8250FC5E8F2831B0:BF885272B7C66FC0]:0)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:550)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1013)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:884)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:946)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:946)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:946)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:946)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:946)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:817)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:194)
at 
org.apache.solr.client.solrj.request.UpdateRequest.commit(UpdateRequest.java:233)
at 
org.apache.solr.cloud.TestAuthenticationFramework.collectionCreateSearchDeleteTwice(TestAuthenticationFramework.java:126)
at 
org.apache.solr.cloud.TestAuthenticationFramework.testBasics(TestAuthenticationFramework.java:74)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at

[jira] [Updated] (SOLR-11952) Add onlineRegress Stream Decorator to support Streaming Regression


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

Joel Bernstein updated SOLR-11952:
--
Description: 
The current *olsRegress* function works on an in-memory matrix. It would be 
nice to also have an online updating multivariate regression implementation 
that works with data sets of any size.

This ticket will add support for *Miller Updating Regression*, which can be 
used with data sets of any size. An *OnlineRegressionStream* Stream Decorator 
will be added to support this functionality. The function name will likely be 
called *onlineRegress*.

The implementation will be provided by Apache Commons Math.

 

  was:
The current *olsRegress* function works on in-memory matrices. It would be nice 
to also have an online updating multivariate regression implementation that 
works with data sets of any size.

This ticket will add support for *Miller Updating Regression*, which can be 
used with data sets of any size. An *OnlineRegressionStream* Stream Decorator 
will be added to support this functionality. The function name will likely be 
called *onlineRegress*.

The implementation will be provided by Apache Commons Math.

 


> Add onlineRegress Stream Decorator to support Streaming Regression
> --
>
> Key: SOLR-11952
> URL: https://issues.apache.org/jira/browse/SOLR-11952
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
>Priority: Major
> Fix For: 7.3
>
>
> The current *olsRegress* function works on an in-memory matrix. It would be 
> nice to also have an online updating multivariate regression implementation 
> that works with data sets of any size.
> This ticket will add support for *Miller Updating Regression*, which can be 
> used with data sets of any size. An *OnlineRegressionStream* Stream Decorator 
> will be added to support this functionality. The function name will likely be 
> called *onlineRegress*.
> The implementation will be provided by Apache Commons Math.
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Updated] (SOLR-11952) Add onlineRegress Stream Decorator to support Streaming Regression


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

Joel Bernstein updated SOLR-11952:
--
Description: 
The current *olsRegress* function works on in-memory matrices. It would be nice 
to also have an online updating multivariate regression implementation that 
works with data sets of any size.

This ticket will add support for *Miller Updating Regression*, which can be 
used with data sets of any size. An *OnlineRegressionStream* Stream Decorator 
will be added to support this functionality. The function name will likely be 
called online*Regress*.

The implementation will be provided by Apache Commons Math.

 

  was:
The current *olsRegress* function works on in-memory matrices. It would be nice 
to also have an online updating multivariate regression implementation that 
works with data sets of any size.

This ticket will add support for *Miller Updating Regression*, which can be 
used with data sets of any size. An *UpdatingRegressionStream* Stream Decorator 
will be added to support this functionality. The function name will likely be 
called *updatingRegress*.

The implementation will be provided by Apache Commons Math.

 


> Add onlineRegress Stream Decorator to support Streaming Regression
> --
>
> Key: SOLR-11952
> URL: https://issues.apache.org/jira/browse/SOLR-11952
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
>Priority: Major
> Fix For: 7.3
>
>
> The current *olsRegress* function works on in-memory matrices. It would be 
> nice to also have an online updating multivariate regression implementation 
> that works with data sets of any size.
> This ticket will add support for *Miller Updating Regression*, which can be 
> used with data sets of any size. An *OnlineRegressionStream* Stream Decorator 
> will be added to support this functionality. The function name will likely be 
> called online*Regress*.
> The implementation will be provided by Apache Commons Math.
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Updated] (SOLR-11952) Add onlineRegress Stream Decorator to support Streaming Regression


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

Joel Bernstein updated SOLR-11952:
--
Description: 
The current *olsRegress* function works on in-memory matrices. It would be nice 
to also have an online updating multivariate regression implementation that 
works with data sets of any size.

This ticket will add support for *Miller Updating Regression*, which can be 
used with data sets of any size. An *OnlineRegressionStream* Stream Decorator 
will be added to support this functionality. The function name will likely be 
called *onlineRegress*.

The implementation will be provided by Apache Commons Math.

 

  was:
The current *olsRegress* function works on in-memory matrices. It would be nice 
to also have an online updating multivariate regression implementation that 
works with data sets of any size.

This ticket will add support for *Miller Updating Regression*, which can be 
used with data sets of any size. An *OnlineRegressionStream* Stream Decorator 
will be added to support this functionality. The function name will likely be 
called online*Regress*.

The implementation will be provided by Apache Commons Math.

 


> Add onlineRegress Stream Decorator to support Streaming Regression
> --
>
> Key: SOLR-11952
> URL: https://issues.apache.org/jira/browse/SOLR-11952
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
>Priority: Major
> Fix For: 7.3
>
>
> The current *olsRegress* function works on in-memory matrices. It would be 
> nice to also have an online updating multivariate regression implementation 
> that works with data sets of any size.
> This ticket will add support for *Miller Updating Regression*, which can be 
> used with data sets of any size. An *OnlineRegressionStream* Stream Decorator 
> will be added to support this functionality. The function name will likely be 
> called *onlineRegress*.
> The implementation will be provided by Apache Commons Math.
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Updated] (SOLR-11952) Add onlineRegress Stream Decorator to support Streaming Regression


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

Joel Bernstein updated SOLR-11952:
--
Summary: Add onlineRegress Stream Decorator to support Streaming Regression 
 (was: Add updatingRegress Stream Decorator to support Streaming Regression)

> Add onlineRegress Stream Decorator to support Streaming Regression
> --
>
> Key: SOLR-11952
> URL: https://issues.apache.org/jira/browse/SOLR-11952
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
>Priority: Major
> Fix For: 7.3
>
>
> The current *olsRegress* function works on in-memory matrices. It would be 
> nice to also have an online updating multivariate regression implementation 
> that works with data sets of any size.
> This ticket will add support for *Miller Updating Regression*, which can be 
> used with data sets of any size. An *UpdatingRegressionStream* Stream 
> Decorator will be added to support this functionality. The function name will 
> likely be called *updatingRegress*.
> The implementation will be provided by Apache Commons Math.
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Updated] (SOLR-11952) Add updatingRegress Stream Decorator to support Streaming Regression


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

Joel Bernstein updated SOLR-11952:
--
Fix Version/s: 7.3

> Add updatingRegress Stream Decorator to support Streaming Regression
> 
>
> Key: SOLR-11952
> URL: https://issues.apache.org/jira/browse/SOLR-11952
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
>Priority: Major
> Fix For: 7.3
>
>
> The current *olsRegress* function works on in-memory matrices. It would be 
> nice to also have an online updating multivariate regression implementation 
> that works with data sets of any size.
> This ticket will add support for *Miller Updating Regression*, which can be 
> used with data sets of any size. An *UpdatingRegressionStream* Stream 
> Decorator will be added to support this functionality. The function name will 
> likely be called *updatingRegress*.
> The implementation will be provided by Apache Commons Math.
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[JENKINS-EA] Lucene-Solr-7.x-Linux (64bit/jdk-10-ea+43) - Build # 1436 - Still unstable!

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/1436/
Java: 64bit/jdk-10-ea+43 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC

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

Error Message:
Expected no cores for decommisioned node: 
{replacenodetest_coll_notarget_shard2_replica_n21={name=replacenodetest_coll_notarget_shard2_replica_n21,instanceDir=/home/jenkins/workspace/Lucene-Solr-7.x-Linux/solr/build/solr-core/test/J1/temp/solr.cloud.ReplaceNodeNoTargetTest_64839A6133A663FF-001/tempDir-001/node5/replacenodetest_coll_notarget_shard2_replica_n21,dataDir=/home/jenkins/workspace/Lucene-Solr-7.x-Linux/solr/build/solr-core/test/J1/temp/solr.cloud.ReplaceNodeNoTargetTest_64839A6133A663FF-001/tempDir-001/node5/./replacenodetest_coll_notarget_shard2_replica_n21/data/,config=solrconfig.xml,schema=schema.xml,startTime=Mon
 Feb 26 21:48:57 AST 
2018,uptime=3979,lastPublished=active,configVersion=0,cloud={collection=replacenodetest_coll_notarget,shard=shard2,replica=core_node22},index={numDocs=0,maxDoc=0,deletedDocs=0,indexHeapUsageBytes=0,version=2,segmentCount=0,current=true,hasDeletions=false,directory=org.apache.lucene.store.MockDirectoryWrapper:MockDirectoryWrapper(RAMDirectory@28ee509c
 
lockFactory=org.apache.lucene.store.SingleInstanceLockFactory@25a9a4f4),segmentsFile=segments_1,segmentsFileSizeInBytes=69,userData={},sizeInBytes=69,size=69
 bytes}}} expected:<0> but was:<1>

Stack Trace:
java.lang.AssertionError: Expected no cores for decommisioned node: 
{replacenodetest_coll_notarget_shard2_replica_n21={name=replacenodetest_coll_notarget_shard2_replica_n21,instanceDir=/home/jenkins/workspace/Lucene-Solr-7.x-Linux/solr/build/solr-core/test/J1/temp/solr.cloud.ReplaceNodeNoTargetTest_64839A6133A663FF-001/tempDir-001/node5/replacenodetest_coll_notarget_shard2_replica_n21,dataDir=/home/jenkins/workspace/Lucene-Solr-7.x-Linux/solr/build/solr-core/test/J1/temp/solr.cloud.ReplaceNodeNoTargetTest_64839A6133A663FF-001/tempDir-001/node5/./replacenodetest_coll_notarget_shard2_replica_n21/data/,config=solrconfig.xml,schema=schema.xml,startTime=Mon
 Feb 26 21:48:57 AST 
2018,uptime=3979,lastPublished=active,configVersion=0,cloud={collection=replacenodetest_coll_notarget,shard=shard2,replica=core_node22},index={numDocs=0,maxDoc=0,deletedDocs=0,indexHeapUsageBytes=0,version=2,segmentCount=0,current=true,hasDeletions=false,directory=org.apache.lucene.store.MockDirectoryWrapper:MockDirectoryWrapper(RAMDirectory@28ee509c
 
lockFactory=org.apache.lucene.store.SingleInstanceLockFactory@25a9a4f4),segmentsFile=segments_1,segmentsFileSizeInBytes=69,userData={},sizeInBytes=69,size=69
 bytes}}} expected:<0> but was:<1>
at 
__randomizedtesting.SeedInfo.seed([64839A6133A663FF:ECD7A5BB9D5A0E07]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.failNotEquals(Assert.java:647)
at org.junit.Assert.assertEquals(Assert.java:128)
at org.junit.Assert.assertEquals(Assert.java:472)
at 
org.apache.solr.cloud.ReplaceNodeNoTargetTest.test(ReplaceNodeNoTargetTest.java:101)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at

[JENKINS] Lucene-Solr-repro - Build # 147 - Still Unstable

Build: https://builds.apache.org/job/Lucene-Solr-repro/147/

[...truncated 29 lines...]
[repro] Jenkins log URL: 
https://builds.apache.org/job/Lucene-Solr-Tests-7.x/462/consoleText

[repro] Revision: 7707e6528ea5c62420df90c63fc52fc8684e4439

[repro] Repro line:  ant test  -Dtestcase=TestStressLucene 
-Dtests.method=testStressLuceneNRT -Dtests.seed=2B475370488D918A 
-Dtests.multiplier=2 -Dtests.slow=true -Dtests.locale=de-AT 
-Dtests.timezone=America/Nassau -Dtests.asserts=true 
-Dtests.file.encoding=US-ASCII

[repro] Repro line:  ant test  -Dtestcase=MoveReplicaHDFSTest 
-Dtests.method=testFailedMove -Dtests.seed=2B475370488D918A 
-Dtests.multiplier=2 -Dtests.slow=true -Dtests.locale=he-IL 
-Dtests.timezone=Asia/Saigon -Dtests.asserts=true -Dtests.file.encoding=US-ASCII

[repro] Repro line:  ant test  -Dtestcase=AutoscalingHistoryHandlerTest 
-Dtests.method=testHistory -Dtests.seed=2B475370488D918A -Dtests.multiplier=2 
-Dtests.slow=true -Dtests.locale=fi-FI -Dtests.timezone=Pacific/Noumea 
-Dtests.asserts=true -Dtests.file.encoding=US-ASCII

[repro] git rev-parse --abbrev-ref HEAD
[repro] git rev-parse HEAD
[repro] Initial local git branch/revision: 
1fc3ca0cbb2fcdd99c4a58dcf98d346e1bab5015
[repro] git fetch
[repro] git checkout 7707e6528ea5c62420df90c63fc52fc8684e4439

[...truncated 2 lines...]
[repro] git merge --ff-only

[...truncated 1 lines...]
[repro] ant clean

[...truncated 6 lines...]
[repro] Test suites by module:
[repro]solr/core
[repro]   AutoscalingHistoryHandlerTest
[repro]   TestStressLucene
[repro]   MoveReplicaHDFSTest
[repro] ant compile-test

[...truncated 3310 lines...]
[repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=15 
-Dtests.class="*.AutoscalingHistoryHandlerTest|*.TestStressLucene|*.MoveReplicaHDFSTest"
 -Dtests.showOutput=onerror  -Dtests.seed=2B475370488D918A -Dtests.multiplier=2 
-Dtests.slow=true -Dtests.locale=fi-FI -Dtests.timezone=Pacific/Noumea 
-Dtests.asserts=true -Dtests.file.encoding=US-ASCII

[...truncated 1809 lines...]
[repro] Setting last failure code to 256

[repro] Failures:
[repro]   0/5 failed: org.apache.solr.cloud.MoveReplicaHDFSTest
[repro]   0/5 failed: org.apache.solr.search.TestStressLucene
[repro]   1/5 failed: 
org.apache.solr.handler.admin.AutoscalingHistoryHandlerTest
[repro] git checkout 1fc3ca0cbb2fcdd99c4a58dcf98d346e1bab5015

[...truncated 2 lines...]
[repro] Exiting with code 256

[...truncated 5 lines...]

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

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

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

2 tests failed.
FAILED:  org.apache.solr.cloud.autoscaling.TriggerIntegrationTest.testEventQueue

Error Message:
action wasn't interrupted

Stack Trace:
java.lang.AssertionError: action wasn't interrupted
at 
__randomizedtesting.SeedInfo.seed([E4D96D5A2B1737AF:2D6C2FF42270F15A]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.cloud.autoscaling.TriggerIntegrationTest.testEventQueue(TriggerIntegrationTest.java:726)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:748)


FAILED:  org.apache.solr.handler.admin.AutoscalingHistoryHandlerTest.testHistory

Error Message:
expected:<5> but was:<0>

Stack Trace:
java.lang.AssertionError: expected:<5> but was:<0>
at 
__randomizedtesting.SeedInfo.seed([E4D96D5A2B1737AF:8925C9A7915FC8A8]:0)
at org.junit.Assert.fail(Assert.java:93)
at

[jira] [Commented] (LUCENE-5575) Non-reproducible TestICUTokenizerCJK failure

2018-02-26 Thread Adrien Grand (JIRA)


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

Adrien Grand commented on LUCENE-5575:
--

Have you tried to run something like {{ant beast -Dbeast.iters=1000 
-Dtestcase=TestICUTokenizerCJK}}? If it doesn't fail I'm +1 to reenable the 
test.

> Non-reproducible TestICUTokenizerCJK failure
> 
>
> Key: LUCENE-5575
> URL: https://issues.apache.org/jira/browse/LUCENE-5575
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/analysis
>Affects Versions: 6.0
>Reporter: Michael McCandless
>Priority: Major
>
> TestICUTokenizerCJK.testRandomHugeStrings -seed 3D1F79CAB506E300
> It hit this failure during distributed beasting:
> {noformat}
> FAILURE: org.apache.lucene.analysis.icu.segmentation.TestICUTokenizerCJK on 
> host 10.17.4.101
> java.lang.RuntimeException: some thread(s) failed
>   at 
> org.apache.lucene.analysis.BaseTokenStreamTestCase.checkRandomData(BaseTokenStreamTestCase.java:533)
>   at 
> org.apache.lucene.analysis.BaseTokenStreamTestCase.checkRandomData(BaseTokenStreamTestCase.java:435)
>   at 
> org.apache.lucene.analysis.icu.segmentation.TestICUTokenizerCJK.testRandomHugeStrings(TestICUTokenizerCJK.java:89)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:606)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1618)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:827)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:877)
>   at 
> org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
>   at 
> org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCacheSanity.java:51)
>   at 
> org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
>   at 
> com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
>   at 
> org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
>   at 
> org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
>   at 
> org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
>   at 
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
>   at 
> com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:360)
>   at 
> com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:793)
>   at 
> com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:453)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:836)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:738)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:772)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:783)
>   at 
> org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
>   at 
> org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
>   at 
> com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
>   at 
> com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
>   at 
> com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
>   at 
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
>   at 
> org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:43)
>   at 
> org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
>   at 
> org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
>   at 
>

[jira] [Commented] (LUCENE-8159) Add a copy constructor in AutomatonQuery to copy directly the compiled automaton

2018-02-26 Thread Adrien Grand (JIRA)


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

Adrien Grand commented on LUCENE-8159:
--

Having a copy constructor to modify the field feels a bit weird to me. I's 
rather like to expose an expert constructor that takes a compiled automaton and 
expect users to compile the automaton themselves if they plan to reuse it in 
multiple queries?

bq. Should PrefixQuery & WildcardQuery & TermRangeQuery have the same 
constructors too?

I'm open to discussing such a change on AutomatonQuery which I consider an 
expert query. However I would like to keep PrefixQuery/WildcardQuery as simple 
as possible so I think we shouldn't add a new constructor there. Those queries 
generate very simple automata so I wouldn't expect this optimization to help 
significantly.

> Add a copy constructor in AutomatonQuery to copy directly the compiled 
> automaton
> 
>
> Key: LUCENE-8159
> URL: https://issues.apache.org/jira/browse/LUCENE-8159
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/search
>Affects Versions: trunk
>Reporter: Bruno Roustant
>Assignee: David Smiley
>Priority: Major
> Attachments: 
> 0001-Add-a-copy-constructor-in-AutomatonQuery-to-copy-dir.patch, 
> LUCENE-8159.patch
>
>
> When the query is composed of multiple AutomatonQuery with the same automaton 
> and which target different fields, it is much more efficient to reuse the 
> already compiled automaton by copying it directly and just changing the 
> target field.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

Re: Moving forward for 2017 taxes

2018-02-26 Thread Erick Erickson

Crap, did it again. Fortunately this has no real information, sorry
for the noise.

On Mon, Feb 26, 2018 at 4:59 PM, Erick Erickson  wrote:
> Devin:
>
> I think we have everything up on the IntuitLink site, how do we move
> forward from here?
>
> Thanks,
> Erick

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

Moving forward for 2017 taxes

2018-02-26 Thread Erick Erickson

Devin:

I think we have everything up on the IntuitLink site, how do we move
forward from here?

Thanks,
Erick

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

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

2018-02-26 Thread ASF subversion and git services (JIRA)

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/21541/
Java: 32bit/jdk1.8.0_162 -server -XX:+UseSerialGC

No tests ran.

Build Log:
[...truncated 58261 lines...]
[repro] Jenkins log URL: 
https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/21541/consoleText

[repro] Revision: 50c17b92bd2709ac9432dab72dc87f3873603dbc

[repro] Ant options: "-Dargs=-server -XX:+UseSerialGC"
[repro] No "reproduce with" lines found; exiting.

[...truncated 8 lines...]
ERROR: Step ‘Publish JUnit test result report’ failed: No test report files 
were found. Configuration error?
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any
Setting 
ANT_1_8_2_HOME=/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Setting 
ANT_1_8_2_HOME=/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Setting 
ANT_1_8_2_HOME=/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Setting 
ANT_1_8_2_HOME=/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2

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

Re: what should go in a docValues field?

2018-02-26 Thread Adrien Grand

I'm not familiar with how Solr deals with this in details but to me option
2 is the way to go. I also agree with your feeling that there should be a
way to convert the internal representation of doc values to something that
is human-readable.

Le lun. 26 févr. 2018 à 22:02, Patrick Recchia 
a écrit :

> Hello all,
>
> I hope I'm in the right place to ask this question.
> Seemed to me as this didn't quite qualify for the user's mailing list.
> But, if not, feel free to redirect me elsewhere.
>
> The question is: what should we store in a docValues field?
>
> I'm working on the implementation of a InetAddress field type for solr;
> leveraging on the' InetAddressPoint sandbox lucene field.
> It started as a POC (as we are internally using solr, but feel the need to
> index IP Address fields).
>
> It might even qualify as something which might go in the direction of
> SOLR-6741; for which I'm planning to offer a patch.
>
> But then I struggle around the following problem:
> what should I store within the docValues field?
>
> The problem is that docValues are being used for two different reasons
> (frm what I can tell):
> - to sort
> - and as an optimizatoin when we retrieve only part of the fields of  a
> set of documents
>
> Each scenario call for different content.
>
> I see 2 possible options, and am not happy with any of them:
>
> 1) string representation:
> I could store the string representation of the IP address. e.g.
> 192.168.1.1 would be stored as "192.168.1.1". as SORTED.
> No issue in displaying the field: it is a string. It appears as a string.
> Except I would need to normalize it somehow, and then I supose that we
> would have 192.168.100.1 < 192.168.11.1 (because '0' < '1').
> So wrong choice.
>
> 2) binary representation:
> I could store the binary representation of the address - which would make
> sense because then I could do sorting - really based on the numeric value
> of the Address.
> So, 192.168.100.1 > 192.168.11.1
> But then I face the issue of the representation of the docValues field
> (when using fl, for example).
> SolrDocumentFetcher.decorateDocValues goes through a long switch to decide
> how to render the docValues.
> My field (InetAddressType) won't fit into any of these cases.
> So I would need to patch also SolrDocumentFetcher to add the
> representation for my new Type.
> Which I feel a bit odd: I should be able to add a fieldType without the
> need to change anyting within the remaining of solr.
>
> So, I see no easy solution neither with 1, nor with 2.
> Or is there something I have overlooked, and the solution is actually
> pretty simple, but hidden to my (layman) eyes?
>
> Incidentally, I somehow feel that the best would be to have something line
> toObject, toExternal, indexedToReadable, etc... for the docValues field,
> directly from within FieldType.
> That would also clean the long case within the SolrDocumentFetcher.
> Again, my feeling? There is, actually, an excellent reason for this long
> switch here, rather than a method there?
>
>
> Thanks to anyone for any clarification.
>
>
>
>
> --
> One way of describing a computer is as an electric box which hums.
> Never ascribe to malice what can be explained by stupidity
> --
> Patrick Recchia
>
>

[jira] [Commented] (SOLR-11067) REPLACENODE should make it optional to provide a target node


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

ASF subversion and git services commented on SOLR-11067:


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

SOLR-11067: AwaitsFix. The test fails often as the target node some times is 
same as the source node


> REPLACENODE should make it optional to provide a target node
> 
>
> Key: SOLR-11067
> URL: https://issues.apache.org/jira/browse/SOLR-11067
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: AutoScaling, SolrCloud
>Reporter: Shalin Shekhar Mangar
>Assignee: Noble Paul
>Priority: Major
> Fix For: master (8.0), 7.3
>
> Attachments: SOLR-11067.patch
>
>
> The REPLACENODE API currently accepts a replacement target and moves all 
> replicas from the source to the given target. We can improve this by having 
> it figure out the right target node for each replica contained in the source.
> This can also then be a thin wrapper over nodeLost event just like how 
> UTILIZENODE (SOLR-9743) can be a wrapper over nodeAdded event.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Comment Edited] (LUCENE-8106) Add script to attempt to reproduce failing tests from a Jenkins log

2018-02-26 Thread Steve Rowe (JIRA)


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

Steve Rowe edited comment on LUCENE-8106 at 2/26/18 11:59 PM:
--

{quote}Sarowe's Jenkins uses ANT_OPTS environment variable. But this is 
something completely different: It is just options that are passed to ANT's JVM 
(the JVM that runs the build scripts). Those won't be passed to test runners, 
as not even the build.xml would see them. Contrary, in the python script they 
are passed like other ant arguments, which is wrong. [...] The ANT_OPTS stuff 
should be removed from the script, it has nothing to do with reproducing tests
{quote}
Thanks, this is done.

I also did the following:
 * fixed a path-based regex that was triggering failures on Windows (fixed to 
handle backslashes).
 * changed the windows batch script to only attempt to move directories if they 
exist (missing directories were causing script failures)
 * added the repro script to the 7.x windows job

I'll keep an eye on the windows builds, hopefully they're fully working after 
these changes.


was (Author: steve_rowe):
bq. Sarowe's Jenkins uses ANT_OPTS environment variable. But this is something 
completely different: It is just options that are passed to ANT's JVM (the JVM 
that runs the build scripts). Those won't be passed to test runners, as not 
even the build.xml would see them. Contrary, in the python script they are 
passed like other ant arguments, which is wrong. [...] The ANT_OPTS stuff 
should be removed from the script, it has nothing to do with reproducing tests

Thanks, this is done.

I also did the following:

* fixed a path-based regex that was triggering failures on Windows (fixed to 
handle backslashes).
* changed the windows batch script to only attempt to move directories if they 
exist (missing directories were causing script failures)
* added the repro script to the 7.x windows job

I'll keep an eye on the windows builds, hopefully they're fully working after 
these changes.

> Add script to attempt to reproduce failing tests from a Jenkins log
> ---
>
> Key: LUCENE-8106
> URL: https://issues.apache.org/jira/browse/LUCENE-8106
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Steve Rowe
>Assignee: Steve Rowe
>Priority: Major
> Fix For: master (8.0), 7.3
>
> Attachments: LUCENE-8106-part2.patch, LUCENE-8106-part3.patch, 
> LUCENE-8106-part4.patch, LUCENE-8106.patch, LUCENE-8106.patch
>
>
> This script will be runnable from a downstream job triggered by an upstream 
> failing Jenkins job, passing log location info between the two.
> The script will also be runnable manually from a developer's cmdline.
> From the script help:
> {noformat}
> Usage:
>  python3 -u reproduceJenkinsFailures.py URL
> Must be run from a Lucene/Solr git workspace. Downloads the Jenkins
> log pointed to by the given URL, parses it for Git revision and failed
> Lucene/Solr tests, checks out the Git revision in the local workspace,
> groups the failed tests by module, then runs
> 'ant test -Dtest.dups=5 -Dtests.class="*.test1[|*.test2[...]]" ...'
> in each module of interest, failing at the end if any of the runs fails.
> To control the maximum number of concurrent JVMs used for each module's
> test run, set 'tests.jvms', e.g. in ~/lucene.build.properties
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (LUCENE-8106) Add script to attempt to reproduce failing tests from a Jenkins log

2018-02-26 Thread Steve Rowe (JIRA)


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

Steve Rowe commented on LUCENE-8106:


bq. Sarowe's Jenkins uses ANT_OPTS environment variable. But this is something 
completely different: It is just options that are passed to ANT's JVM (the JVM 
that runs the build scripts). Those won't be passed to test runners, as not 
even the build.xml would see them. Contrary, in the python script they are 
passed like other ant arguments, which is wrong. [...] The ANT_OPTS stuff 
should be removed from the script, it has nothing to do with reproducing tests

Thanks, this is done.

I also did the following:

* fixed a path-based regex that was triggering failures on Windows (fixed to 
handle backslashes).
* changed the windows batch script to only attempt to move directories if they 
exist (missing directories were causing script failures)
* added the repro script to the 7.x windows job

I'll keep an eye on the windows builds, hopefully they're fully working after 
these changes.

> Add script to attempt to reproduce failing tests from a Jenkins log
> ---
>
> Key: LUCENE-8106
> URL: https://issues.apache.org/jira/browse/LUCENE-8106
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Steve Rowe
>Assignee: Steve Rowe
>Priority: Major
> Fix For: master (8.0), 7.3
>
> Attachments: LUCENE-8106-part2.patch, LUCENE-8106-part3.patch, 
> LUCENE-8106-part4.patch, LUCENE-8106.patch, LUCENE-8106.patch
>
>
> This script will be runnable from a downstream job triggered by an upstream 
> failing Jenkins job, passing log location info between the two.
> The script will also be runnable manually from a developer's cmdline.
> From the script help:
> {noformat}
> Usage:
>  python3 -u reproduceJenkinsFailures.py URL
> Must be run from a Lucene/Solr git workspace. Downloads the Jenkins
> log pointed to by the given URL, parses it for Git revision and failed
> Lucene/Solr tests, checks out the Git revision in the local workspace,
> groups the failed tests by module, then runs
> 'ant test -Dtest.dups=5 -Dtests.class="*.test1[|*.test2[...]]" ...'
> in each module of interest, failing at the end if any of the runs fails.
> To control the maximum number of concurrent JVMs used for each module's
> test run, set 'tests.jvms', e.g. in ~/lucene.build.properties
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (SOLR-11067) REPLACENODE should make it optional to provide a target node

2018-02-26 Thread ASF subversion and git services (JIRA)


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

ASF subversion and git services commented on SOLR-11067:


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

SOLR-11067: improve tests logging

(cherry picked from commit 8760e3225fe98c23210a0c73aff4c8f56bb7f39f)


> REPLACENODE should make it optional to provide a target node
> 
>
> Key: SOLR-11067
> URL: https://issues.apache.org/jira/browse/SOLR-11067
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: AutoScaling, SolrCloud
>Reporter: Shalin Shekhar Mangar
>Assignee: Noble Paul
>Priority: Major
> Fix For: master (8.0), 7.3
>
> Attachments: SOLR-11067.patch
>
>
> The REPLACENODE API currently accepts a replacement target and moves all 
> replicas from the source to the given target. We can improve this by having 
> it figure out the right target node for each replica contained in the source.
> This can also then be a thin wrapper over nodeLost event just like how 
> UTILIZENODE (SOLR-9743) can be a wrapper over nodeAdded event.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (SOLR-11067) REPLACENODE should make it optional to provide a target node

2018-02-26 Thread ASF subversion and git services (JIRA)


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

ASF subversion and git services commented on SOLR-11067:


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

SOLR-11067: improve tests logging


> REPLACENODE should make it optional to provide a target node
> 
>
> Key: SOLR-11067
> URL: https://issues.apache.org/jira/browse/SOLR-11067
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: AutoScaling, SolrCloud
>Reporter: Shalin Shekhar Mangar
>Assignee: Noble Paul
>Priority: Major
> Fix For: master (8.0), 7.3
>
> Attachments: SOLR-11067.patch
>
>
> The REPLACENODE API currently accepts a replacement target and moves all 
> replicas from the source to the given target. We can improve this by having 
> it figure out the right target node for each replica contained in the source.
> This can also then be a thin wrapper over nodeLost event just like how 
> UTILIZENODE (SOLR-9743) can be a wrapper over nodeAdded event.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (LUCENE-8106) Add script to attempt to reproduce failing tests from a Jenkins log

2018-02-26 Thread ASF subversion and git services (JIRA)


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

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

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

LUCENE-8106: fix module regex to recognize Windows path backslashes


> Add script to attempt to reproduce failing tests from a Jenkins log
> ---
>
> Key: LUCENE-8106
> URL: https://issues.apache.org/jira/browse/LUCENE-8106
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Steve Rowe
>Assignee: Steve Rowe
>Priority: Major
> Fix For: master (8.0), 7.3
>
> Attachments: LUCENE-8106-part2.patch, LUCENE-8106-part3.patch, 
> LUCENE-8106-part4.patch, LUCENE-8106.patch, LUCENE-8106.patch
>
>
> This script will be runnable from a downstream job triggered by an upstream 
> failing Jenkins job, passing log location info between the two.
> The script will also be runnable manually from a developer's cmdline.
> From the script help:
> {noformat}
> Usage:
>  python3 -u reproduceJenkinsFailures.py URL
> Must be run from a Lucene/Solr git workspace. Downloads the Jenkins
> log pointed to by the given URL, parses it for Git revision and failed
> Lucene/Solr tests, checks out the Git revision in the local workspace,
> groups the failed tests by module, then runs
> 'ant test -Dtest.dups=5 -Dtests.class="*.test1[|*.test2[...]]" ...'
> in each module of interest, failing at the end if any of the runs fails.
> To control the maximum number of concurrent JVMs used for each module's
> test run, set 'tests.jvms', e.g. in ~/lucene.build.properties
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (LUCENE-8106) Add script to attempt to reproduce failing tests from a Jenkins log

2018-02-26 Thread ASF subversion and git services (JIRA)


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

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

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

LUCENE-8106: stop parsing ANT_OPTS from Jenkins log


> Add script to attempt to reproduce failing tests from a Jenkins log
> ---
>
> Key: LUCENE-8106
> URL: https://issues.apache.org/jira/browse/LUCENE-8106
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Steve Rowe
>Assignee: Steve Rowe
>Priority: Major
> Fix For: master (8.0), 7.3
>
> Attachments: LUCENE-8106-part2.patch, LUCENE-8106-part3.patch, 
> LUCENE-8106-part4.patch, LUCENE-8106.patch, LUCENE-8106.patch
>
>
> This script will be runnable from a downstream job triggered by an upstream 
> failing Jenkins job, passing log location info between the two.
> The script will also be runnable manually from a developer's cmdline.
> From the script help:
> {noformat}
> Usage:
>  python3 -u reproduceJenkinsFailures.py URL
> Must be run from a Lucene/Solr git workspace. Downloads the Jenkins
> log pointed to by the given URL, parses it for Git revision and failed
> Lucene/Solr tests, checks out the Git revision in the local workspace,
> groups the failed tests by module, then runs
> 'ant test -Dtest.dups=5 -Dtests.class="*.test1[|*.test2[...]]" ...'
> in each module of interest, failing at the end if any of the runs fails.
> To control the maximum number of concurrent JVMs used for each module's
> test run, set 'tests.jvms', e.g. in ~/lucene.build.properties
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (LUCENE-8106) Add script to attempt to reproduce failing tests from a Jenkins log

2018-02-26 Thread ASF subversion and git services (JIRA)


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

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

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

LUCENE-8106: fix module regex to recognize Windows path backslashes


> Add script to attempt to reproduce failing tests from a Jenkins log
> ---
>
> Key: LUCENE-8106
> URL: https://issues.apache.org/jira/browse/LUCENE-8106
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Steve Rowe
>Assignee: Steve Rowe
>Priority: Major
> Fix For: master (8.0), 7.3
>
> Attachments: LUCENE-8106-part2.patch, LUCENE-8106-part3.patch, 
> LUCENE-8106-part4.patch, LUCENE-8106.patch, LUCENE-8106.patch
>
>
> This script will be runnable from a downstream job triggered by an upstream 
> failing Jenkins job, passing log location info between the two.
> The script will also be runnable manually from a developer's cmdline.
> From the script help:
> {noformat}
> Usage:
>  python3 -u reproduceJenkinsFailures.py URL
> Must be run from a Lucene/Solr git workspace. Downloads the Jenkins
> log pointed to by the given URL, parses it for Git revision and failed
> Lucene/Solr tests, checks out the Git revision in the local workspace,
> groups the failed tests by module, then runs
> 'ant test -Dtest.dups=5 -Dtests.class="*.test1[|*.test2[...]]" ...'
> in each module of interest, failing at the end if any of the runs fails.
> To control the maximum number of concurrent JVMs used for each module's
> test run, set 'tests.jvms', e.g. in ~/lucene.build.properties
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (LUCENE-8106) Add script to attempt to reproduce failing tests from a Jenkins log

2018-02-26 Thread ASF subversion and git services (JIRA)


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

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

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

LUCENE-8106: stop parsing ANT_OPTS from Jenkins log


> Add script to attempt to reproduce failing tests from a Jenkins log
> ---
>
> Key: LUCENE-8106
> URL: https://issues.apache.org/jira/browse/LUCENE-8106
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Steve Rowe
>Assignee: Steve Rowe
>Priority: Major
> Fix For: master (8.0), 7.3
>
> Attachments: LUCENE-8106-part2.patch, LUCENE-8106-part3.patch, 
> LUCENE-8106-part4.patch, LUCENE-8106.patch, LUCENE-8106.patch
>
>
> This script will be runnable from a downstream job triggered by an upstream 
> failing Jenkins job, passing log location info between the two.
> The script will also be runnable manually from a developer's cmdline.
> From the script help:
> {noformat}
> Usage:
>  python3 -u reproduceJenkinsFailures.py URL
> Must be run from a Lucene/Solr git workspace. Downloads the Jenkins
> log pointed to by the given URL, parses it for Git revision and failed
> Lucene/Solr tests, checks out the Git revision in the local workspace,
> groups the failed tests by module, then runs
> 'ant test -Dtest.dups=5 -Dtests.class="*.test1[|*.test2[...]]" ...'
> in each module of interest, failing at the end if any of the runs fails.
> To control the maximum number of concurrent JVMs used for each module's
> test run, set 'tests.jvms', e.g. in ~/lucene.build.properties
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[JENKINS] Lucene-Solr-7.x-Linux (32bit/jdk1.8.0_162) - Build # 1435 - Failure!

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/1435/
Java: 32bit/jdk1.8.0_162 -client -XX:+UseParallelGC

No tests ran.

Build Log:
[...truncated 58353 lines...]
[repro] Jenkins log URL: 
https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/1435/consoleText

[repro] Revision: ad9182a0c970597f4f5e946ca80ccf93e0dff0b9

[repro] Ant options: "-Dargs=-client -XX:+UseParallelGC"
[repro] No "reproduce with" lines found; exiting.

[...truncated 8 lines...]
ERROR: Step ‘Publish JUnit test result report’ failed: No test report files 
were found. Configuration error?
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any
Setting 
ANT_1_8_2_HOME=/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Setting 
ANT_1_8_2_HOME=/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Setting 
ANT_1_8_2_HOME=/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Setting 
ANT_1_8_2_HOME=/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2

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

[jira] [Commented] (SOLR-11067) REPLACENODE should make it optional to provide a target node

2018-02-26 Thread Hoss Man (JIRA)


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

Hoss Man commented on SOLR-11067:
-



Since this issue is still marked "Open" i'll post this here instead of creating 
a new jira..

The logic used by REPLACENODE when no target is specified appears to be flawed. 
 The logs from jenkins falures of ReplaceNodeNoTargetTest show that sometimes 
the 'source' node is choosen to be it's own replacement...

https://jenkins.thetaphi.de/view/Lucene-Solr/job/Lucene-Solr-master-Linux/21538/
{noformat}
   [junit4]   2> 1369525 INFO  (qtp1209949969-11440) [n:127.0.0.1:35749_solr
] o.a.s.h.a.CollectionsHandler Invoked Collection Action :replacenode with 
params 
async=001=REPLACENODE=127.0.0.1:45303_solr=javabin=2 
and sendToOCPQueue=true
   [junit4]   2> 1369526 INFO  (qtp1209949969-11440) [n:127.0.0.1:35749_solr
] o.a.s.s.HttpSolrCall [admin] webapp=null path=/admin/collections 
params={async=001=REPLACENODE=127.0.0.1:45303_solr=javabin=2}
 status=0 QTime=1
...
   [junit4]   2> 1369527 INFO  
(OverseerThreadFactory-4614-thread-2-processing-n:127.0.0.1:33719_solr) 
[n:127.0.0.1:33719_solr] o.a.s.c.a.c.ReplaceNodeCmd Going to create replica 
for collection=replacenodetest_coll_notarget shard=shard1 on node=null
...
   [junit4]   2> 1369551 INFO  
(OverseerThreadFactory-4614-thread-2-processing-n:127.0.0.1:33719_solr) 
[n:127.0.0.1:33719_solr] o.a.s.c.a.c.AddReplicaCmd Node Identified 
127.0.0.1:45303_solr for creating new replica
   [junit4]   2> 1369553 INFO  
(OverseerStateUpdate-72215357633069068-127.0.0.1:33719_solr-n_00) 
[n:127.0.0.1:33719_solr] o.a.s.c.o.SliceMutator createReplica() {
   [junit4]   2>   "operation":"addreplica",
   [junit4]   2>   "collection":"replacenodetest_coll_notarget",
   [junit4]   2>   "shard":"shard1",
   [junit4]   2>   "core":"replacenodetest_coll_notarget_shard1_replica_n21",
   [junit4]   2>   "state":"down",
   [junit4]   2>   "base_url":"http://127.0.0.1:45303/solr;,
   [junit4]   2>   "node_name":"127.0.0.1:45303_solr",
   [junit4]   2>   "type":"NRT"} 
{noformat}

NOTE: The test currently fails with an obscurely vague 
{{java.lang.AssertionError}} (when the node count of cores on the source node 
is non-0 after the command completes) roughly ~30% of the times it is run by 
jenkins.  This is consistent with the idea that REPLACENODE command is randomly 
picking from _all_ currently active NODES (w/o excluding the one to be 
replaced) since there are 6 nodes to choose from, but a total of 10 cores in 
the cluster -- so instead of just failing in 1/6th of the runes, 2 out 3 runs 
there are 2 cores on the source node and the randomized selection happens twice 
in the test:  (1/3 * 1/6) + (2/3 * (1/6 + 1/6)) ~= 27%



I plan to commit some improvements to the test assertion/logging that helped me 
in realizing that the root problem was that entirely new cores were being added 
to the `node2bdecommissioned` which lead to discovering the (aparent) root 
cause failure, but someone who understands the actual `REPLACENODE` code needs 
to figure out "the right" fix for this bug.

SIDE NOTE: what happens if i try `REPLACENODE` w/o a target on a cluster with 
only one node? presumably that should be a failure case -- but i'm confident we 
don't have a test for it. (because if we did then based on the logs above it 
would be failing 100% of the time as it just kept re-using the source node 
every time) 


> REPLACENODE should make it optional to provide a target node
> 
>
> Key: SOLR-11067
> URL: https://issues.apache.org/jira/browse/SOLR-11067
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: AutoScaling, SolrCloud
>Reporter: Shalin Shekhar Mangar
>Assignee: Noble Paul
>Priority: Major
> Fix For: master (8.0), 7.3
>
> Attachments: SOLR-11067.patch
>
>
> The REPLACENODE API currently accepts a replacement target and moves all 
> replicas from the source to the given target. We can improve this by having 
> it figure out the right target node for each replica contained in the source.
> This can also then be a thin wrapper over nodeLost event just like how 
> UTILIZENODE (SOLR-9743) can be a wrapper over nodeAdded event.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Assigned] (LUCENE-8159) Add a copy constructor in AutomatonQuery to copy directly the compiled automaton

2018-02-26 Thread David Smiley (JIRA)


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

David Smiley reassigned LUCENE-8159:


Assignee: David Smiley

This looks good to me.  I'd only trivially change the parameter order so that 
the field name is first, which I think aligns better with the Query subclass 
constructors.

Should PrefixQuery & WildcardQuery & TermRangeQuery have the same constructors 
too?  Probably... otherwise if you are rewriting one of these you could only 
convert it to a generic AutomatonQuery instead of the specific type.  That's 
not a big deal perhaps but still.

As an aside, this reminds me of some ideas I've had about a different Query API 
that Lucene could have in which the field is inherited from the parent instead 
of being attached to each leaf Query, sorta like how boosts were refactored out 
of Query.  So you'd have a FieldQuery(...) that wraps a possibly complex query 
with a TermQuery inside that only has the term bytes, no field reference. And 
then Query.createWeight would reference the field just as it does the score.  
Any way, such a hypothetical won't be happening on this issue!

> Add a copy constructor in AutomatonQuery to copy directly the compiled 
> automaton
> 
>
> Key: LUCENE-8159
> URL: https://issues.apache.org/jira/browse/LUCENE-8159
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/search
>Affects Versions: trunk
>Reporter: Bruno Roustant
>Assignee: David Smiley
>Priority: Major
> Attachments: 
> 0001-Add-a-copy-constructor-in-AutomatonQuery-to-copy-dir.patch, 
> LUCENE-8159.patch
>
>
> When the query is composed of multiple AutomatonQuery with the same automaton 
> and which target different fields, it is much more efficient to reuse the 
> already compiled automaton by copying it directly and just changing the 
> target field.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[JENKINS] Lucene-Solr-Tests-master - Build # 2383 - Still Unstable

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

1 tests failed.
FAILED:  
org.apache.solr.cloud.autoscaling.HdfsAutoAddReplicasIntegrationTest.testSimple

Error Message:
Waiting for collection testSimple1 null Live Nodes: [127.0.0.1:32908_solr, 
127.0.0.1:42580_solr] Last available state: 
DocCollection(testSimple1//collections/testSimple1/state.json/18)={   
"pullReplicas":"0",   "replicationFactor":"2",   "shards":{ "shard1":{  
 "range":"8000-",   "state":"active",   "replicas":{
 "core_node3":{   
"dataDir":"hdfs://lucene2-us-west.apache.org:45415/data/testSimple1/core_node3/data/",
   "base_url":"https://127.0.0.1:32908/solr;,   
"node_name":"127.0.0.1:32908_solr",   "type":"NRT",   
"ulogDir":"hdfs://lucene2-us-west.apache.org:45415/data/testSimple1/core_node3/data/tlog",
   "core":"testSimple1_shard1_replica_n1",   
"shared_storage":"true",   "state":"active",   
"leader":"true"}, "core_node5":{   
"dataDir":"hdfs://lucene2-us-west.apache.org:45415/data/testSimple1/core_node5/data/",
   "base_url":"https://127.0.0.1:32908/solr;,   
"node_name":"127.0.0.1:32908_solr",   "type":"NRT",   
"ulogDir":"hdfs://lucene2-us-west.apache.org:45415/data/testSimple1/core_node5/data/tlog",
   "core":"testSimple1_shard1_replica_n2",   
"shared_storage":"true",   "state":"active"}}}, "shard2":{   
"range":"0-7fff",   "state":"active",   "replicas":{ 
"core_node7":{   
"dataDir":"hdfs://lucene2-us-west.apache.org:45415/data/testSimple1/core_node7/data/",
   "base_url":"https://127.0.0.1:32908/solr;,   
"node_name":"127.0.0.1:32908_solr",   "type":"NRT",   
"ulogDir":"hdfs://lucene2-us-west.apache.org:45415/data/testSimple1/core_node7/data/tlog",
   "core":"testSimple1_shard2_replica_n4",   
"shared_storage":"true",   "state":"active",   
"leader":"true"}, "core_node8":{   
"dataDir":"hdfs://lucene2-us-west.apache.org:45415/data/testSimple1/core_node8/data/",
   "base_url":"https://127.0.0.1:33948/solr;,   
"node_name":"127.0.0.1:33948_solr",   "type":"NRT",   
"ulogDir":"hdfs://lucene2-us-west.apache.org:45415/data/testSimple1/core_node8/data/tlog",
   "core":"testSimple1_shard2_replica_n6",   
"shared_storage":"true",   "state":"down",   
"router":{"name":"compositeId"},   "maxShardsPerNode":"2",   
"autoAddReplicas":"true",   "nrtReplicas":"2",   "tlogReplicas":"0"}

Stack Trace:
java.lang.AssertionError: Waiting for collection testSimple1
null
Live Nodes: [127.0.0.1:32908_solr, 127.0.0.1:42580_solr]
Last available state: 
DocCollection(testSimple1//collections/testSimple1/state.json/18)={
  "pullReplicas":"0",
  "replicationFactor":"2",
  "shards":{
"shard1":{
  "range":"8000-",
  "state":"active",
  "replicas":{
"core_node3":{
  
"dataDir":"hdfs://lucene2-us-west.apache.org:45415/data/testSimple1/core_node3/data/",
  "base_url":"https://127.0.0.1:32908/solr;,
  "node_name":"127.0.0.1:32908_solr",
  "type":"NRT",
  
"ulogDir":"hdfs://lucene2-us-west.apache.org:45415/data/testSimple1/core_node3/data/tlog",
  "core":"testSimple1_shard1_replica_n1",
  "shared_storage":"true",
  "state":"active",
  "leader":"true"},
"core_node5":{
  
"dataDir":"hdfs://lucene2-us-west.apache.org:45415/data/testSimple1/core_node5/data/",
  "base_url":"https://127.0.0.1:32908/solr;,
  "node_name":"127.0.0.1:32908_solr",
  "type":"NRT",
  
"ulogDir":"hdfs://lucene2-us-west.apache.org:45415/data/testSimple1/core_node5/data/tlog",
  "core":"testSimple1_shard1_replica_n2",
  "shared_storage":"true",
  "state":"active"}}},
"shard2":{
  "range":"0-7fff",
  "state":"active",
  "replicas":{
"core_node7":{
  
"dataDir":"hdfs://lucene2-us-west.apache.org:45415/data/testSimple1/core_node7/data/",
  "base_url":"https://127.0.0.1:32908/solr;,
  "node_name":"127.0.0.1:32908_solr",
  "type":"NRT",
  
"ulogDir":"hdfs://lucene2-us-west.apache.org:45415/data/testSimple1/core_node7/data/tlog",
  "core":"testSimple1_shard2_replica_n4",
  "shared_storage":"true",
  "state":"active",
  "leader":"true"},
"core_node8":{
  
"dataDir":"hdfs://lucene2-us-west.apache.org:45415/data/testSimple1/core_node8/data/",
  "base_url":"https://127.0.0.1:33948/solr;,
  "node_name":"127.0.0.1:33948_solr",
  "type":"NRT",
  
"ulogDir":"hdfs://lucene2-us-west.apache.org:45415/data/testSimple1/core_node8/data/tlog",
  "core":"testSimple1_shard2_replica_n6",

[JENKINS-EA] Lucene-Solr-master-Linux (64bit/jdk-10-ea+43) - Build # 21540 - Still Unstable!

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/21540/
Java: 64bit/jdk-10-ea+43 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC

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

Error Message:


Stack Trace:
java.lang.AssertionError
at 
__randomizedtesting.SeedInfo.seed([34440A0E8887F38E:BC1035D4267B9E76]: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.ReplaceNodeNoTargetTest.test(ReplaceNodeNoTargetTest.java:92)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.base/java.lang.Thread.run(Thread.java:844)


FAILED:  
org.apache.solr.cloud.autoscaling.AutoAddReplicasIntegrationTest.testSimple

Error Message:
Waiting for collection testSimple2 null Live Nodes: [127.0.0.1:43691_solr, 
127.0.0.1:45803_solr] Last available state: 
DocCollection(testSimple2//collections/testSimple2/state.json/15)={   
"pullReplicas":"0",

[JENKINS] Lucene-Solr-repro - Build # 146 - Unstable

Build: https://builds.apache.org/job/Lucene-Solr-repro/146/

[...truncated 31 lines...]
[repro] Jenkins log URL: 
https://builds.apache.org/job/Lucene-Solr-Tests-7.x/461/consoleText

[repro] Revision: 7707e6528ea5c62420df90c63fc52fc8684e4439

[repro] Repro line:  ant test  -Dtestcase=ReplaceNodeNoTargetTest 
-Dtests.method=test -Dtests.seed=1BA016D7001F9189 -Dtests.multiplier=2 
-Dtests.slow=true -Dtests.locale=ar-MA 
-Dtests.timezone=America/Argentina/Catamarca -Dtests.asserts=true 
-Dtests.file.encoding=UTF-8

[repro] Repro line:  ant test  -Dtestcase=ComputePlanActionTest 
-Dtests.method=testSelectedCollections -Dtests.seed=1BA016D7001F9189 
-Dtests.multiplier=2 -Dtests.slow=true -Dtests.locale=sr 
-Dtests.timezone=Asia/Ulaanbaatar -Dtests.asserts=true 
-Dtests.file.encoding=UTF-8

[repro] git rev-parse --abbrev-ref HEAD
[repro] git rev-parse HEAD
[repro] Initial local git branch/revision: 
50c17b92bd2709ac9432dab72dc87f3873603dbc
[repro] git fetch
[repro] git checkout 7707e6528ea5c62420df90c63fc52fc8684e4439

[...truncated 2 lines...]
[repro] git merge --ff-only

[...truncated 1 lines...]
[repro] ant clean

[...truncated 6 lines...]
[repro] Test suites by module:
[repro]solr/core
[repro]   ComputePlanActionTest
[repro]   ReplaceNodeNoTargetTest
[repro] ant compile-test

[...truncated 3310 lines...]
[repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=10 
-Dtests.class="*.ComputePlanActionTest|*.ReplaceNodeNoTargetTest" 
-Dtests.showOutput=onerror  -Dtests.seed=1BA016D7001F9189 -Dtests.multiplier=2 
-Dtests.slow=true -Dtests.locale=sr -Dtests.timezone=Asia/Ulaanbaatar 
-Dtests.asserts=true -Dtests.file.encoding=UTF-8

[...truncated 13561 lines...]
[repro] Setting last failure code to 256

[repro] Failures:
[repro]   0/5 failed: org.apache.solr.cloud.ReplaceNodeNoTargetTest
[repro]   2/5 failed: org.apache.solr.cloud.autoscaling.ComputePlanActionTest
[repro] git checkout 50c17b92bd2709ac9432dab72dc87f3873603dbc

[...truncated 2 lines...]
[repro] Exiting with code 256

[...truncated 6 lines...]

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

what should go in a docValues field?

2018-02-26 Thread Patrick Recchia

Hello all,

I hope I'm in the right place to ask this question.
Seemed to me as this didn't quite qualify for the user's mailing list.
But, if not, feel free to redirect me elsewhere.

The question is: what should we store in a docValues field?

I'm working on the implementation of a InetAddress field type for solr;
leveraging on the' InetAddressPoint sandbox lucene field.
It started as a POC (as we are internally using solr, but feel the need to
index IP Address fields).

It might even qualify as something which might go in the direction of
SOLR-6741; for which I'm planning to offer a patch.

But then I struggle around the following problem:
what should I store within the docValues field?

The problem is that docValues are being used for two different reasons (frm
what I can tell):
- to sort
- and as an optimizatoin when we retrieve only part of the fields of  a set
of documents

Each scenario call for different content.

I see 2 possible options, and am not happy with any of them:

1) string representation:
I could store the string representation of the IP address. e.g. 192.168.1.1
would be stored as "192.168.1.1". as SORTED.
No issue in displaying the field: it is a string. It appears as a string.
Except I would need to normalize it somehow, and then I supose that we
would have 192.168.100.1 < 192.168.11.1 (because '0' < '1').
So wrong choice.

2) binary representation:
I could store the binary representation of the address - which would make
sense because then I could do sorting - really based on the numeric value
of the Address.
So, 192.168.100.1 > 192.168.11.1
But then I face the issue of the representation of the docValues field
(when using fl, for example).
SolrDocumentFetcher.decorateDocValues goes through a long switch to decide
how to render the docValues.
My field (InetAddressType) won't fit into any of these cases.
So I would need to patch also SolrDocumentFetcher to add the representation
for my new Type.
Which I feel a bit odd: I should be able to add a fieldType without the
need to change anyting within the remaining of solr.

So, I see no easy solution neither with 1, nor with 2.
Or is there something I have overlooked, and the solution is actually
pretty simple, but hidden to my (layman) eyes?

Incidentally, I somehow feel that the best would be to have something line
toObject, toExternal, indexedToReadable, etc... for the docValues field,
directly from within FieldType.
That would also clean the long case within the SolrDocumentFetcher.
Again, my feeling? There is, actually, an excellent reason for this long
switch here, rather than a method there?


Thanks to anyone for any clarification.




-- 
One way of describing a computer is as an electric box which hums.
Never ascribe to malice what can be explained by stupidity
--
Patrick Recchia

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

2018-02-26 Thread ASF subversion and git services (JIRA)

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

3 tests failed.
FAILED:  org.apache.solr.cloud.MoveReplicaHDFSTest.testFailedMove

Error Message:
No live SolrServers available to handle this 
request:[http://127.0.0.1:54696/solr/MoveReplicaHDFSTest_failed_coll_true, 
http://127.0.0.1:44752/solr/MoveReplicaHDFSTest_failed_coll_true]

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: No live SolrServers available 
to handle this 
request:[http://127.0.0.1:54696/solr/MoveReplicaHDFSTest_failed_coll_true, 
http://127.0.0.1:44752/solr/MoveReplicaHDFSTest_failed_coll_true]
at 
__randomizedtesting.SeedInfo.seed([2B475370488D918A:818A8082FF5E445A]:0)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:462)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1104)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:884)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:991)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:991)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:817)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:194)
at org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:942)
at 
org.apache.solr.cloud.MoveReplicaTest.testFailedMove(MoveReplicaTest.java:307)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at

Re: Lucene/Solr 7.3

2018-02-26 Thread David Smiley

I think the feature freeze is when the feature branch is created (9th
March), not now

On Mon, Feb 26, 2018 at 2:41 PM Christine Poerschke (BLOOMBERG/ LONDON) <
cpoersc...@bloomberg.net> wrote:

> +1 and I'd like to nominate Kai Chan's
>
>   https://issues.apache.org/jira/browse/SOLR-11633
>
> patch for potential inclusion in 7.3 even though I'm not myself familiar
> with that area of the code.
>
> Christine
>
> - Original Message -
> From: dev@lucene.apache.org
> To: dev@lucene.apache.org
> At: 02/23/18 16:39:16
>
> +1 Thanks!
>
> On Fri, Feb 23, 2018 at 8:36 AM, Joel Bernstein 
> wrote:
> > +1
> >
> > Joel Bernstein
> > http://joelsolr.blogspot.com/
> >
> > On Fri, Feb 23, 2018 at 10:34 AM, Uwe Schindler  wrote:
> >>
> >> +1 Thanks!
> >>
> >> -
> >> Uwe Schindler
> >> Achterdiek 19, D-28357 Bremen
> >> http://www.thetaphi.de
> >> eMail: u...@thetaphi.de
> >>
> >> > -Original Message-
> >> > From: Alan Woodward [mailto:alan.woodw...@romseysoftware.co.uk]
> >> > Sent: Friday, February 23, 2018 10:50 AM
> >> > To: dev@lucene.apache.org
> >> > Subject: Lucene/Solr 7.3
> >> >
> >> > Hi all,
> >> >
> >> > It’s been a couple of months since the 7.2 release, and we’ve
> >> > accumulated
> >> > some nice new features since then.  I’d like to volunteer to be RM
> for a
> >> > 7.3
> >> > release.
> >> >
> >> > I’m travelling for the next couple of weeks, so I would plan to create
> >> > the
> >> > release branch two weeks today, on the 9th March (unless anybody else
> >> > wants to do it sooner, of course :)
> >> >
> >> > - Alan
> >> > -
> >> > 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
> >>
> >
>
> -
> 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] [Commented] (SOLR-11923) Add bicubicSpline Stream Evaluator


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

ASF subversion and git services commented on SOLR-11923:


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

SOLR-11923: Add bicubicSpline Stream Evaluator


> Add bicubicSpline Stream Evaluator
> --
>
> Key: SOLR-11923
> URL: https://issues.apache.org/jira/browse/SOLR-11923
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
>Priority: Major
> Fix For: 7.3
>
> Attachments: SOLR-11923.patch
>
>
> This ticket adds the *bicupicSpline* Stream Evaluator to support computing 
> bicubic splines over a matrix.
> Implementation provided by Apache Commons Math



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (SOLR-11923) Add bicubicSpline Stream Evaluator

2018-02-26 Thread ASF subversion and git services (JIRA)


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

ASF subversion and git services commented on SOLR-11923:


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

SOLR-11923: Add bicubicSpline Stream Evaluator


> Add bicubicSpline Stream Evaluator
> --
>
> Key: SOLR-11923
> URL: https://issues.apache.org/jira/browse/SOLR-11923
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
>Priority: Major
> Fix For: 7.3
>
> Attachments: SOLR-11923.patch
>
>
> This ticket adds the *bicupicSpline* Stream Evaluator to support computing 
> bicubic splines over a matrix.
> Implementation provided by Apache Commons Math



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

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

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

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

Error Message:


Stack Trace:
java.lang.AssertionError
at 
__randomizedtesting.SeedInfo.seed([1BA016D7001F9189:93F4290DAEE3FC71]: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.ReplaceNodeNoTargetTest.test(ReplaceNodeNoTargetTest.java:92)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:748)


FAILED:  
org.apache.solr.cloud.autoscaling.ComputePlanActionTest.testSelectedCollections

Error Message:
The operations computed by ComputePlanAction should not be 
nullSolrClientNodeStateProvider.DEBUG{AFTER_ACTION=[compute_plan, null], 
BEFORE_ACTION=[compute_plan, null]}

Stack Trace:
java.lang.AssertionError: The operations computed by ComputePlanAction should 
not be

[jira] [Commented] (SOLR-10686) improve pattern in examples' log4j.properties


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

Erick Erickson commented on SOLR-10686:
---

It's still a germane question why we have two of these, one in example and one 
in server. Pinging again in case anyone knows why we have two.

> improve pattern in examples' log4j.properties 
> --
>
> Key: SOLR-10686
> URL: https://issues.apache.org/jira/browse/SOLR-10686
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Mikhail Khludnev
>Priority: Major
> Attachments: SOLR-10686.patch
>
>
> At comparison to {{server/resources/log4j.properties}} 
> {{solr/example/resources/log4j.properties}} lacks thread name and uses {{%C}} 
> which is well known performance pitfall.  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[JENKINS] Lucene-Solr-7.x-Linux (64bit/jdk1.8.0_162) - Build # 1434 - Still Unstable!

2018-02-26 Thread Christine Poerschke (BLOOMBERG/ LONDON)

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/1434/
Java: 64bit/jdk1.8.0_162 -XX:-UseCompressedOops -XX:+UseG1GC

10 tests failed.
FAILED:  org.apache.solr.cloud.TestUtilizeNode.test

Error Message:
no replica should be present in  127.0.0.1:37241_solr

Stack Trace:
java.lang.AssertionError: no replica should be present in  127.0.0.1:37241_solr
at 
__randomizedtesting.SeedInfo.seed([DB3D85681426B60E:5369BAB2BADADBF6]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.apache.solr.cloud.TestUtilizeNode.test(TestUtilizeNode.java:99)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:748)


FAILED:  org.apache.solr.cloud.autoscaling.ComputePlanActionTest.testNodeLost

Error Message:
Trigger was not fired even after 10 seconds

Stack Trace:
java.lang.AssertionError: Trigger was not fired even after 10 seconds
at

[jira] [Commented] (LUCENE-6271) PostingsEnum should have consistent flags behavior

2018-02-26 Thread David Smiley (JIRA)


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

David Smiley commented on LUCENE-6271:
--

I think in this issue we forgot to update the javadocs of 
org.apache.lucene.index.TermsEnum#postings(org.apache.lucene.index.PostingsEnum,
 int) to remove mention of null being a valid return; it should be flipped to 
say it isn't valid, just like the overloaded one without the flags says.  For a 
while I thought it was valid and I kept guarding against it and in one case 
wrote some ugly loop that downgrades bits until non-null.  I don't believe it 
happened in practice but the docs allowed it so...

[~rjernst] If you don't want to do it or are too busy, I could simply update 
the javadocs on master & 7x.
CC [~romseygeek] as LUCENE-4524 was highly related and was the commit that 
actually has the current javadocs about null being permitted.

> PostingsEnum should have consistent flags behavior
> --
>
> Key: LUCENE-6271
> URL: https://issues.apache.org/jira/browse/LUCENE-6271
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Ryan Ernst
>Assignee: Robert Muir
>Priority: Major
> Fix For: 5.1
>
> Attachments: LUCENE-6271.patch, LUCENE-6271.patch
>
>
> When asking for flags like OFFSETS or PAYLOADS with DocsAndPositionsEnum, the 
> behavior was to always return an enum, even if offsets or payloads were not 
> indexed.  They would just not be available from the enum if they were not 
> present.  This behavior was carried over to PostingsEnum, which is good.
> However, the new POSITIONS flag has different behavior.  If positions are not 
> available, null is returned, instead of a PostingsEnum that just gives access 
> to freqs.  This behavior is confusing, as it means you have to special case 
> asking for positions (only ask if you know they were indexed) which sort of 
> defeats the purpose of the unified PostingsEnum.
> We should make POSITIONS have the same behavior as other flags. The trickiest 
> part will be maintaining backcompat for DocsAndPositionsEnum in 5.x, but I 
> think it can be done.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

Re: Lucene/Solr 7.3

+1 and I'd like to nominate Kai Chan's

  https://issues.apache.org/jira/browse/SOLR-11633

patch for potential inclusion in 7.3 even though I'm not myself familiar with 
that area of the code.

Christine

- Original Message -
From: dev@lucene.apache.org
To: dev@lucene.apache.org
At: 02/23/18 16:39:16

+1 Thanks!

On Fri, Feb 23, 2018 at 8:36 AM, Joel Bernstein  wrote:
> +1
>
> Joel Bernstein
> http://joelsolr.blogspot.com/
>
> On Fri, Feb 23, 2018 at 10:34 AM, Uwe Schindler  wrote:
>>
>> +1 Thanks!
>>
>> -
>> Uwe Schindler
>> Achterdiek 19, D-28357 Bremen
>> http://www.thetaphi.de
>> eMail: u...@thetaphi.de
>>
>> > -Original Message-
>> > From: Alan Woodward [mailto:alan.woodw...@romseysoftware.co.uk]
>> > Sent: Friday, February 23, 2018 10:50 AM
>> > To: dev@lucene.apache.org
>> > Subject: Lucene/Solr 7.3
>> >
>> > Hi all,
>> >
>> > It’s been a couple of months since the 7.2 release, and we’ve
>> > accumulated
>> > some nice new features since then.  I’d like to volunteer to be RM for a
>> > 7.3
>> > release.
>> >
>> > I’m travelling for the next couple of weeks, so I would plan to create
>> > the
>> > release branch two weeks today, on the 9th March (unless anybody else
>> > wants to do it sooner, of course :)
>> >
>> > - Alan
>> > -
>> > 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
>>
>

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

[jira] [Updated] (SOLR-12036) factor out DefaultStreamFactory class


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

Christine Poerschke updated SOLR-12036:
---
Component/s: streaming expressions

> factor out DefaultStreamFactory class
> -
>
> Key: SOLR-12036
> URL: https://issues.apache.org/jira/browse/SOLR-12036
> Project: Solr
>  Issue Type: Task
>  Components: streaming expressions
>Reporter: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-12036.patch
>
>
> Motivation for the proposed class is to reduce the need for 
> {{withFunctionName}} method calls in client code.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (SOLR-12036) factor out DefaultStreamFactory class


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

Christine Poerschke commented on SOLR-12036:


Attached illustrative patch - more or even all (solrj) function names from 
{{StreamHandler}} could be added to {{DefaultStreamFactory}} potentially.

[~joel.bernstein], [~dpgove] - what do you think?

> factor out DefaultStreamFactory class
> -
>
> Key: SOLR-12036
> URL: https://issues.apache.org/jira/browse/SOLR-12036
> Project: Solr
>  Issue Type: Task
>Reporter: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-12036.patch
>
>
> Motivation for the proposed class is to reduce the need for 
> {{withFunctionName}} method calls in client code.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Updated] (SOLR-12036) factor out DefaultStreamFactory class


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

Christine Poerschke updated SOLR-12036:
---
Attachment: SOLR-12036.patch

> factor out DefaultStreamFactory class
> -
>
> Key: SOLR-12036
> URL: https://issues.apache.org/jira/browse/SOLR-12036
> Project: Solr
>  Issue Type: Task
>Reporter: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-12036.patch
>
>
> Motivation for the proposed class is to reduce the need for 
> {{withFunctionName}} method calls in client code.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Created] (SOLR-12036) factor out DefaultStreamFactory class

Christine Poerschke created SOLR-12036:
--

 Summary: factor out DefaultStreamFactory class
 Key: SOLR-12036
 URL: https://issues.apache.org/jira/browse/SOLR-12036
 Project: Solr
  Issue Type: Task
Reporter: Christine Poerschke


Motivation for the proposed class is to reduce the need for 
{{withFunctionName}} method calls in client code.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Updated] (SOLR-11923) Add bicubicSpline Stream Evaluator


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

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

> Add bicubicSpline Stream Evaluator
> --
>
> Key: SOLR-11923
> URL: https://issues.apache.org/jira/browse/SOLR-11923
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
>Priority: Major
> Fix For: 7.3
>
> Attachments: SOLR-11923.patch
>
>
> This ticket adds the *bicupicSpline* Stream Evaluator to support computing 
> bicubic splines over a matrix.
> Implementation provided by Apache Commons Math



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (SOLR-11923) Add bicubicSpline Stream Evaluator


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

Joel Bernstein commented on SOLR-11923:
---

Added patch with initial implementation and tests.

> Add bicubicSpline Stream Evaluator
> --
>
> Key: SOLR-11923
> URL: https://issues.apache.org/jira/browse/SOLR-11923
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
>Priority: Major
> Fix For: 7.3
>
> Attachments: SOLR-11923.patch
>
>
> This ticket adds the *bicupicSpline* Stream Evaluator to support computing 
> bicubic splines over a matrix.
> Implementation provided by Apache Commons Math



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Updated] (SOLR-11923) Add bicubicSpline Stream Evaluator


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

Joel Bernstein updated SOLR-11923:
--
Description: 
This ticket adds the *bicupicSpline* Stream Evaluator to support computing 
bicubic splines over a matrix.

Implementation provided by Apache Commons Math

  was:
This ticket adds the *bicupicSpline* Stream Evaluator to support computing 
bicubic spline over a matrix.

Implementation provided by Apache Commons Math


> Add bicubicSpline Stream Evaluator
> --
>
> Key: SOLR-11923
> URL: https://issues.apache.org/jira/browse/SOLR-11923
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
>Priority: Major
> Fix For: 7.3
>
>
> This ticket adds the *bicupicSpline* Stream Evaluator to support computing 
> bicubic splines over a matrix.
> Implementation provided by Apache Commons Math



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Assigned] (SOLR-11923) Add bicubicSpline Stream Evaluator


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

Joel Bernstein reassigned SOLR-11923:
-

Assignee: Joel Bernstein

> Add bicubicSpline Stream Evaluator
> --
>
> Key: SOLR-11923
> URL: https://issues.apache.org/jira/browse/SOLR-11923
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
>Priority: Major
> Fix For: 7.3
>
>
> This ticket adds the *bicupicSpline* Stream Evaluator to support computing 
> bicubic spline over a matrix.
> Implementation provided by Apache Commons Math



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Updated] (SOLR-11923) Add bicubicSpline Stream Evaluator


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

Joel Bernstein updated SOLR-11923:
--
Fix Version/s: 7.3

> Add bicubicSpline Stream Evaluator
> --
>
> Key: SOLR-11923
> URL: https://issues.apache.org/jira/browse/SOLR-11923
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
>Priority: Major
> Fix For: 7.3
>
>
> This ticket adds the *bicupicSpline* Stream Evaluator to support computing 
> bicubic spline over a matrix.
> Implementation provided by Apache Commons Math



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (SOLR-11752) add gzip to jetty

2018-02-26 Thread Shawn Heisey (JIRA)


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

Shawn Heisey commented on SOLR-11752:
-

[~mbraun688], you are correct.  [~msporleder] probably didn't find that issue 
before creating this one.

Unelss [~janhoy] objects, I will continue with the work on this issue and close 
the other as a duplicate once I've completed it.  I prefer the approach in the 
patch on this issue -- enabling it for the entire server, not just the Solr 
webapp.


> add gzip to jetty
> -
>
> Key: SOLR-11752
> URL: https://issues.apache.org/jira/browse/SOLR-11752
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Server
>Affects Versions: master (8.0)
>Reporter: Matthew Sporleder
>Priority: Trivial
>  Labels: jetty
> Attachments: SOLR-11752.patch, SOLR-11752.patch
>
>
> with a little bit of typing I am able to add gzip to my solr's jetty, which 
> is a big help for SAN access and completely out-of-band to solr, *and* only 
> happens if the client requests it so I think it is is a good default.
> I will just inline my code to this ticket:
> {code}
> #server/etc/jetty-gzip.xml
> #just download it from here: 
> http://grepcode.com/file/repo1.maven.org/maven2/org.eclipse.jetty/jetty-server/9.3.0.v20150612/etc/jetty-gzip.xml?av=f
> {code}
> {code}
> #server/modules/gzip.mod
> [depend]
> server
> [xml]
> etc/jetty-gzip.xml
> {code}
> This is where you might want to add an option, but the result should look 
> like this:
> {code}
> #bin/solr
> else
>   SOLR_JETTY_CONFIG+=("--module=http,gzip")
> fi
> {code}
> I can now do this:
> {code}
> curl -vvv --compressed localhost:8983/solr/ > /dev/null
> {code}
> With:
> {code}
> < Content-Encoding: gzip
> < Content-Length: 2890
> {code}
> Without:
> {code}
> < Content-Length: 13349
> {code}
> ---
> A regular query:
> With:
> {code}
> < Content-Encoding: gzip
> < Content-Length: 2876
> {code}
> Without:
> {code}
> < Content-Length: 17761
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[JENKINS] Lucene-Solr-repro - Build # 144 - Unstable

Build: https://builds.apache.org/job/Lucene-Solr-repro/144/

[...truncated 28 lines...]
[repro] Jenkins log URL: 
https://builds.apache.org/job/Lucene-Solr-SmokeRelease-master/964/consoleText

[repro] Revision: a2eb7f388009b9fd0bda356fdf51e52d525124d2

[repro] Repro line:  ant test  -Dtestcase=TriggerIntegrationTest 
-Dtests.method=testEventQueue -Dtests.seed=EE70AACE0E488CFF 
-Dtests.multiplier=2 -Dtests.locale=el-GR -Dtests.timezone=Etc/GMT+0 
-Dtests.asserts=true -Dtests.file.encoding=UTF-8

[repro] Ant options: -DsmokeTestRelease.java9=/home/jenkins/tools/java/latest1.9
[repro] git rev-parse --abbrev-ref HEAD
[repro] git rev-parse HEAD
[repro] Initial local git branch/revision: 
e08eac421a19f148f2ac149bc5ebcc121cdea51f
[repro] git fetch
[repro] git checkout a2eb7f388009b9fd0bda356fdf51e52d525124d2

[...truncated 2 lines...]
[repro] git merge --ff-only

[...truncated 1 lines...]
[repro] ant clean

[...truncated 6 lines...]
[repro] Test suites by module:
[repro]solr/core
[repro]   TriggerIntegrationTest
[repro] ant compile-test

[...truncated 3292 lines...]
[repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=5 
-Dtests.class="*.TriggerIntegrationTest" -Dtests.showOutput=onerror 
-DsmokeTestRelease.java9=/home/jenkins/tools/java/latest1.9 
-Dtests.seed=EE70AACE0E488CFF -Dtests.multiplier=2 -Dtests.locale=el-GR 
-Dtests.timezone=Etc/GMT+0 -Dtests.asserts=true -Dtests.file.encoding=UTF-8

[...truncated 11698 lines...]
[repro] Setting last failure code to 256

[repro] Failures:
[repro]   2/5 failed: org.apache.solr.cloud.autoscaling.TriggerIntegrationTest
[repro] git checkout e08eac421a19f148f2ac149bc5ebcc121cdea51f

[...truncated 2 lines...]
[repro] Exiting with code 256

[...truncated 6 lines...]

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

[JENKINS] Lucene-Solr-Tests-master - Build # 2382 - Still Unstable

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

2 tests failed.
FAILED:  org.apache.solr.cloud.MoveReplicaHDFSTest.testFailedMove

Error Message:
No live SolrServers available to handle this 
request:[http://127.0.0.1:45063/solr/MoveReplicaHDFSTest_failed_coll_true, 
http://127.0.0.1:59130/solr/MoveReplicaHDFSTest_failed_coll_true, 
http://127.0.0.1:55992/solr/MoveReplicaHDFSTest_failed_coll_true]

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: No live SolrServers available 
to handle this 
request:[http://127.0.0.1:45063/solr/MoveReplicaHDFSTest_failed_coll_true, 
http://127.0.0.1:59130/solr/MoveReplicaHDFSTest_failed_coll_true, 
http://127.0.0.1:55992/solr/MoveReplicaHDFSTest_failed_coll_true]
at 
__randomizedtesting.SeedInfo.seed([E5072BF17F206E5E:4FCAF803C8F3BB8E]:0)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:462)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1104)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:884)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:991)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:817)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:194)
at org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:942)
at 
org.apache.solr.cloud.MoveReplicaTest.testFailedMove(MoveReplicaTest.java:309)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)

PointValues ordering

2018-02-26 Thread Dominik Safaric

Given a multi-valued and non-indexed point value field, how does Lucene 
internally store this kind of fields, in terms or order and may they be 
retrieved in the same order as stored? For example, given a document and an 
associated field equal to plongField: [1,2,3], and using a DocIdSetIterator, 
how can I retrieve these values in the same order as inserted during for 
example scoring using a CustomScoreProvider?

Cheers,
Dominik

[jira] [Updated] (SOLR-12035) ExtendedDismaxQParser fails to include charfilters in nostopanalyzer


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

Tim Allison updated SOLR-12035:
---
Affects Version/s: master (8.0)

> ExtendedDismaxQParser fails to include charfilters in nostopanalyzer
> 
>
> Key: SOLR-12035
> URL: https://issues.apache.org/jira/browse/SOLR-12035
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: query parsers
>Affects Versions: master (8.0)
>Reporter: Tim Allison
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> In some circumstances, the ExtendedDismaxQParser tries to remove stop filters 
> from the TokenizerChain.  When building the new analyzer without the stop 
> filters, the charfilters from the original TokenizerChain are not copied over.
> The fix is trivial.
> {noformat}
> -  TokenizerChain newa = new TokenizerChain(tcq.getTokenizerFactory(), 
> newtf);
> + TokenizerChain newa = new TokenizerChain(tcq.getCharFilterFactories(), 
> tcq.getTokenizerFactory(), newtf);
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Updated] (SOLR-12035) ExtendedDismaxQParser fails to include charfilters in nostopanalyzer


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

Tim Allison updated SOLR-12035:
---
Component/s: query parsers

> ExtendedDismaxQParser fails to include charfilters in nostopanalyzer
> 
>
> Key: SOLR-12035
> URL: https://issues.apache.org/jira/browse/SOLR-12035
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: query parsers
>Affects Versions: master (8.0)
>Reporter: Tim Allison
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> In some circumstances, the ExtendedDismaxQParser tries to remove stop filters 
> from the TokenizerChain.  When building the new analyzer without the stop 
> filters, the charfilters from the original TokenizerChain are not copied over.
> The fix is trivial.
> {noformat}
> -  TokenizerChain newa = new TokenizerChain(tcq.getTokenizerFactory(), 
> newtf);
> + TokenizerChain newa = new TokenizerChain(tcq.getCharFilterFactories(), 
> tcq.getTokenizerFactory(), newtf);
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[GitHub] lucene-solr pull request #329: SOLR-12035

2018-02-26 Thread tballison

GitHub user tballison opened a pull request:

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

SOLR-12035

don't forget to copy charfilters into nostopanalyzer

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

$ git pull https://github.com/tballison/lucene-solr jira/SOLR-12035

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

https://github.com/apache/lucene-solr/pull/329.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 #329


commit c024cd87facde89344941a114b6231321b2b68ea
Author: tballison 
Date:   2018-02-26T18:14:33Z

SOLR-12035 -- don't forget to copy charfilters into nostopanalyzer




---

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

[jira] [Created] (SOLR-12035) ExtendedDismaxQParser fails to include charfilters in nostopanalyzer

Tim Allison created SOLR-12035:
--

 Summary: ExtendedDismaxQParser fails to include charfilters in 
nostopanalyzer
 Key: SOLR-12035
 URL: https://issues.apache.org/jira/browse/SOLR-12035
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Tim Allison


In some circumstances, the ExtendedDismaxQParser tries to remove stop filters 
from the TokenizerChain.  When building the new analyzer without the stop 
filters, the charfilters from the original TokenizerChain are not copied over.

The fix is trivial.
{noformat}
-  TokenizerChain newa = new TokenizerChain(tcq.getTokenizerFactory(), 
newtf);
+ TokenizerChain newa = new TokenizerChain(tcq.getCharFilterFactories(), 
tcq.getTokenizerFactory(), newtf);
{noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (SOLR-12028) BadApple and AwaitsFix annotations usage


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

Erick Erickson commented on SOLR-12028:
---

I think this is ready to check in, I'll do that later today along with Uwe's 
changes to the build system. From there we can refine how we work on the 
backlog.

> BadApple and AwaitsFix annotations usage
> 
>
> Key: SOLR-12028
> URL: https://issues.apache.org/jira/browse/SOLR-12028
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Tests
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Major
> Attachments: SOLR-12016-buildsystem.patch, SOLR-12028.patch
>
>
> There's a long discussion of this topic at SOLR-12016. Here's a summary:
> - BadApple annotations are used for tests that intermittently fail, say < 30% 
> of the time. Tests that fail more often shold be moved to AwaitsFix. This is, 
> of course, a judgement call
> - AwaitsFix annotations are used for tests that, for some reason, the problem 
> can't be fixed immediately. Likely reasons are third-party dependencies, 
> extreme difficulty tracking down, dependency on another JIRA etc.
> Jenkins jobs will typically run with BadApple disabled to cut down on noise. 
> Periodically Jenkins jobs will be run with BadApples enabled so BadApple 
> tests won't be lost and reports can be generated. Tests that run with 
> BadApples disabled that fail require _immediate_ attention.
> The default for developers is that BadApple is enabled.
> If you are working on one of these tests and cannot get the test to fail 
> locally, it is perfectly acceptable to comment the annotation out. You should 
> let the dev list know that this is deliberate.
> This JIRA is a placeholder for BadApple tests to point to between the times 
> they're identified as BadApple and they're either fixed or changed to 
> AwaitsFix or assigned their own JIRA.
> I've assigned this to myself to track so I don't lose track of it. No one 
> person will fix all of these issues, this will be an ongoing technical debt 
> cleanup effort.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (SOLR-11981) Multiple kerberos name rules can not be passed with SOLR_AUTHENTICATION_OPTS

2018-02-26 Thread JIRA


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

Olivér Szabó commented on SOLR-11981:
-

Probably the reason could be that variable was set in a file and then its 
formatted multiple times after that,as the -D will be added into SOLR_OPTS 
anyway in the end

> Multiple kerberos name rules can not be passed with SOLR_AUTHENTICATION_OPTS
> 
>
> Key: SOLR-11981
> URL: https://issues.apache.org/jira/browse/SOLR-11981
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: security
>Affects Versions: 5.5.5, 6.6.2, 7.2.1
>Reporter: Olivér Szabó
>Priority: Major
>
> On secure env, when multiline (or space separated) kerberos name rules are 
> used ( in solr.in),  those values cannot be passed to .the start script 
> properly. (using {{org.apache.solr.security.KerberosPlugin}})
> Example:
> {code:java}
> SOLR_JAAS_FILE=solr.jaas
> SOLR_KERB_KEYTAB=/etc/security/keytabs/solr.keytab
> SOLR_KERB_PRINCIPAL=solr/myhost1@example.com
> SOLR_KERB_NAME_RULES="RULE:[1:$1@$0](.*@ADMIN.EXAMPLE.NET)s/@.*///L 
> RULE:[1:$1@$0](.*@PROD.EXAMPLE.NET)s/@.*///L 
> RULE:[2:$1@$0](s...@admin.example.net)s/.*/solr/"
> SOLR_AUTHENTICATION_CLIENT_CONFIGURER="org.apache.solr.client.solrj.impl.Krb5HttpClientConfigurer"
> SOLR_AUTHENTICATION_OPTS=" 
> -DauthenticationPlugin=org.apache.solr.security.KerberosPlugin 
> -Djava.security.auth.login.config=$SOLR_JAAS_FILE 
> -Dsolr.kerberos.principal=${SOLR_KERB_PRINCIPAL} 
> -Dsolr.kerberos.keytab=${SOLR_KERB_KEYTAB} 
> -Dsolr.kerberos.cookie.domain=${SOLR_HOST}" 
> -Dsolr.kerberos.name.rules=${SOLR_KERB_NAME_RULES}
> {code}
> that will cause:
> {code:java}
> Caused by: 
> org.apache.hadoop.security.authentication.util.KerberosName$NoMatchingRule: 
> No rules applied to solr/host.exam...@admin.example.net 
> at 
> org.apache.hadoop.security.authentication.util.KerberosName.getShortName(KerberosName.java:389)
>  
> at 
> org.apache.hadoop.security.authentication.server.KerberosAuthenticationHandler
> {code}
> Reason for that (probably): in solr start script, there are multiple 
> {{"${SOLR_OPTS[@]}}}-like (for auth props as well), which magically handle 
> variables as arrays (separated by space or endlines).
> I have tried to add {{solr.kerberos.name.rules}} property directly to 
> SOLR_OPTS instead of SOLR_AUTHENTICATION_OPTS, but i could not using 
> spaces/newlines there even with quotes or escape characters.
> With Ambari we faced this issue before: 
> https://issues.apache.org/jira/browse/AMBARI-18898, the quick solution was to 
> patch the start script to use 
> {{-Dsolr.kerberos.name.rules="$SOLR_KERB_NAME_RULES"}} directly where the 
> scripts starts the java process
> You can close this jira invalid if there is a workaround for that issue or 
> fixed already, if not, then my proposed solution to do something similar. 
> (maybe there are better places where to put that variable)



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (SOLR-11981) Multiple kerberos name rules can not be passed with SOLR_AUTHENTICATION_OPTS

2018-02-26 Thread Amrit Sarkar (JIRA)


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

Amrit Sarkar commented on SOLR-11981:
-

Thanks Oliver, helpful and surprising at the same time, it doesn't work with 
SOLR_OPTS.

> Multiple kerberos name rules can not be passed with SOLR_AUTHENTICATION_OPTS
> 
>
> Key: SOLR-11981
> URL: https://issues.apache.org/jira/browse/SOLR-11981
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: security
>Affects Versions: 5.5.5, 6.6.2, 7.2.1
>Reporter: Olivér Szabó
>Priority: Major
>
> On secure env, when multiline (or space separated) kerberos name rules are 
> used ( in solr.in),  those values cannot be passed to .the start script 
> properly. (using {{org.apache.solr.security.KerberosPlugin}})
> Example:
> {code:java}
> SOLR_JAAS_FILE=solr.jaas
> SOLR_KERB_KEYTAB=/etc/security/keytabs/solr.keytab
> SOLR_KERB_PRINCIPAL=solr/myhost1@example.com
> SOLR_KERB_NAME_RULES="RULE:[1:$1@$0](.*@ADMIN.EXAMPLE.NET)s/@.*///L 
> RULE:[1:$1@$0](.*@PROD.EXAMPLE.NET)s/@.*///L 
> RULE:[2:$1@$0](s...@admin.example.net)s/.*/solr/"
> SOLR_AUTHENTICATION_CLIENT_CONFIGURER="org.apache.solr.client.solrj.impl.Krb5HttpClientConfigurer"
> SOLR_AUTHENTICATION_OPTS=" 
> -DauthenticationPlugin=org.apache.solr.security.KerberosPlugin 
> -Djava.security.auth.login.config=$SOLR_JAAS_FILE 
> -Dsolr.kerberos.principal=${SOLR_KERB_PRINCIPAL} 
> -Dsolr.kerberos.keytab=${SOLR_KERB_KEYTAB} 
> -Dsolr.kerberos.cookie.domain=${SOLR_HOST}" 
> -Dsolr.kerberos.name.rules=${SOLR_KERB_NAME_RULES}
> {code}
> that will cause:
> {code:java}
> Caused by: 
> org.apache.hadoop.security.authentication.util.KerberosName$NoMatchingRule: 
> No rules applied to solr/host.exam...@admin.example.net 
> at 
> org.apache.hadoop.security.authentication.util.KerberosName.getShortName(KerberosName.java:389)
>  
> at 
> org.apache.hadoop.security.authentication.server.KerberosAuthenticationHandler
> {code}
> Reason for that (probably): in solr start script, there are multiple 
> {{"${SOLR_OPTS[@]}}}-like (for auth props as well), which magically handle 
> variables as arrays (separated by space or endlines).
> I have tried to add {{solr.kerberos.name.rules}} property directly to 
> SOLR_OPTS instead of SOLR_AUTHENTICATION_OPTS, but i could not using 
> spaces/newlines there even with quotes or escape characters.
> With Ambari we faced this issue before: 
> https://issues.apache.org/jira/browse/AMBARI-18898, the quick solution was to 
> patch the start script to use 
> {{-Dsolr.kerberos.name.rules="$SOLR_KERB_NAME_RULES"}} directly where the 
> scripts starts the java process
> You can close this jira invalid if there is a workaround for that issue or 
> fixed already, if not, then my proposed solution to do something similar. 
> (maybe there are better places where to put that variable)



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Updated] (LUCENE-8186) CustomAnalyzer with a LowerCaseTokenizerFactory fails to normalize multiterms


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

Tim Allison updated LUCENE-8186:

Description: 
While working on SOLR-12034, a unit test that relied on the 
LowerCaseTokenizerFactory failed.

After some digging, I was able to replicate this at the Lucene level.

Unit test:
{noformat}
  @Test
  public void testLCTokenizerFactoryNormalize() throws Exception {

Analyzer analyzer =  
CustomAnalyzer.builder().withTokenizer(LowerCaseTokenizerFactory.class).build();

//fails
assertEquals(new BytesRef("hello"), analyzer.normalize("f", "Hello"));

//now try an integration test with the classic query parser
QueryParser p = new QueryParser("f", analyzer);
Query q = p.parse("Hello");
//passes
assertEquals(new TermQuery(new Term("f", "hello")), q);

q = p.parse("Hello*");
//fails
assertEquals(new PrefixQuery(new Term("f", "hello")), q);

q = p.parse("Hel*o");
//fails
assertEquals(new WildcardQuery(new Term("f", "hel*o")), q);
  }
{noformat}

The problem is that the CustomAnalyzer iterates through the tokenfilters, but 
does not call the tokenizer, which, in the case of the LowerCaseTokenizer, does 
the filtering work.

  was:
While working on SOLR-12034, a unit test that relied on the 
LowerCaseTokenizerFactory failed.

After some digging, I was able to replicate this at the Lucene level.

Unit test:
{noformat}
  @Test
  public void testLCTokenizerFactoryNormalize() throws Exception {

Analyzer analyzer = CustomAnalyzer.builder().withTokenizer(new 
LowerCaseTokenizerFactory(Collections.EMPTY_MAP)).build();

//fails
assertEquals(new BytesRef("hello"), analyzer.normalize("f", "Hello"));

//now try an integration test with the classic query parser
QueryParser p = new QueryParser("f", analyzer);
Query q = p.parse("Hello");
//passes
assertEquals(new TermQuery(new Term("f", "hello")), q);

q = p.parse("Hello*");
//fails
assertEquals(new PrefixQuery(new Term("f", "hello")), q);

q = p.parse("Hel*o");
//fails
assertEquals(new WildcardQuery(new Term("f", "hel*o")), q);
  }
{noformat}

The problem is that the CustomAnalyzer iterates through the tokenfilters, but 
does not call the tokenizer, which, in the case of the LowerCaseTokenizer, does 
the filtering work.


> CustomAnalyzer with a LowerCaseTokenizerFactory fails to normalize multiterms 
> --
>
> Key: LUCENE-8186
> URL: https://issues.apache.org/jira/browse/LUCENE-8186
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Tim Allison
>Priority: Minor
>
> While working on SOLR-12034, a unit test that relied on the 
> LowerCaseTokenizerFactory failed.
> After some digging, I was able to replicate this at the Lucene level.
> Unit test:
> {noformat}
>   @Test
>   public void testLCTokenizerFactoryNormalize() throws Exception {
> Analyzer analyzer =  
> CustomAnalyzer.builder().withTokenizer(LowerCaseTokenizerFactory.class).build();
> //fails
> assertEquals(new BytesRef("hello"), analyzer.normalize("f", "Hello"));
> 
> //now try an integration test with the classic query parser
> QueryParser p = new QueryParser("f", analyzer);
> Query q = p.parse("Hello");
> //passes
> assertEquals(new TermQuery(new Term("f", "hello")), q);
> q = p.parse("Hello*");
> //fails
> assertEquals(new PrefixQuery(new Term("f", "hello")), q);
> q = p.parse("Hel*o");
> //fails
> assertEquals(new WildcardQuery(new Term("f", "hel*o")), q);
>   }
> {noformat}
> The problem is that the CustomAnalyzer iterates through the tokenfilters, but 
> does not call the tokenizer, which, in the case of the LowerCaseTokenizer, 
> does the filtering work.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Updated] (LUCENE-8186) CustomAnalyzer with a LowerCaseTokenizerFactory fails to normalize multiterms


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

Tim Allison updated LUCENE-8186:

Description: 
While working on SOLR-12034, a unit test that relied on the 
LowerCaseTokenizerFactory failed.

After some digging, I was able to replicate this at the Lucene level.

Unit test:
{noformat}
  @Test
  public void testLCTokenizerFactoryNormalize() throws Exception {

Analyzer analyzer = CustomAnalyzer.builder().withTokenizer(new 
LowerCaseTokenizerFactory(Collections.EMPTY_MAP)).build();

//fails
assertEquals(new BytesRef("hello"), analyzer.normalize("f", "Hello"));

//now try an integration test with the classic query parser
QueryParser p = new QueryParser("f", analyzer);
Query q = p.parse("Hello");
//passes
assertEquals(new TermQuery(new Term("f", "hello")), q);

q = p.parse("Hello*");
//fails
assertEquals(new PrefixQuery(new Term("f", "hello")), q);

q = p.parse("Hel*o");
//fails
assertEquals(new WildcardQuery(new Term("f", "hel*o")), q);
  }
{noformat}

The problem is that the CustomAnalyzer iterates through the tokenfilters, but 
does not call the tokenizer, which, in the case of the LowerCaseTokenizer, does 
the filtering work.

  was:
While working on SOLR-12034, a unit test that relied on the 
LowerCaseTokenizerFactory failed.

After some digging, I was able to replicate this at the Lucene level.

Unit test:
{noformat}
  @Test
  public void testLCTokenizerFactoryNormalize() throws Exception {

Analyzer analyzer = CustomAnalyzer.builder().withTokenizer(new 
LowerCaseTokenizerFactory(Collections.EMPTY_MAP)).build();

//fails
assertEquals(new BytesRef("hello"), analyzer.normalize("f", "Hello"));

//now try an integration test with the classic query parser
QueryParser p = new QueryParser("f", analyzer);
Query q = p.parse("Hello");
//passes
assertEquals(new TermQuery(new Term("f", "hello")), q);

q = p.parse("Hello*");
//fails
assertEquals(new PrefixQuery(new Term("f", "hello")), q);

q = p.parse("Hel*o");
//fails
assertEquals(new WildcardQuery(new Term("f", "hel*o")), q);
  }
{noformat}

The problem is that the CustomAnalyzer iterates through the tokenfilters, but 
does not call the tokenizer, which, in the case of the LowerCaseAnalyzer, does 
the filtering work.


> CustomAnalyzer with a LowerCaseTokenizerFactory fails to normalize multiterms 
> --
>
> Key: LUCENE-8186
> URL: https://issues.apache.org/jira/browse/LUCENE-8186
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Tim Allison
>Priority: Minor
>
> While working on SOLR-12034, a unit test that relied on the 
> LowerCaseTokenizerFactory failed.
> After some digging, I was able to replicate this at the Lucene level.
> Unit test:
> {noformat}
>   @Test
>   public void testLCTokenizerFactoryNormalize() throws Exception {
> Analyzer analyzer = CustomAnalyzer.builder().withTokenizer(new 
> LowerCaseTokenizerFactory(Collections.EMPTY_MAP)).build();
> //fails
> assertEquals(new BytesRef("hello"), analyzer.normalize("f", "Hello"));
> 
> //now try an integration test with the classic query parser
> QueryParser p = new QueryParser("f", analyzer);
> Query q = p.parse("Hello");
> //passes
> assertEquals(new TermQuery(new Term("f", "hello")), q);
> q = p.parse("Hello*");
> //fails
> assertEquals(new PrefixQuery(new Term("f", "hello")), q);
> q = p.parse("Hel*o");
> //fails
> assertEquals(new WildcardQuery(new Term("f", "hel*o")), q);
>   }
> {noformat}
> The problem is that the CustomAnalyzer iterates through the tokenfilters, but 
> does not call the tokenizer, which, in the case of the LowerCaseTokenizer, 
> does the filtering work.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Created] (LUCENE-8186) CustomAnalyzer with a LowerCaseTokenizerFactory fails to normalize multiterms

Tim Allison created LUCENE-8186:
---

 Summary: CustomAnalyzer with a LowerCaseTokenizerFactory fails to 
normalize multiterms 
 Key: LUCENE-8186
 URL: https://issues.apache.org/jira/browse/LUCENE-8186
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Tim Allison


While working on SOLR-12034, a unit test that relied on the 
LowerCaseTokenizerFactory failed.

After some digging, I was able to replicate this at the Lucene level.

Unit test:
{noformat}
  @Test
  public void testLCTokenizerFactoryNormalize() throws Exception {

Analyzer analyzer = CustomAnalyzer.builder().withTokenizer(new 
LowerCaseTokenizerFactory(Collections.EMPTY_MAP)).build();

//fails
assertEquals(new BytesRef("hello"), analyzer.normalize("f", "Hello"));

//now try an integration test with the classic query parser
QueryParser p = new QueryParser("f", analyzer);
Query q = p.parse("Hello");
//passes
assertEquals(new TermQuery(new Term("f", "hello")), q);

q = p.parse("Hello*");
//fails
assertEquals(new PrefixQuery(new Term("f", "hello")), q);

q = p.parse("Hel*o");
//fails
assertEquals(new WildcardQuery(new Term("f", "hel*o")), q);
  }
{noformat}

The problem is that the CustomAnalyzer iterates through the tokenfilters, but 
does not call the tokenizer, which, in the case of the LowerCaseAnalyzer, does 
the filtering work.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Resolved] (SOLR-11201) Implement trigger for arbitrary metrics

2018-02-26 Thread Shalin Shekhar Mangar (JIRA)


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

Shalin Shekhar Mangar resolved SOLR-11201.
--
Resolution: Fixed

> Implement trigger for arbitrary metrics
> ---
>
> Key: SOLR-11201
> URL: https://issues.apache.org/jira/browse/SOLR-11201
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: AutoScaling, SolrCloud
>Reporter: Shalin Shekhar Mangar
>Assignee: Shalin Shekhar Mangar
>Priority: Major
> Fix For: master (8.0), 7.3
>
> Attachments: SOLR-11201-test-fix.patch, SOLR-11201.patch, 
> SOLR-11201.patch
>
>
> It should be possible to set a trigger on any metrics exposed by the Metrics 
> API using a threshold value. Supporting {{waitFor}} may not be possible or 
> useful for all metrics. For those we will implement proper trigger support 
> (such as searchRate) However, a naive implementation might be to just poll 
> the value of the metric frequently and if it is consistently above the 
> threshold, fire the trigger.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

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

2018-02-26 Thread ASF subversion and git services (JIRA)

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

No tests ran.

Build Log:
[...truncated 28738 lines...]
prepare-release-no-sign:
[mkdir] Created dir: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/dist
 [copy] Copying 491 files to 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/dist/lucene
 [copy] Copying 215 files to 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/dist/solr
   [smoker] Java 1.8 JAVA_HOME=/home/jenkins/tools/java/latest1.8
   [smoker] Java 9 JAVA_HOME=/home/jenkins/tools/java/latest1.9
   [smoker] NOTE: output encoding is UTF-8
   [smoker] 
   [smoker] Load release URL 
"file:/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/dist/"...
   [smoker] 
   [smoker] Test Lucene...
   [smoker]   test basics...
   [smoker]   get KEYS
   [smoker] 0.2 MB in 0.02 sec (13.2 MB/sec)
   [smoker]   check changes HTML...
   [smoker]   download lucene-8.0.0-src.tgz...
   [smoker] 30.2 MB in 0.03 sec (1150.8 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download lucene-8.0.0.tgz...
   [smoker] 73.2 MB in 0.06 sec (1145.2 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download lucene-8.0.0.zip...
   [smoker] 83.7 MB in 0.08 sec (1055.4 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   unpack lucene-8.0.0.tgz...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] test demo with 1.8...
   [smoker]   got 6243 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] test demo with 9...
   [smoker]   got 6243 hits for query "lucene"
   [smoker] checkindex with 9...
   [smoker] check Lucene's javadoc JAR
   [smoker]   unpack lucene-8.0.0.zip...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] test demo with 1.8...
   [smoker]   got 6243 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] test demo with 9...
   [smoker]   got 6243 hits for query "lucene"
   [smoker] checkindex with 9...
   [smoker] check Lucene's javadoc JAR
   [smoker]   unpack lucene-8.0.0-src.tgz...
   [smoker] make sure no JARs/WARs in src dist...
   [smoker] run "ant validate"
   [smoker] run tests w/ Java 8 and testArgs='-Dtests.slow=false'...
   [smoker] test demo with 1.8...
   [smoker]   got 212 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] generate javadocs w/ Java 8...
   [smoker] 
   [smoker] Crawl/parse...
   [smoker] 
   [smoker] Verify...
   [smoker] run tests w/ Java 9 and testArgs='-Dtests.slow=false'...
   [smoker] test demo with 9...
   [smoker]   got 212 hits for query "lucene"
   [smoker] checkindex with 9...
   [smoker]   confirm all releases have coverage in TestBackwardsCompatibility
   [smoker] find all past Lucene releases...
   [smoker] run TestBackwardsCompatibility..
   [smoker] success!
   [smoker] 
   [smoker] Test Solr...
   [smoker]   test basics...
   [smoker]   get KEYS
   [smoker] 0.2 MB in 0.00 sec (293.0 MB/sec)
   [smoker]   check changes HTML...
   [smoker]   download solr-8.0.0-src.tgz...
   [smoker] 52.6 MB in 1.07 sec (49.3 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download solr-8.0.0.tgz...
   [smoker] 151.0 MB in 2.19 sec (69.0 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download solr-8.0.0.zip...
   [smoker] 152.0 MB in 0.41 sec (366.3 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   unpack solr-8.0.0.tgz...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] unpack lucene-8.0.0.tgz...
   [smoker]   **WARNING**: skipping check of 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/tmp/unpack/solr-8.0.0/contrib/dataimporthandler-extras/lib/javax.mail-1.5.1.jar:
 it has javax.* classes
   [smoker]   **WARNING**: skipping check of 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/tmp/unpack/solr-8.0.0/contrib/dataimporthandler-extras/lib/activation-1.1.1.jar:
 it has javax.* classes
   [smoker] copying unpacked distribution for Java 8 ...
   [smoker] test solr example w/ Java 8...
   [smoker]   start Solr instance 
(log=/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/tmp/unpack/solr-8.0.0-java8/solr-example.log)...
   [smoker] No process found for Solr node running on port 8983
   [smoker]   Running techproducts example on port 8983 from 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/tmp/unpack/solr-8.0.0-java8
   [smoker] *** [WARN] *** Your

[jira] [Commented] (SOLR-11201) Implement trigger for arbitrary metrics


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

ASF subversion and git services commented on SOLR-11201:


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

SOLR-11201: Fix bad assumptions made in testMetricTrigger


> Implement trigger for arbitrary metrics
> ---
>
> Key: SOLR-11201
> URL: https://issues.apache.org/jira/browse/SOLR-11201
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: AutoScaling, SolrCloud
>Reporter: Shalin Shekhar Mangar
>Assignee: Shalin Shekhar Mangar
>Priority: Major
> Fix For: master (8.0), 7.3
>
> Attachments: SOLR-11201-test-fix.patch, SOLR-11201.patch, 
> SOLR-11201.patch
>
>
> It should be possible to set a trigger on any metrics exposed by the Metrics 
> API using a threshold value. Supporting {{waitFor}} may not be possible or 
> useful for all metrics. For those we will implement proper trigger support 
> (such as searchRate) However, a naive implementation might be to just poll 
> the value of the metric frequently and if it is consistently above the 
> threshold, fire the trigger.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (SOLR-11201) Implement trigger for arbitrary metrics

2018-02-26 Thread ASF subversion and git services (JIRA)


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

ASF subversion and git services commented on SOLR-11201:


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

SOLR-11201: Fix bad assumptions made in testMetricTrigger

(cherry picked from commit e08eac4)


> Implement trigger for arbitrary metrics
> ---
>
> Key: SOLR-11201
> URL: https://issues.apache.org/jira/browse/SOLR-11201
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: AutoScaling, SolrCloud
>Reporter: Shalin Shekhar Mangar
>Assignee: Shalin Shekhar Mangar
>Priority: Major
> Fix For: master (8.0), 7.3
>
> Attachments: SOLR-11201-test-fix.patch, SOLR-11201.patch, 
> SOLR-11201.patch
>
>
> It should be possible to set a trigger on any metrics exposed by the Metrics 
> API using a threshold value. Supporting {{waitFor}} may not be possible or 
> useful for all metrics. For those we will implement proper trigger support 
> (such as searchRate) However, a naive implementation might be to just poll 
> the value of the metric frequently and if it is consistently above the 
> threshold, fire the trigger.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
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 (64bit/jdk-10-ea+43) - Build # 21539 - Still Unstable!