[JENKINS] Lucene-Solr-BadApples-7.x-Linux (64bit/jdk-9.0.4) - Build # 9 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-BadApples-7.x-Linux/9/
Java: 64bit/jdk-9.0.4 -XX:-UseCompressedOops -XX:+UseParallelGC

12 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.cloud.autoscaling.sim.TestLargeCluster

Error Message:
1 thread leaked from SUITE scope at 
org.apache.solr.cloud.autoscaling.sim.TestLargeCluster: 1) Thread[id=477, 
name=AutoscalingActionExecutor-13-thread-1, state=RUNNABLE, 
group=TGRP-TestLargeCluster] at 
app//org.apache.solr.common.util.Utils.getDeepCopy(Utils.java:131) at 
app//org.apache.solr.common.util.Utils.makeDeepCopy(Utils.java:110) at 
app//org.apache.solr.common.util.Utils.getDeepCopy(Utils.java:92) at 
app//org.apache.solr.common.util.Utils.makeDeepCopy(Utils.java:108) at 
app//org.apache.solr.common.util.Utils.getDeepCopy(Utils.java:92) at 
app//org.apache.solr.common.util.Utils.getDeepCopy(Utils.java:74) at 
app//org.apache.solr.client.solrj.cloud.autoscaling.Row.copy(Row.java:91)   
  at 
app//org.apache.solr.client.solrj.cloud.autoscaling.Policy$Session.lambda$getMatrixCopy$1(Policy.java:299)
 at 
app//org.apache.solr.client.solrj.cloud.autoscaling.Policy$Session$$Lambda$231/1388132079.apply(Unknown
 Source) at 
java.base@9.0.4/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195)
 at 
java.base@9.0.4/java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1494)
 at 
java.base@9.0.4/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484)
 at 
java.base@9.0.4/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474)
 at 
java.base@9.0.4/java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:913)
 at 
java.base@9.0.4/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
 at 
java.base@9.0.4/java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:511)
 at 
app//org.apache.solr.client.solrj.cloud.autoscaling.Policy$Session.getMatrixCopy(Policy.java:300)
 at 
app//org.apache.solr.client.solrj.cloud.autoscaling.Policy$Session.copy(Policy.java:289)
 at 
app//org.apache.solr.client.solrj.cloud.autoscaling.Row.addReplica(Row.java:122)
 at 
app//org.apache.solr.client.solrj.cloud.autoscaling.MoveReplicaSuggester.tryEachNode(MoveReplicaSuggester.java:59)
 at 
app//org.apache.solr.client.solrj.cloud.autoscaling.MoveReplicaSuggester.init(MoveReplicaSuggester.java:34)
 at 
app//org.apache.solr.client.solrj.cloud.autoscaling.Suggester.getSuggestion(Suggester.java:129)
 at 
app//org.apache.solr.cloud.autoscaling.ComputePlanAction.process(ComputePlanAction.java:98)
 at 
app//org.apache.solr.cloud.autoscaling.ScheduledTriggers.lambda$add$3(ScheduledTriggers.java:308)
 at 
app//org.apache.solr.cloud.autoscaling.ScheduledTriggers$$Lambda$213/355972816.run(Unknown
 Source) at 
java.base@9.0.4/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:514)
 at 
java.base@9.0.4/java.util.concurrent.FutureTask.run(FutureTask.java:264)
 at 
app//org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:188)
 at 
app//org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor$$Lambda$133/546346621.run(Unknown
 Source) at 
java.base@9.0.4/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1167)
 at 
java.base@9.0.4/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641)
 at java.base@9.0.4/java.lang.Thread.run(Thread.java:844)

Stack Trace:
com.carrotsearch.randomizedtesting.ThreadLeakError: 1 thread leaked from SUITE 
scope at org.apache.solr.cloud.autoscaling.sim.TestLargeCluster: 
   1) Thread[id=477, name=AutoscalingActionExecutor-13-thread-1, 
state=RUNNABLE, group=TGRP-TestLargeCluster]
at app//org.apache.solr.common.util.Utils.getDeepCopy(Utils.java:131)
at app//org.apache.solr.common.util.Utils.makeDeepCopy(Utils.java:110)
at app//org.apache.solr.common.util.Utils.getDeepCopy(Utils.java:92)
at app//org.apache.solr.common.util.Utils.makeDeepCopy(Utils.java:108)
at app//org.apache.solr.common.util.Utils.getDeepCopy(Utils.java:92)
at app//org.apache.solr.common.util.Utils.getDeepCopy(Utils.java:74)
at 
app//org.apache.solr.client.solrj.cloud.autoscaling.Row.copy(Row.java:91)
at 
app//org.apache.solr.client.solrj.cloud.autoscaling.Policy$Session.lambda$getMatrixCopy$1(Policy.java:299)
at 
app//org.apache.solr.client.solrj.cloud.autoscaling.Policy$Session$$Lambda$231/1388132079.apply(Unknown
 Source)
at 
java.base@9.0.4/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195)
at 
java.base@9.0.4/java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1494)
at 

[JENKINS] Lucene-Solr-7.3-Windows (64bit/jdk-9.0.1) - Build # 5 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.3-Windows/5/
Java: 64bit/jdk-9.0.1 -XX:+UseCompressedOops -XX:+UseSerialGC

1 tests failed.
FAILED:  org.apache.solr.core.ExitableDirectoryReaderTest.testQueryResults

Error Message:
Should NOT have inserted partial results! expected:<4> but was:<5>

Stack Trace:
java.lang.AssertionError: Should NOT have inserted partial results! 
expected:<4> but was:<5>
at 
__randomizedtesting.SeedInfo.seed([193A467CB4A58EEB:44B37E0516AED0A0]: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.core.ExitableDirectoryReaderTest.testQueryResults(ExitableDirectoryReaderTest.java:141)
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)




Build Log:
[...truncated 14426 lines...]
   [junit4] Suite: org.apache.solr.core.ExitableDirectoryReaderTest
  

[jira] [Commented] (SOLR-12059) Unable to rename solr.xml

[Walter Underwood (JIRA)]

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

Walter Underwood commented on SOLR-12059:
-

Changing the file name for version control is not a good reason. I've been 
using version control systems that allow keeping the same file name since, um, 
1981. Yeah, that was SCCS in Unix v6/PWB.

> Unable to rename solr.xml
> -
>
> Key: SOLR-12059
> URL: https://issues.apache.org/jira/browse/SOLR-12059
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 6.5.1
> Environment: Renaming of solr,xml in the $SOLR_HOME directory
>Reporter: Edwin Yeo Zheng Lin
>Priority: Major
>
> I am able to rename the flie names like solrconfig.xml and solr.log to custom 
> names like myconfig.xml and my.log quite seamlessly. 
> However, I am not able to rename the same for solr.xml. Understand that the 
> solr.xml is hard-coded at the SolrXmlConfig.java. Meaning it requires a 
> re-compile of the Jar file in order to rename it.
> Since we can rename files like solrconfig.xml from the properties files, so 
> we should do the same for solr.xml?
>  
>  



--
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-BadApples-master-Linux (64bit/jdk1.8.0_162) - Build # 9 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-BadApples-master-Linux/9/
Java: 64bit/jdk1.8.0_162 -XX:-UseCompressedOops -XX:+UseParallelGC

13 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.cloud.autoscaling.sim.TestLargeCluster

Error Message:
1 thread leaked from SUITE scope at 
org.apache.solr.cloud.autoscaling.sim.TestLargeCluster: 1) Thread[id=632, 
name=AutoscalingActionExecutor-13-thread-1, state=RUNNABLE, 
group=TGRP-TestLargeCluster] at 
org.apache.solr.common.util.Utils.getDeepCopy(Utils.java:90) at 
org.apache.solr.common.util.Utils.makeDeepCopy(Utils.java:108) at 
org.apache.solr.common.util.Utils.getDeepCopy(Utils.java:92) at 
org.apache.solr.common.util.Utils.getDeepCopy(Utils.java:74) at 
org.apache.solr.client.solrj.cloud.autoscaling.Row.copy(Row.java:91) at 
org.apache.solr.client.solrj.cloud.autoscaling.Policy$Session.lambda$getMatrixCopy$1(Policy.java:299)
 at 
org.apache.solr.client.solrj.cloud.autoscaling.Policy$Session$$Lambda$142/1513285709.apply(Unknown
 Source) at 
java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)   
  at 
java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1382)  
   at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481) 
at 
java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
 at 
java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:708)  
   at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234) 
at java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:499)   
  at 
org.apache.solr.client.solrj.cloud.autoscaling.Policy$Session.getMatrixCopy(Policy.java:300)
 at 
org.apache.solr.client.solrj.cloud.autoscaling.Policy$Session.copy(Policy.java:289)
 at 
org.apache.solr.client.solrj.cloud.autoscaling.Row.addReplica(Row.java:122) 
at 
org.apache.solr.client.solrj.cloud.autoscaling.MoveReplicaSuggester.tryEachNode(MoveReplicaSuggester.java:59)
 at 
org.apache.solr.client.solrj.cloud.autoscaling.MoveReplicaSuggester.init(MoveReplicaSuggester.java:34)
 at 
org.apache.solr.client.solrj.cloud.autoscaling.Suggester.getSuggestion(Suggester.java:129)
 at 
org.apache.solr.cloud.autoscaling.ComputePlanAction.process(ComputePlanAction.java:98)
 at 
org.apache.solr.cloud.autoscaling.ScheduledTriggers.lambda$null$3(ScheduledTriggers.java:307)
 at 
org.apache.solr.cloud.autoscaling.ScheduledTriggers$$Lambda$124/280419344.run(Unknown
 Source) at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
at java.util.concurrent.FutureTask.run(FutureTask.java:266) at 
org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:188)
 at 
org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor$$Lambda$66/571639289.run(Unknown
 Source) at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) 
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) 
at java.lang.Thread.run(Thread.java:748)

Stack Trace:
com.carrotsearch.randomizedtesting.ThreadLeakError: 1 thread leaked from SUITE 
scope at org.apache.solr.cloud.autoscaling.sim.TestLargeCluster: 
   1) Thread[id=632, name=AutoscalingActionExecutor-13-thread-1, 
state=RUNNABLE, group=TGRP-TestLargeCluster]
at org.apache.solr.common.util.Utils.getDeepCopy(Utils.java:90)
at org.apache.solr.common.util.Utils.makeDeepCopy(Utils.java:108)
at org.apache.solr.common.util.Utils.getDeepCopy(Utils.java:92)
at org.apache.solr.common.util.Utils.getDeepCopy(Utils.java:74)
at org.apache.solr.client.solrj.cloud.autoscaling.Row.copy(Row.java:91)
at 
org.apache.solr.client.solrj.cloud.autoscaling.Policy$Session.lambda$getMatrixCopy$1(Policy.java:299)
at 
org.apache.solr.client.solrj.cloud.autoscaling.Policy$Session$$Lambda$142/1513285709.apply(Unknown
 Source)
at 
java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
at 
java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1382)
at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
at 
java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
at 
java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:708)
at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
at 
java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:499)
at 
org.apache.solr.client.solrj.cloud.autoscaling.Policy$Session.getMatrixCopy(Policy.java:300)
at 
org.apache.solr.client.solrj.cloud.autoscaling.Policy$Session.copy(Policy.java:289)
at 

[jira] [Commented] (SOLR-12059) Unable to rename solr.xml

[Shawn Heisey (JIRA)]

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

Shawn Heisey commented on SOLR-12059:
-

bq. We want to rename the solr.xml to add some versioning and date to the file 
name.

None of the information before now has mentioned versioning or dates.  It has 
been about replacing "solr" with something else, which was stated as "my" in 
everything I have seen before today.

Why would you need to rename solr-cell-6.5.1.jar to my-cell-6.5.1.jar if your 
intent is version control?  There's already a version number in the filename, 
and the jars are very unlikely to ever get replaced with an incorrect version, 
because another version will most likely have a different filename.

I have the same question about renaming solr-webapp to my-webapp and 
solr-jetty-context.xml to my-jetty-context.xml, which were other changes you 
said you wanted to make.  These changes are unlikely to be related to version 
control.  The context file almost never requires changes, and the other one is 
a directory.  Most users will NEVER need to change the context file, so the 
official Solr download serves as a backup copy that can always be obtained.

Renaming solrconfig.xml to myconfig.xml also seems to have little to do with 
version control.

If my suspicions are unfounded and you really are interested in version 
control, there are two ways to do this effectively with Solr's config files.  
Neither of these methods requires any ability to change the filenames Solr is 
expecting to see.

One way is to put the entire directory into version control, setting the 
software to ignore anything that's not needed to make sure you don't lose 
config info.  This would probably mean something like svn or git.  When you 
make a change, you can commit it, which will ensure that the version history 
isn't lost.  You could even have changes pushed to a central repository, so 
that if the Solr server loses all of its data, you still have all of your 
config information.

The other way is to copy the active config file to a versioned backup whenever 
you change it.  So for solr.xml, you will have a bunch of other files, with 
names like solr-201803101900.xml ... and there would be similar backups for 
other config files.  Solr will typically ignore the ones with different 
filenames.  To make sure you don't lose this data if the Solr server dies 
completely, copy the files regularly to another server.

With SolrCloud, where the active configs are in zookeeper, you would want to 
maintain a separate on-disk config tree somewhere and do version control on 
that, uploading changes to ZK after making changes in the on-disk directory and 
doing whatever's necessary to keep your version history.

If you really feel like you need to rename solr.xml, then edit the source code, 
change it, and recompile Solr.  I haven't seen a compelling reason to make it 
configurable for everyone.  It certainly COULD be configurable, but there are 
always risks of bugs when something is made configurable.  Because of that, 
configurability is only added to things where there is a REALLY good reason.

Thinking about it from the standpoint of supporting users, it is very nice to 
be able to mention the solr.xml filename and be SURE that this is the file the 
user needs to look for.


> Unable to rename solr.xml
> -
>
> Key: SOLR-12059
> URL: https://issues.apache.org/jira/browse/SOLR-12059
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 6.5.1
> Environment: Renaming of solr,xml in the $SOLR_HOME directory
>Reporter: Edwin Yeo Zheng Lin
>Priority: Major
>
> I am able to rename the flie names like solrconfig.xml and solr.log to custom 
> names like myconfig.xml and my.log quite seamlessly. 
> However, I am not able to rename the same for solr.xml. Understand that the 
> solr.xml is hard-coded at the SolrXmlConfig.java. Meaning it requires a 
> re-compile of the Jar file in order to rename it.
> Since we can rename files like solrconfig.xml from the properties files, so 
> we should do the same for solr.xml?
>  
>  



--
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-Windows (64bit/jdk-9.0.1) - Build # 7225 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/7225/
Java: 64bit/jdk-9.0.1 -XX:+UseCompressedOops -XX:+UseParallelGC

14 tests failed.
FAILED:  org.apache.solr.cloud.autoscaling.ScheduledTriggerTest.testTrigger

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

Stack Trace:
java.lang.AssertionError: expected:<3> but was:<2>
at 
__randomizedtesting.SeedInfo.seed([4B19A5DA2CA1E96D:28D29358B56E9A40]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.failNotEquals(Assert.java:647)
at org.junit.Assert.assertEquals(Assert.java:128)
at org.junit.Assert.assertEquals(Assert.java:472)
at org.junit.Assert.assertEquals(Assert.java:456)
at 
org.apache.solr.cloud.autoscaling.ScheduledTriggerTest.scheduledTriggerTest(ScheduledTriggerTest.java:112)
at 
org.apache.solr.cloud.autoscaling.ScheduledTriggerTest.testTrigger(ScheduledTriggerTest.java:65)
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:  

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

[Apache Jenkins Server]

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

No tests ran.

Build Log:
[...truncated 30126 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 230 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.02 sec (11.3 MB/sec)
   [smoker]   check changes HTML...
   [smoker]   download lucene-7.4.0-src.tgz...
   [smoker] 31.9 MB in 0.03 sec (1172.0 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download lucene-7.4.0.tgz...
   [smoker] 73.4 MB in 0.24 sec (309.7 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download lucene-7.4.0.zip...
   [smoker] 83.9 MB in 0.17 sec (480.8 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   unpack lucene-7.4.0.tgz...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] test demo with 1.8...
   [smoker]   got 6300 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] test demo with 9...
   [smoker]   got 6300 hits for query "lucene"
   [smoker] checkindex with 9...
   [smoker] check Lucene's javadoc JAR
   [smoker]   unpack lucene-7.4.0.zip...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] test demo with 1.8...
   [smoker]   got 6300 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] test demo with 9...
   [smoker]   got 6300 hits for query "lucene"
   [smoker] checkindex with 9...
   [smoker] check Lucene's javadoc JAR
   [smoker]   unpack lucene-7.4.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.badapples=false 
-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.badapples=false 
-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 (232.1 MB/sec)
   [smoker]   check changes HTML...
   [smoker]   download solr-7.4.0-src.tgz...
   [smoker] 55.4 MB in 0.06 sec (896.2 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download solr-7.4.0.tgz...
   [smoker] 154.6 MB in 0.16 sec (946.9 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download solr-7.4.0.zip...
   [smoker] 155.6 MB in 0.17 sec (938.5 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   unpack solr-7.4.0.tgz...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] unpack lucene-7.4.0.tgz...
   [smoker]   **WARNING**: skipping check of 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/lucene/build/smokeTestRelease/tmp/unpack/solr-7.4.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.4.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.4.0-java8/solr-example.log)...
   [smoker] No process found for Solr node running on port 8983
   [smoker]   Running techproducts example on port 8983 from 

[jira] [Commented] (LUCENE-8197) Make top-k queries fast when static scoring signals are incorporated into the score

[Robert Muir (JIRA)]

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

Robert Muir commented on LUCENE-8197:
-

and just to be clear, i dont want to hide the formula. user should be in 
control of parameters weight/scaling factor so the formula is transparent. but 
they can always add a boost so can the default weight be something uber-simple? 
As far as scaling factor, well you already have a simple default for the 
two-parameter case, but for the 1-parameter case is there anything we can do 
that is simple? its a log either way, so we are a far cry from the previous 
crazy stuff with lucene's sqrt() :) 

just brainstorming to make it really easy to get the query integrated into 
various query parsers and stuff, but still be clear to people who really give a 
crap.

> Make top-k queries fast when static scoring signals are incorporated into the 
> score
> ---
>
> Key: LUCENE-8197
> URL: https://issues.apache.org/jira/browse/LUCENE-8197
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Adrien Grand
>Priority: Minor
> Fix For: master (8.0)
>
> Attachments: LUCENE-8197.patch, LUCENE-8197.patch, LUCENE-8197.patch
>
>
> Block-max WAND (LUCENE-8135) and some earlier issues made Lucene faster at 
> computing the top-k matches of boolean queries.
> It is quite frequent that users want to improve ranking and end up scoring 
> with a formula that could look like {{bm25_score + w * log(alpha + 
> pagerank)}} (w and alpha being constants, and pagerank being a per-document 
> field value). You could do this with doc values and {{FunctionScoreQuery}} 
> but unfortunately this will remove the ability to optimize top-k queries 
> since the scoring formula becomes opaque to Lucene.
> I'd like to add a new field that allows to store such scoring signals as term 
> frequencies, and new queries that could produce {{log(alpha + pagerank)}} as 
> a score. Then implementing the above formula can be done by boosting this 
> query with a boost equal to {{w}} and adding this boosted query as a SHOULD 
> clause of a {{BooleanQuery}}. This would give Lucene the ability to compute 
> top-k hits faster, especially but not only if the index is sorted by 
> decreasing pagerank.



--
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-11960) Add collection level properties

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar commented on SOLR-11960:
--

bq. Shalin Shekhar Mangar, I believe your comments were addressed

Looks good, thanks!

> Add collection level properties
> ---
>
> Key: SOLR-11960
> URL: https://issues.apache.org/jira/browse/SOLR-11960
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Peter Rusko
>Assignee: Tomás Fernández Löbbe
>Priority: Blocker
> Fix For: 7.3, master (8.0)
>
> Attachments: SOLR-11960.patch, SOLR-11960.patch, SOLR-11960.patch, 
> SOLR-11960.patch, SOLR-11960.patch, SOLR-11960_2.patch
>
>
> Solr has cluster properties, but no easy and extendable way of defining 
> properties that affect a single collection. Collection properties could be 
> stored in a single zookeeper node per collection, making it possible to 
> trigger zookeeper watchers for only those Solr nodes that have cores of that 
> collection.



--
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-8197) Make top-k queries fast when static scoring signals are incorporated into the score

[Robert Muir (JIRA)]

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

Robert Muir commented on LUCENE-8197:
-

But that sounds like a more general field-weighting issue. I think we should 
keep the concepts separate. The FeatureField should try to help you fill out 
its parameters, i mean ideally the api is just as simple as possible, but its a 
per-field thing. Shouldn't we just let the user continue to still tune field 
weights for now with boosts? We can always try to separately improve the 
cross-field situation better, regardless of nontextual stuff.

My only suggestion for this issue is to try to reduce the amount of per-field 
parameters as much as we can, so the user can use the thing as easily as 
possible. Otherwise its hard if we don't give defaults and they have to 
maximize some multivariable equation across all their fields to even approach 
the thing.

> Make top-k queries fast when static scoring signals are incorporated into the 
> score
> ---
>
> Key: LUCENE-8197
> URL: https://issues.apache.org/jira/browse/LUCENE-8197
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Adrien Grand
>Priority: Minor
> Fix For: master (8.0)
>
> Attachments: LUCENE-8197.patch, LUCENE-8197.patch, LUCENE-8197.patch
>
>
> Block-max WAND (LUCENE-8135) and some earlier issues made Lucene faster at 
> computing the top-k matches of boolean queries.
> It is quite frequent that users want to improve ranking and end up scoring 
> with a formula that could look like {{bm25_score + w * log(alpha + 
> pagerank)}} (w and alpha being constants, and pagerank being a per-document 
> field value). You could do this with doc values and {{FunctionScoreQuery}} 
> but unfortunately this will remove the ability to optimize top-k queries 
> since the scoring formula becomes opaque to Lucene.
> I'd like to add a new field that allows to store such scoring signals as term 
> frequencies, and new queries that could produce {{log(alpha + pagerank)}} as 
> a score. Then implementing the above formula can be done by boosting this 
> query with a boost equal to {{w}} and adding this boosted query as a SHOULD 
> clause of a {{BooleanQuery}}. This would give Lucene the ability to compute 
> top-k hits faster, especially but not only if the index is sorted by 
> decreasing pagerank.



--
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-12059) Unable to rename solr.xml

[David Smiley (JIRA)]

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

David Smiley commented on SOLR-12059:
-

Consider simply using a different chroot to the zookeeper coordinates.

> Unable to rename solr.xml
> -
>
> Key: SOLR-12059
> URL: https://issues.apache.org/jira/browse/SOLR-12059
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 6.5.1
> Environment: Renaming of solr,xml in the $SOLR_HOME directory
>Reporter: Edwin Yeo Zheng Lin
>Priority: Major
>
> I am able to rename the flie names like solrconfig.xml and solr.log to custom 
> names like myconfig.xml and my.log quite seamlessly. 
> However, I am not able to rename the same for solr.xml. Understand that the 
> solr.xml is hard-coded at the SolrXmlConfig.java. Meaning it requires a 
> re-compile of the Jar file in order to rename it.
> Since we can rename files like solrconfig.xml from the properties files, so 
> we should do the same for solr.xml?
>  
>  



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

[Đạt Cao Mạnh]

Hi guys, Alan,

I found a blocker issue SOLR-12110, when investigating test failure. I've
already uploaded a patch and beasting the tests, if the result is good I
will commit soon.

Thanks!

On Tue, Mar 13, 2018 at 7:49 PM Alan Woodward  wrote:

> Just realised that I don’t have an ASF Jenkins account - Uwe or Steve, can
> you give me a hand setting up the 7.3 Jenkins jobs?
>
> Thanks, Alan
>
>
> On 12 Mar 2018, at 09:32, Alan Woodward  wrote:
>
> I’ve created the 7.3 release branch.  I’ll leave 24 hours for bug-fixes
> and doc patches and then create a release candidate.
>
> We’re now in feature-freeze for 7.3, so please bear in mind the following:
>
>- No new features may be committed to the branch.
>- Documentation patches, build patches and serious bug fixes may be
>committed to the branch. However, you should submit *all* patches you
>want to commit to Jira first to give others the chance to review and
>possibly vote against the patch. Keep in mind that it is our main intention
>to keep the branch as stable as possible.
>- All patches that are intended for the branch should first be
>committed to the unstable branch, merged into the stable branch, and then
>into the current release branch.
>- Normal unstable and stable branch development may continue as usual.
>However, if you plan to commit a big change to the unstable branch while
>the branch feature freeze is in effect, think twice: can't the addition
>wait a couple more days? Merges of bug fixes into the branch may become
>more difficult.
>- *Only* Jira issues with Fix version “7.3" and priority "Blocker"
>will delay a release candidate build.
>
>
>
> On 9 Mar 2018, at 16:43, Alan Woodward  wrote:
>
> FYI I’m still recovering from my travels, so I’m going to create the
> release branch on Monday instead.
>
> On 27 Feb 2018, at 18:51, Cassandra Targett  wrote:
>
> I intend to create the Ref Guide RC as soon as the Lucene/Solr artifacts
> RC is ready, so this is a great time to remind folks that if you've got
> Ref Guide changes to be done, you've got a couple weeks. If you're stuck or
> not sure what to do, let me know & I'm happy to help you out.
>
> Eventually we'd like to release both the Ref Guide and Lucene/Solr with
> the same release process, so this will be a big first test to see how ready
> for that we are.
>
> On Tue, Feb 27, 2018 at 11:42 AM, Michael McCandless <
> luc...@mikemccandless.com> wrote:
>
>> +1
>>
>> Mike McCandless
>>
>> http://blog.mikemccandless.com
>>
>> On Fri, Feb 23, 2018 at 4:50 AM, Alan Woodward <
>> alan.woodw...@romseysoftware.co.uk> wrote:
>>
>>> 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
>>>
>>>
>>
>
>
>
>

[jira] [Commented] (SOLR-12110) Replica which failed to register in Zk can become leader

[Cao Manh Dat (JIRA)]

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

Cao Manh Dat commented on SOLR-12110:
-

The idea of the patch is calling ZkController.unregister when an exception is 
thrown by ZkController.register

> Replica which failed to register in Zk can become leader
> 
>
> Key: SOLR-12110
> URL: https://issues.apache.org/jira/browse/SOLR-12110
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 7.3
>Reporter: Cao Manh Dat
>Assignee: Cao Manh Dat
>Priority: Blocker
> Attachments: SOLR-12110.patch
>
>
> In case of when an exception is thrown in ZkController.register() a replica 
> can still be able to joinElection and become leader after that. This will 
> cause many problems, one of the problems can happen (the patch including a 
> test which lead to this failure) is
> A replica with DOWN state can become a leader and the shard will be stuck in 
> this state forever until the replica is removed or the node contains the 
> replica is restarted.
> This won't be a problem in Solr 7.2.1 because a replica with last published 
> state = DOWN can't become a leader, only since SOLR-7034 get resolved (by 
> SOLR-12011)



--
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-12110) Replica which failed to register in Zk can become leader

[Cao Manh Dat (JIRA)]

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

Cao Manh Dat updated SOLR-12110:

Attachment: SOLR-12110.patch

> Replica which failed to register in Zk can become leader
> 
>
> Key: SOLR-12110
> URL: https://issues.apache.org/jira/browse/SOLR-12110
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 7.3
>Reporter: Cao Manh Dat
>Assignee: Cao Manh Dat
>Priority: Blocker
> Attachments: SOLR-12110.patch
>
>
> In case of when an exception is thrown in ZkController.register() a replica 
> can still be able to joinElection and become leader after that. This will 
> cause many problems, one of the problems can happen (the patch including a 
> test which lead to this failure) is
> A replica with DOWN state can become a leader and the shard will be stuck in 
> this state forever until the replica is removed or the node contains the 
> replica is restarted.
> This won't be a problem in Solr 7.2.1 because a replica with last published 
> state = DOWN can't become a leader, only since SOLR-7034 get resolved (by 
> SOLR-12011)



--
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-12110) Replica which failed to register in Zk can become leader

[Cao Manh Dat (JIRA)]

Cao Manh Dat created SOLR-12110:
---

 Summary: Replica which failed to register in Zk can become leader
 Key: SOLR-12110
 URL: https://issues.apache.org/jira/browse/SOLR-12110
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
Affects Versions: 7.3
Reporter: Cao Manh Dat
Assignee: Cao Manh Dat


In case of when an exception is thrown in ZkController.register() a replica can 
still be able to joinElection and become leader after that. This will cause 
many problems, one of the problems can happen (the patch including a test which 
lead to this failure) is

A replica with DOWN state can become a leader and the shard will be stuck in 
this state forever until the replica is removed or the node contains the 
replica is restarted.

This won't be a problem in Solr 7.2.1 because a replica with last published 
state = DOWN can't become a leader, only since SOLR-7034 get resolved (by 
SOLR-12011)



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

[Policeman Jenkins Server]

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

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

Error Message:
ObjectTracker found 6 object(s) that were not released!!! 
[MockDirectoryWrapper, MockDirectoryWrapper, SolrCore, SolrIndexSearcher, 
MockDirectoryWrapper, MDCAwareThreadPoolExecutor] 
org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: 
org.apache.lucene.store.MockDirectoryWrapper  at 
org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42)
  at 
org.apache.solr.core.CachingDirectoryFactory.get(CachingDirectoryFactory.java:348)
  at 
org.apache.solr.core.SolrCore.initSnapshotMetaDataManager(SolrCore.java:498)  
at org.apache.solr.core.SolrCore.(SolrCore.java:948)  at 
org.apache.solr.core.SolrCore.(SolrCore.java:863)  at 
org.apache.solr.core.CoreContainer.createFromDescriptor(CoreContainer.java:1040)
  at org.apache.solr.core.CoreContainer.getCore(CoreContainer.java:1510)  at 
org.apache.solr.core.TestCoreDiscovery.testTooManyTransientCores(TestCoreDiscovery.java:320)
  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 

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

[Steve Rowe]

This seems to be happening fairly often on Policeman Jenkins. 

A while back, Uwe, you suggested that this problem could related to too-large 
console logs, and that may be true, but the frequency is getting high enough 
that we should try to figure out what’s happening and address it somehow.

--
Steve
www.lucidworks.com

> On Mar 15, 2018, at 4:26 PM, Policeman Jenkins Server  
> wrote:
> 
> Error processing tokens: Error while parsing action 
> 'Text/ZeroOrMore/FirstOf/Token/DelimitedToken/DelimitedToken_Action3' at 
> input position (line 79, pos 4):
> )"}
>   ^
> 
> java.lang.OutOfMemoryError: Java heap space


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

[jira] [Commented] (SOLR-11749) regression-test-like functionality for bin/solr*

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-11749:


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

SOLR-11749: Introduce bin/solr test suite


> regression-test-like functionality for bin/solr*
> 
>
> Key: SOLR-11749
> URL: https://issues.apache.org/jira/browse/SOLR-11749
> Project: Solr
>  Issue Type: Wish
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: scripts and tools
>Reporter: Christine Poerschke
>Assignee: Jason Gerlowski
>Priority: Minor
> Attachments: SOLR-11749.patch, SOLR-11749.patch, SOLR-11749.patch, 
> SOLR-11749.patch, SOLR-11749.patch, test-output.txt
>
>




--
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-11911) TestLargeCluster.testSearchRate() failure

[Hoss Man (JIRA)]

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

Hoss Man commented on SOLR-11911:
-

bq. SOLR-11911: Wait a while for left-behind threads from executors.

Increasing the wait time just kicks the can down the road -- the real questions 
are:
# why these executor tasks aren't aborting quickly
#* If the Callable instances being submitted to the executors can take a non 
trivial amount of time, then they should be checking the shutdown status of the 
executor frequently
# why the threads are being reported as leaks, instead of the test timing out 
when shutting down the nodes
#* MiniSolrCcoudCluster.shutdown() calls shutdown on each of the jetty 
instances in independent threads so they can be shutdown in parallel, but it 
still waits for all the jetties to finish their shutdown before it let's the 
test finish -- and if the lifecycle of the executor is beingmanaged correctly, 
souldn't the shutdown of the Solr node block until these autoscaling executors 
finish their shutdown?
#* so even if one of these executor tasks was effectively blocked forever, 
shouldn't that be causing the test to timeout, not report a leaked thread?


> TestLargeCluster.testSearchRate() failure
> -
>
> Key: SOLR-11911
> URL: https://issues.apache.org/jira/browse/SOLR-11911
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Steve Rowe
>Assignee: Andrzej Bialecki 
>Priority: Major
>
> My Jenkins found a branch_7x seed that reproduced 4/5 times for me:
> {noformat}
> Checking out Revision af9706cb89335a5aa04f9bcae0c2558a61803b50 
> (refs/remotes/origin/branch_7x)
> [...]
>[junit4]   2> NOTE: reproduce with: ant test  -Dtestcase=TestLargeCluster 
> -Dtests.method=testSearchRate -Dtests.seed=2D7724685882A83D -Dtests.slow=true 
> -Dtests.locale=be-BY -Dtests.timezone=Africa/Ouagadougou -Dtests.asserts=true 
> -Dtests.file.encoding=UTF-8
>[junit4] FAILURE 1.24s J0  | TestLargeCluster.testSearchRate <<<
>[junit4]> Throwable #1: java.lang.AssertionError: The trigger did not 
> fire at all
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([2D7724685882A83D:703F3AE197440E72]:0)
>[junit4]>  at 
> org.apache.solr.cloud.autoscaling.sim.TestLargeCluster.testSearchRate(TestLargeCluster.java:547)
>[junit4]>  at java.lang.Thread.run(Thread.java:748)
> [...]
>[junit4]   2> NOTE: test params are: codec=CheapBastard, 
> sim=RandomSimilarity(queryNorm=true): {}, locale=be-BY, 
> timezone=Africa/Ouagadougou
>[junit4]   2> NOTE: Linux 4.1.0-custom2-amd64 amd64/Oracle Corporation 
> 1.8.0_151 (64-bit)/cpus=16,threads=1,free=388243840,total=502267904
> {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-10912) Adding automatic patch validation

[Steve Rowe (JIRA)]

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

Steve Rowe commented on SOLR-10912:
---

The short-term TODO is all taken care of:
{quote}
# Commit current patch to master
# Manually test the Jenkins precommit job
# Iterate above two steps until testing is successful
# Backport the patch to branch_7x
# Copy the Precommit-LUCENE-Build job to a new PreCommit-SOLR-Build job.
# Request ASF Infrastructure to add LUCENE and SOLR to the list of projects 
that use the PreCommit-Admin Jenkins job to enqueue precommit runs for new 
patches on LUCENE/SOLR JIRAs with the "Patch Available" state. (I'll make a 
JIRA for this and link it to this issue.)
# Attach a patch with the finalized Lucene/Solr personality on YETUS-537, for 
inclusion in future Yetus releases
{quote}

I'll leave this issue open until after automatic validation has started.

> Adding automatic patch validation
> -
>
> Key: SOLR-10912
> URL: https://issues.apache.org/jira/browse/SOLR-10912
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Build
>Reporter: Mano Kovacs
>Assignee: Steve Rowe
>Priority: Major
> Attachments: SOLR-10912.ok-patch-in-core.patch, SOLR-10912.patch, 
> SOLR-10912.patch, SOLR-10912.sample-patch.patch, 
> SOLR-10912.solj-contrib-facet-error.patch
>
>
> Proposing introduction of automated patch validation, similar what Hadoop or 
> other Apache projects are using (see link). This would ensure that every 
> patch passes a certain set of criterions before getting approved. It would 
> save time for developer (faster feedback loop), save time for committers 
> (less step to do manually), and would increase quality.
> Hadoop is currently using Apache Yetus to run validations, which seems to be 
> a good direction to start. This jira could be the board of discussing the 
> preferred solution.



--
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-11749) regression-test-like functionality for bin/solr*

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-11749:


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

SOLR-11749: Introduce bin/solr test suite


> regression-test-like functionality for bin/solr*
> 
>
> Key: SOLR-11749
> URL: https://issues.apache.org/jira/browse/SOLR-11749
> Project: Solr
>  Issue Type: Wish
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: scripts and tools
>Reporter: Christine Poerschke
>Assignee: Jason Gerlowski
>Priority: Minor
> Attachments: SOLR-11749.patch, SOLR-11749.patch, SOLR-11749.patch, 
> SOLR-11749.patch, SOLR-11749.patch, test-output.txt
>
>




--
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-10912) Adding automatic patch validation

[Steve Rowe (JIRA)]

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

Steve Rowe commented on SOLR-10912:
---

bq. 6. Request ASF Infrastructure to add LUCENE and SOLR to the list of 
projects that use the PreCommit-Admin Jenkins job to enqueue precommit runs for 
new patches on LUCENE/SOLR JIRAs with the "Patch Available" state. (I'll make a 
JIRA for this and link it to this issue.)

Done: INFRA-16194

> Adding automatic patch validation
> -
>
> Key: SOLR-10912
> URL: https://issues.apache.org/jira/browse/SOLR-10912
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Build
>Reporter: Mano Kovacs
>Assignee: Steve Rowe
>Priority: Major
> Attachments: SOLR-10912.ok-patch-in-core.patch, SOLR-10912.patch, 
> SOLR-10912.patch, SOLR-10912.sample-patch.patch, 
> SOLR-10912.solj-contrib-facet-error.patch
>
>
> Proposing introduction of automated patch validation, similar what Hadoop or 
> other Apache projects are using (see link). This would ensure that every 
> patch passes a certain set of criterions before getting approved. It would 
> save time for developer (faster feedback loop), save time for committers 
> (less step to do manually), and would increase quality.
> Hadoop is currently using Apache Yetus to run validations, which seems to be 
> a good direction to start. This jira could be the board of discussing the 
> preferred solution.



--
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-12059) Unable to rename solr.xml

[Edwin Yeo Zheng Lin (JIRA)]

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

Edwin Yeo Zheng Lin commented on SOLR-12059:


We want to rename the solr.xml to add some versioning and date to the file 
name. This helps in many ways including when we upgrade the Solr to newer 
version the old version configuration files stay intact and will not be 
replaced accidentally. Another reason is for providing a means to revert to 
last configurations if something goes wrong after changing solr.xml or other 
config xml files!



As we mentioned, we could make changes to almost all xml config files except 
solr.xml, so I believe if all the rest can be renamed why not solr.xml?

> Unable to rename solr.xml
> -
>
> Key: SOLR-12059
> URL: https://issues.apache.org/jira/browse/SOLR-12059
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 6.5.1
> Environment: Renaming of solr,xml in the $SOLR_HOME directory
>Reporter: Edwin Yeo Zheng Lin
>Priority: Major
>
> I am able to rename the flie names like solrconfig.xml and solr.log to custom 
> names like myconfig.xml and my.log quite seamlessly. 
> However, I am not able to rename the same for solr.xml. Understand that the 
> solr.xml is hard-coded at the SolrXmlConfig.java. Meaning it requires a 
> re-compile of the Jar file in order to rename it.
> Since we can rename files like solrconfig.xml from the properties files, so 
> we should do the same for solr.xml?
>  
>  



--
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] (SOLR-10912) Adding automatic patch validation

[Steve Rowe (JIRA)]

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

Steve Rowe edited comment on SOLR-10912 at 3/16/18 1:02 AM:


{quote}The current change is here: 
[https://github.com/apache/lucene-solr/compare/master...manokovacs:feature/SOLR-10912]
{quote}
I've attached a patch with a modified version of Mano's branch, and I plan on 
committing it shortly in order to start testing the Jenkins job I've set up at 
[https://builds.apache.org/view/PreCommit+Builds/job/PreCommit-LUCENE-Build/] 
(the script in this job's config, a copy of which is in the patch, expects the 
Yetus personality to be committed to the Git repo).
h2. From Mano's "Steps remaining":
{quote}Multiple module test currently duplicates the failed test result, fixing 
shortly.
{quote}
Fixed.
{quote}Add test to call -validate-source-patterns
{quote}
Added. FYI, I had to rename the Ant task to remove the leading dash so that it 
can be invoked from the cmdline.
{quote}Finalize the runner script to setup Yetus, similarly to Hadoop.
{quote}
Done.
{quote}Verify the test-patch with Github PR
{quote}
Since [~aw] wrote above that "The job on Jenkins that feeds test-patch is NOT 
github aware", I don't plan on doing this verification. I'll include this on a 
TODO list below.
{quote}Add Patch Available status for SOLR project (and update the script to 
look for that).
{quote}
Done.
{quote}Add Precommit-SOLR and Precommit-LUCENE jenkins jobs
{quote}
I've added a PreCommit-LUCENE-Build job (linked above), and once I've committed 
the patch I've attached here (on master only initially), I'll manually invoke 
it for testing (via "Build with Parameters").
h2. From Mano's "Open questions":
{quote}1. As you can see, a patch with two log entries had 6 (flaky) test 
failures. Assuming flaky tests will not go away very soon, would it still be 
useful to have this test-patch?
{quote}
I think now is a perfect time to do this, given the current efforts focused on 
reducing test flakiness.
{quote}2. I propose starting with the smallest set of tests (ie. affected 
modules) and extend them later to dependent modules.
{quote}
+1.
h2. Stuff I changed from Mano's branch that is not already mentioned above:
 # Renamed the personality file (was {{solr-yetus-personality.sh}}, now 
{{lucene-solr-yetus-personality.sh}}).
 # Improved handling of Lucene modules.
 # Added basic ref guide validation, via {{ant bare-bones-html-validation}}; 
note that this is not the kind of missing-doc validation discussed above in 
this issue; that idea was spun off as SOLR-11419
 # Standardized Lucene/Solr-specific plugins to make them run only if they need 
to.
 # Added some user- and dev-level documentation to the local runner script and 
personality files.

h2. Short-term TODO:
 # Commit current patch to master
 # Manually test the Jenkins precommit job
 # Iterate above two steps until testing is successful
 # Backport the patch to branch_7x
 # Copy the Precommit-LUCENE-Build job to a new PreCommit-SOLR-Build job.
 # Request ASF Infrastructure to add LUCENE and SOLR to the list of projects 
that use the PreCommit-Admin Jenkins job to enqueue precommit runs for new 
patches on LUCENE/SOLR JIRAs with the "Patch Available" state. (I'll make a 
JIRA for this and link it to this issue.)
 # Attach a patch with the finalized Lucene/Solr personality on YETUS-537, for 
inclusion in future Yetus releases

*edit*: Added Shawn's improvement ideas to the TODO list below:

h2. Longer-term TODO (to be dealt with on further issues):
 # Solr missing-doc validation: SOLR-11419.
 # Add handling of module dependencies and build ordering.
 # Currently when any test or non-test file is changed in a module, all unit 
tests are run in that module. I think a faster version of this is possible when 
there are test-only changes: just the changed test suites could be run, rather 
than all of the module's tests.
 # If there's not an entry in CHANGES.txt that mentions the issue number 
(either the lucene or solr file as appropriate), that should be a -1 (or maybe 
-0?)
# How about a -1 if a SOLR patch makes changes to lucene, or vice versa? If 
there is an entry in the appropriate CHANGES.txt file for the issue, turn that 
into a -0. That way, we have better assurance that if a commit for one part of 
the project requires changes to the other part, there will be a release note.


was (Author: steve_rowe):
{quote}The current change is here: 
[https://github.com/apache/lucene-solr/compare/master...manokovacs:feature/SOLR-10912]
{quote}
I've attached a patch with a modified version of Mano's branch, and I plan on 
committing it shortly in order to start testing the Jenkins job I've set up at 
[https://builds.apache.org/view/PreCommit+Builds/job/PreCommit-LUCENE-Build/] 
(the script in this job's config, a copy of which is in the patch, expects the 
Yetus personality to 

[jira] [Commented] (SOLR-10912) Adding automatic patch validation

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10912:


Commit 077f19bdc5bc6b4a27d5604f6e83f166457374a7 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=077f19b ]

SOLR-10912: attempted personality plugins fix: trying just junit/javac instead 
of unit/compile (which didn't actually do anything at all)


> Adding automatic patch validation
> -
>
> Key: SOLR-10912
> URL: https://issues.apache.org/jira/browse/SOLR-10912
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Build
>Reporter: Mano Kovacs
>Assignee: Steve Rowe
>Priority: Major
> Attachments: SOLR-10912.ok-patch-in-core.patch, SOLR-10912.patch, 
> SOLR-10912.patch, SOLR-10912.sample-patch.patch, 
> SOLR-10912.solj-contrib-facet-error.patch
>
>
> Proposing introduction of automated patch validation, similar what Hadoop or 
> other Apache projects are using (see link). This would ensure that every 
> patch passes a certain set of criterions before getting approved. It would 
> save time for developer (faster feedback loop), save time for committers 
> (less step to do manually), and would increase quality.
> Hadoop is currently using Apache Yetus to run validations, which seems to be 
> a good direction to start. This jira could be the board of discussing the 
> preferred solution.



--
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-10912) Adding automatic patch validation

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10912:


Commit 285bc554a6bdd0dec686ad4e5b02256836ce61e6 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=285bc55 ]

SOLR-10912: updating copy of Jenkins precommit job script: proc max limit code 
seems not to work on jenkins slaves, so put it at a fixed 10k; added 
customization of artifact url so console output links in the JIRA comment 
report work properly; no longer attempting to cache the yetus download, since 
it always downloads every time anyway.


> Adding automatic patch validation
> -
>
> Key: SOLR-10912
> URL: https://issues.apache.org/jira/browse/SOLR-10912
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Build
>Reporter: Mano Kovacs
>Assignee: Steve Rowe
>Priority: Major
> Attachments: SOLR-10912.ok-patch-in-core.patch, SOLR-10912.patch, 
> SOLR-10912.patch, SOLR-10912.sample-patch.patch, 
> SOLR-10912.solj-contrib-facet-error.patch
>
>
> Proposing introduction of automated patch validation, similar what Hadoop or 
> other Apache projects are using (see link). This would ensure that every 
> patch passes a certain set of criterions before getting approved. It would 
> save time for developer (faster feedback loop), save time for committers 
> (less step to do manually), and would increase quality.
> Hadoop is currently using Apache Yetus to run validations, which seems to be 
> a good direction to start. This jira could be the board of discussing the 
> preferred solution.



--
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-10912) Adding automatic patch validation

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10912:


Commit 1c31773fa303e5a48efb1e8af3efae8cd844d760 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=1c31773 ]

SOLR-10912: personality fix: in solr-ref-guide, don't run compile and unit 
plugins. Also, consistently use curly brackets when interpolating variables


> Adding automatic patch validation
> -
>
> Key: SOLR-10912
> URL: https://issues.apache.org/jira/browse/SOLR-10912
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Build
>Reporter: Mano Kovacs
>Assignee: Steve Rowe
>Priority: Major
> Attachments: SOLR-10912.ok-patch-in-core.patch, SOLR-10912.patch, 
> SOLR-10912.patch, SOLR-10912.sample-patch.patch, 
> SOLR-10912.solj-contrib-facet-error.patch
>
>
> Proposing introduction of automated patch validation, similar what Hadoop or 
> other Apache projects are using (see link). This would ensure that every 
> patch passes a certain set of criterions before getting approved. It would 
> save time for developer (faster feedback loop), save time for committers 
> (less step to do manually), and would increase quality.
> Hadoop is currently using Apache Yetus to run validations, which seems to be 
> a good direction to start. This jira could be the board of discussing the 
> preferred solution.



--
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-10912) Adding automatic patch validation

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10912:


Commit dd3ace8ed68987bfc5562474bac455b923e2e14f 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=dd3ace8 ]

SOLR-10912: excluding apparently unnecessary plugins: 'junit' and 'javac' (the 
'unit' and 'compile' plugins are producing output but the 'j' ones aren't)


> Adding automatic patch validation
> -
>
> Key: SOLR-10912
> URL: https://issues.apache.org/jira/browse/SOLR-10912
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Build
>Reporter: Mano Kovacs
>Assignee: Steve Rowe
>Priority: Major
> Attachments: SOLR-10912.ok-patch-in-core.patch, SOLR-10912.patch, 
> SOLR-10912.patch, SOLR-10912.sample-patch.patch, 
> SOLR-10912.solj-contrib-facet-error.patch
>
>
> Proposing introduction of automated patch validation, similar what Hadoop or 
> other Apache projects are using (see link). This would ensure that every 
> patch passes a certain set of criterions before getting approved. It would 
> save time for developer (faster feedback loop), save time for committers 
> (less step to do manually), and would increase quality.
> Hadoop is currently using Apache Yetus to run validations, which seems to be 
> a good direction to start. This jira could be the board of discussing the 
> preferred solution.



--
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-10912) Adding automatic patch validation

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10912:


Commit a3980add396e878b8b5693c8f8b6e0b89a0ebda0 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=a3980ad ]

SOLR-10912: reverting personality plugins changes to include junit+unit and 
javac+compile, since this combo works, and neither one individually does.


> Adding automatic patch validation
> -
>
> Key: SOLR-10912
> URL: https://issues.apache.org/jira/browse/SOLR-10912
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Build
>Reporter: Mano Kovacs
>Assignee: Steve Rowe
>Priority: Major
> Attachments: SOLR-10912.ok-patch-in-core.patch, SOLR-10912.patch, 
> SOLR-10912.patch, SOLR-10912.sample-patch.patch, 
> SOLR-10912.solj-contrib-facet-error.patch
>
>
> Proposing introduction of automated patch validation, similar what Hadoop or 
> other Apache projects are using (see link). This would ensure that every 
> patch passes a certain set of criterions before getting approved. It would 
> save time for developer (faster feedback loop), save time for committers 
> (less step to do manually), and would increase quality.
> Hadoop is currently using Apache Yetus to run validations, which seems to be 
> a good direction to start. This jira could be the board of discussing the 
> preferred solution.



--
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-10912) Adding automatic patch validation

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10912:


Commit 3e0d245cf1152fa12ebb52a846bb3deff2d6ea7f 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=3e0d245 ]

SOLR-10912: Add scripts for automatic patch validation


> Adding automatic patch validation
> -
>
> Key: SOLR-10912
> URL: https://issues.apache.org/jira/browse/SOLR-10912
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Build
>Reporter: Mano Kovacs
>Assignee: Steve Rowe
>Priority: Major
> Attachments: SOLR-10912.ok-patch-in-core.patch, SOLR-10912.patch, 
> SOLR-10912.patch, SOLR-10912.sample-patch.patch, 
> SOLR-10912.solj-contrib-facet-error.patch
>
>
> Proposing introduction of automated patch validation, similar what Hadoop or 
> other Apache projects are using (see link). This would ensure that every 
> patch passes a certain set of criterions before getting approved. It would 
> save time for developer (faster feedback loop), save time for committers 
> (less step to do manually), and would increase quality.
> Hadoop is currently using Apache Yetus to run validations, which seems to be 
> a good direction to start. This jira could be the board of discussing the 
> preferred solution.



--
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-12106) Validate patch validation (solr edition)

[Lucene/Solr QA (JIRA)]

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

Lucene/Solr QA commented on SOLR-12106:
---

| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green}  0m 
 0s{color} | {color:green} The patch appears to include 1 new or modified test 
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  0m 
57s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  0m 
57s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green}  0m 
57s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Release audit (RAT) {color} | 
{color:green}  1m  1s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Check forbidden APIs {color} | 
{color:green}  0m 57s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Validate source patterns {color} | 
{color:green}  0m 57s{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} Validate ref guide {color} | {color:red}  
0m 57s{color} | {color:red} Validate ref guide bare-bones-html-validation 
failed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:red}-1{color} | {color:red} unit {color} | {color:red}  0m 25s{color} 
| {color:red} test-framework in the patch failed. {color} |
| {color:black}{color} | {color:black} {color} | {color:black}  5m 33s{color} | 
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | SOLR-12106 |
| JIRA Patch URL | 
https://issues.apache.org/jira/secure/attachment/12914788/SOLR-12106.patch |
| Optional Tests |  ratsources  validatesourcepatterns  validaterefguide  
compile  javac  unit  checkforbiddenapis  |
| uname | Linux lucene1-us-west 3.13.0-88-generic #135-Ubuntu SMP Wed Jun 8 
21:10:42 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | ant |
| Personality | 
/home/jenkins/jenkins-slave/workspace/PreCommit-SOLR-Build/sourcedir/dev-tools/test-patch/lucene-solr-yetus-personality.sh
 |
| git revision | master / 298063e |
| ant | version: Apache Ant(TM) version 1.9.3 compiled on April 8 2014 |
| Default Java | 1.8.0_144 |
| Validate ref guide | 
https://builds.apache.org/job/PreCommit-SOLR-Build/5/artifact/out/patch-bare-bones-html-validation-solr_solr-ref-guide.txt
 |
| unit | 
https://builds.apache.org/job/PreCommit-SOLR-Build/5/artifact/out/patch-unit-solr_test-framework.txt
 |
|  Test Results | 
https://builds.apache.org/job/PreCommit-SOLR-Build/5/testReport/ |
| modules | C: solr/solr-ref-guide solr/test-framework U: solr |
| Console output | https://builds.apache.org/job/PreCommit-SOLR-Build/5/console 
|
| Powered by | Apache Yetus 0.7.0   http://yetus.apache.org |


This message was automatically generated.



> Validate patch validation (solr edition)
> 
>
> Key: SOLR-12106
> URL: https://issues.apache.org/jira/browse/SOLR-12106
> Project: Solr
>  Issue Type: Test
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Tests
>Reporter: Steve Rowe
>Assignee: Steve Rowe
>Priority: Trivial
> Attachments: SOLR-12106.patch
>
>
> Issue to host patches for testing automatic patch validation.



--
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-10912) Adding automatic patch validation

[Steve Rowe (JIRA)]

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

Steve Rowe commented on SOLR-10912:
---

bq. compile does a basic compile test. javac looks in the output log for 
specific java warnings/errors generated from the compile phase when java's lint 
mode is activated.

Thanks [~aw], good to know.  Unfortunately the plugins are pretty lightly 
documented: AFAICT only a subset of the built-in plugins' individual *methods* 
are documented in the api ref, with no whole-builtin-plugin docs I could find; 
I haven't dug into the source much yet, other than test-patch.sh itself and 
some of the bundled example personalities.

> Adding automatic patch validation
> -
>
> Key: SOLR-10912
> URL: https://issues.apache.org/jira/browse/SOLR-10912
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Build
>Reporter: Mano Kovacs
>Assignee: Steve Rowe
>Priority: Major
> Attachments: SOLR-10912.ok-patch-in-core.patch, SOLR-10912.patch, 
> SOLR-10912.patch, SOLR-10912.sample-patch.patch, 
> SOLR-10912.solj-contrib-facet-error.patch
>
>
> Proposing introduction of automated patch validation, similar what Hadoop or 
> other Apache projects are using (see link). This would ensure that every 
> patch passes a certain set of criterions before getting approved. It would 
> save time for developer (faster feedback loop), save time for committers 
> (less step to do manually), and would increase quality.
> Hadoop is currently using Apache Yetus to run validations, which seems to be 
> a good direction to start. This jira could be the board of discussing the 
> preferred solution.



--
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-10912) Adding automatic patch validation

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10912:


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

SOLR-10912: personality fix: in solr-ref-guide, don't run compile and unit 
plugins. Also, consistently use curly brackets when interpolating variables


> Adding automatic patch validation
> -
>
> Key: SOLR-10912
> URL: https://issues.apache.org/jira/browse/SOLR-10912
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Build
>Reporter: Mano Kovacs
>Assignee: Steve Rowe
>Priority: Major
> Attachments: SOLR-10912.ok-patch-in-core.patch, SOLR-10912.patch, 
> SOLR-10912.patch, SOLR-10912.sample-patch.patch, 
> SOLR-10912.solj-contrib-facet-error.patch
>
>
> Proposing introduction of automated patch validation, similar what Hadoop or 
> other Apache projects are using (see link). This would ensure that every 
> patch passes a certain set of criterions before getting approved. It would 
> save time for developer (faster feedback loop), save time for committers 
> (less step to do manually), and would increase quality.
> Hadoop is currently using Apache Yetus to run validations, which seems to be 
> a good direction to start. This jira could be the board of discussing the 
> preferred solution.



--
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-12109) Should randomize enable/disable on all caches in all tests unless explicitly required for testing

[Hoss Man (JIRA)]

Hoss Man created SOLR-12109:
---

 Summary: Should randomize enable/disable on all caches in all 
tests unless explicitly required for testing
 Key: SOLR-12109
 URL: https://issues.apache.org/jira/browse/SOLR-12109
 Project: Solr
  Issue Type: Test
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Hoss Man


Enabling/disabling caches should not affect behavior -- just performance.

And yet, w/caches enabled by default (either implicitly or explicitly) in our 
test configs, it's easy to overlook bugs that exist because of code assumptions 
that only hold up when cahces are enabled -- SOLR-12108 & SOLR-12107 are 2 
great examples of this.

We should update all of our configs used in tests (including the techproduct 
sample configs used for "example" tests) to use sysprops to enable/disable all 
the caches (documentCache, filterCache, queyResultCache) and then make 
SolrTestCaseJ4 randomize all of those system properties independently.  Tests 
that depend on explicit state should explicitly set those properties.



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

[Policeman Jenkins Server]

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

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

Error Message:
java.util.concurrent.TimeoutException: Could not connect to ZooKeeper 
127.0.0.1:41409 within 3 ms

Stack Trace:
org.apache.solr.common.SolrException: java.util.concurrent.TimeoutException: 
Could not connect to ZooKeeper 127.0.0.1:41409 within 3 ms
at __randomizedtesting.SeedInfo.seed([DF44788DBE20EF01]:0)
at 
org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:183)
at 
org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:120)
at 
org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:115)
at 
org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:102)
at 
org.apache.solr.cloud.MiniSolrCloudCluster.waitForAllNodes(MiniSolrCloudCluster.java:268)
at 
org.apache.solr.cloud.MiniSolrCloudCluster.(MiniSolrCloudCluster.java:262)
at 
org.apache.solr.cloud.SolrCloudTestCase$Builder.configure(SolrCloudTestCase.java:190)
at 
org.apache.solr.cloud.DeleteLastCustomShardedReplicaTest.setupCluster(DeleteLastCustomShardedReplicaTest.java:31)
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$6.evaluate(RandomizedRunner.java:874)
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)
Caused by: java.util.concurrent.TimeoutException: Could not connect to 
ZooKeeper 127.0.0.1:41409 within 3 ms
at 
org.apache.solr.common.cloud.ConnectionManager.waitForConnected(ConnectionManager.java:232)
at 
org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:175)
... 31 more


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

Error Message:
28 threads leaked from SUITE scope at 
org.apache.solr.cloud.DeleteLastCustomShardedReplicaTest: 1) 
Thread[id=7335, 
name=qtp1329013312-7335-acceptor-0@ac94e40-ServerConnector@247acfac{HTTP/1.1,[http/1.1]}{127.0.0.1:58786},
 state=RUNNABLE, group=TGRP-DeleteLastCustomShardedReplicaTest] at 
sun.nio.ch.ServerSocketChannelImpl.accept0(Native Method) at 
sun.nio.ch.ServerSocketChannelImpl.accept(ServerSocketChannelImpl.java:422) 
at 
sun.nio.ch.ServerSocketChannelImpl.accept(ServerSocketChannelImpl.java:250) 
at 
org.eclipse.jetty.server.ServerConnector.accept(ServerConnector.java:379)   
  at 
org.eclipse.jetty.server.AbstractConnector$Acceptor.run(AbstractConnector.java:638)
 at 

[jira] [Commented] (SOLR-12107) [child] doc transformer used w/o uniqueKey in 'fl' fails with NPE unless documentCache is enabled

[Hoss Man (JIRA)]

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

Hoss Man commented on SOLR-12107:
-

The patch in SOLR-11891 to make DocStreamer more efficient exposes this bug in 
pre-existing tests, and includes the necessary fix

> [child] doc transformer used w/o uniqueKey in 'fl' fails with NPE unless 
> documentCache is enabled
> -
>
> Key: SOLR-12107
> URL: https://issues.apache.org/jira/browse/SOLR-12107
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Assignee: Hoss Man
>Priority: Major
>
> discovered this while working on SOLR-11891...
> The ChildDocumentTransformer implicitly assumes the uniqueKey field will 
> allways be available when transforming the doc, w/o explicitly requesting it 
> via {{getExtraRequestFields()}}
> Because of the existing sloppy code in SOLR-11891, that means this bug in 
> ChildDocumentTransformer only impacts current users if the documentCache is 
> disabled
> 
> Example steps to reproduce w/techproducts config assuming {{solrconfig.xml}} 
> is edited to disable documentCache...
> {noformat}
> $ curl 'http://localhost:8983/solr/techproducts/update?commit=true' -H 
> 'Content-Type: application/json' --data-binary '[
> >   {
> > "id": "1",
> > "title": "Solr adds block join support",
> > "content_type": "parentDocument",
> > "_childDocuments_": [
> >   {
> > "id": "2",
> > "comments": "SolrCloud supports it too!"
> >   }
> > ]
> >   },
> >   {
> > "id": "3",
> > "title": "New Lucene and Solr release is out",
> > "content_type": "parentDocument",
> > "_childDocuments_": [
> >   {
> > "id": "4",
> > "comments": "Lots of new features"
> >   }
> > ]
> >   }
> > ]'
> {
>   "responseHeader":{
> "status":0,
> "QTime":69}}
> $ curl 'http://localhost:8983/solr/techproducts/query?q=id:1'
> {
>   "responseHeader":{
> "status":0,
> "QTime":5,
> "params":{
>   "q":"id:1"}},
>   "response":{"numFound":1,"start":0,"docs":[
>   {
> "id":"1",
> "title":["Solr adds block join support"],
> "content_type":["parentDocument"],
> "_version_":1595047178033692672}]
>   }}
> $ curl 
> 'http://localhost:8983/solr/techproducts/query?q=id:1=id,%5Bchild+parentFilter="content_type:parentDocument"%5D'
> {
>   "responseHeader":{
> "status":0,
> "QTime":0,
> "params":{
>   "q":"id:1",
>   "fl":"id,[child parentFilter=\"content_type:parentDocument\"]"}},
>   "response":{"numFound":1,"start":0,"docs":[
>   {
> "id":"1",
> "_childDocuments_":[
> {
>   "id":"2",
>   "comments":"SolrCloud supports it too!",
>   "_version_":1595047178033692672}]}]
>   }}
> $ curl 
> 'http://localhost:8983/solr/techproducts/query?q=id:1=%5Bchild+parentFilter="content_type:parentDocument"%5D'
> {
>   "error":{
> "trace":"java.lang.NullPointerException\n\tat 
> org.apache.solr.response.transform.ChildDocTransformer.transform(ChildDocTransformerFactory.java:133)\n\tat
>  org.apache.solr.response.DocsStreamer.next(DocsStreamer.java:120)\n\tat 
> org.apache.solr.response.DocsStreamer.next(DocsStreamer.java:57)\n\tat 
> org.apache.solr.response.TextResponseWriter.writeDocuments(TextResponseWriter.java:275)\n\tat
>  
> org.apache.solr.response.TextResponseWriter.writeVal(TextResponseWriter.java:161)\n\tat
>  
> org.apache.solr.response.JSONWriter.writeNamedListAsMapWithDups(JSONResponseWriter.java:209)\n\tat
>  
> org.apache.solr.response.JSONWriter.writeNamedList(JSONResponseWriter.java:325)\n\tat
>  
> org.apache.solr.response.JSONWriter.writeResponse(JSONResponseWriter.java:120)\n\tat
>  
> org.apache.solr.response.JSONResponseWriter.write(JSONResponseWriter.java:71)\n\tat
>  
> org.apache.solr.response.QueryResponseWriterUtil.writeQueryResponse(QueryResponseWriterUtil.java:65)\n\tat
>  
> org.apache.solr.servlet.HttpSolrCall.writeResponse(HttpSolrCall.java:789)\n\tat
>  org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:526)\n\tat 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:384)\n\tat
>  
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:330)\n\tat
>  
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1629)\n\tat
>  
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:533)\n\tat
>  
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)\n\tat
>  
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)\n\tat
>  
> 

[jira] [Commented] (SOLR-12108) raw transformers ([json] and [xml]) drop the field value if wt is not a match and documentCache is not enabled

[Hoss Man (JIRA)]

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

Hoss Man commented on SOLR-12108:
-

The patch in SOLR-11891 to make DocStreamer more efficient exposes this bug in 
pre-existing tests, and includes the necessary fix

> raw transformers ([json] and [xml]) drop the field value if wt is not a match 
> and documentCache is not enabled
> --
>
> Key: SOLR-12108
> URL: https://issues.apache.org/jira/browse/SOLR-12108
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Priority: Major
>
> discovered this while working on SOLR-11891...
> The {{RawValueTransformerFactory}} class is suppose to treat the field value 
> as a normal string in situations where an instance is limited by the {{wt}} 
> param (which it is automatically for the default {{[json]}} and {{[xml]}} 
> transformers.
> This is currently implemented by {{RawValueTransformerFactory.create()}} 
> assuming it can just return "null" if the ResponseWriter in use doesn't match 
> - but because of how this transformer abuses the "key" to implicitly indicate 
> the field to be returned (ie: {{my_json_fieldName:[json]}}, it means that 
> nothing about the resulting {{ReturnFields}} datastructure indicates that the 
> field ({{my_json_fieldName}}) should be returned at all.
> Because of the existing sloppy code in SOLR-11891, that means this bug in 
> ChildDocumentTransformer only impacts current users if the documentCache is 
> disabled
> 
> Example steps to reproduce w/techproducts config assuming {{solrconfig.xml}} 
> is edited to disable documentCache...
> {noformat}
> $ curl 'http://localhost:8983/solr/techproducts/update?commit=true' -H 
> 'Content-Type: application/json' --data-binary '[
>   {
> "id": "1",
> "raw_s":"{\"raw\":\"json\"}" } ]'
> {
>   "responseHeader":{
> "status":0,
> "QTime":39}}
> $ curl 'http://localhost:8983/solr/techproducts/query?wt=json=id:1=raw_s'
> {
>   "responseHeader":{
> "status":0,
> "QTime":2,
> "params":{
>   "q":"id:1",
>   "fl":"raw_s",
>   "wt":"json"}},
>   "response":{"numFound":1,"start":0,"docs":[
>   {
> "raw_s":"{\"raw\":\"json\"}"}]
>   }}
> $ curl 
> 'http://localhost:8983/solr/techproducts/query?wt=json=id:1=raw_s:%5Bjson%5D'
> {
>   "responseHeader":{
> "status":0,
> "QTime":0,
> "params":{
>   "q":"id:1",
>   "fl":"raw_s:[json]",
>   "wt":"json"}},
>   "response":{"numFound":1,"start":0,"docs":[
>   {
> "raw_s":{"raw":"json"}}]
>   }}
> $ curl 
> 'http://localhost:8983/solr/techproducts/query?wt=xml=id:1=raw_s:%5Bjson%5D'
> 
> 
> 
>   0
>   0
>   
> id:1
> raw_s:[json]
> xml
>   
> 
> 
>   
> 
> 
> {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] [Assigned] (SOLR-12108) raw transformers ([json] and [xml]) drop the field value if wt is not a match and documentCache is not enabled

[Hoss Man (JIRA)]

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

Hoss Man reassigned SOLR-12108:
---

Assignee: Hoss Man

> raw transformers ([json] and [xml]) drop the field value if wt is not a match 
> and documentCache is not enabled
> --
>
> Key: SOLR-12108
> URL: https://issues.apache.org/jira/browse/SOLR-12108
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Assignee: Hoss Man
>Priority: Major
>
> discovered this while working on SOLR-11891...
> The {{RawValueTransformerFactory}} class is suppose to treat the field value 
> as a normal string in situations where an instance is limited by the {{wt}} 
> param (which it is automatically for the default {{[json]}} and {{[xml]}} 
> transformers.
> This is currently implemented by {{RawValueTransformerFactory.create()}} 
> assuming it can just return "null" if the ResponseWriter in use doesn't match 
> - but because of how this transformer abuses the "key" to implicitly indicate 
> the field to be returned (ie: {{my_json_fieldName:[json]}}, it means that 
> nothing about the resulting {{ReturnFields}} datastructure indicates that the 
> field ({{my_json_fieldName}}) should be returned at all.
> Because of the existing sloppy code in SOLR-11891, that means this bug in 
> ChildDocumentTransformer only impacts current users if the documentCache is 
> disabled
> 
> Example steps to reproduce w/techproducts config assuming {{solrconfig.xml}} 
> is edited to disable documentCache...
> {noformat}
> $ curl 'http://localhost:8983/solr/techproducts/update?commit=true' -H 
> 'Content-Type: application/json' --data-binary '[
>   {
> "id": "1",
> "raw_s":"{\"raw\":\"json\"}" } ]'
> {
>   "responseHeader":{
> "status":0,
> "QTime":39}}
> $ curl 'http://localhost:8983/solr/techproducts/query?wt=json=id:1=raw_s'
> {
>   "responseHeader":{
> "status":0,
> "QTime":2,
> "params":{
>   "q":"id:1",
>   "fl":"raw_s",
>   "wt":"json"}},
>   "response":{"numFound":1,"start":0,"docs":[
>   {
> "raw_s":"{\"raw\":\"json\"}"}]
>   }}
> $ curl 
> 'http://localhost:8983/solr/techproducts/query?wt=json=id:1=raw_s:%5Bjson%5D'
> {
>   "responseHeader":{
> "status":0,
> "QTime":0,
> "params":{
>   "q":"id:1",
>   "fl":"raw_s:[json]",
>   "wt":"json"}},
>   "response":{"numFound":1,"start":0,"docs":[
>   {
> "raw_s":{"raw":"json"}}]
>   }}
> $ curl 
> 'http://localhost:8983/solr/techproducts/query?wt=xml=id:1=raw_s:%5Bjson%5D'
> 
> 
> 
>   0
>   0
>   
> id:1
> raw_s:[json]
> xml
>   
> 
> 
>   
> 
> 
> {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] [Created] (SOLR-12108) raw transformers ([json] and [xml]) drop the field value if wt is not a match and documentCache is not enabled

[Hoss Man (JIRA)]

Hoss Man created SOLR-12108:
---

 Summary: raw transformers ([json] and [xml]) drop the field value 
if wt is not a match and documentCache is not enabled
 Key: SOLR-12108
 URL: https://issues.apache.org/jira/browse/SOLR-12108
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Hoss Man


discovered this while working on SOLR-11891...

The {{RawValueTransformerFactory}} class is suppose to treat the field value as 
a normal string in situations where an instance is limited by the {{wt}} param 
(which it is automatically for the default {{[json]}} and {{[xml]}} 
transformers.

This is currently implemented by {{RawValueTransformerFactory.create()}} 
assuming it can just return "null" if the ResponseWriter in use doesn't match - 
but because of how this transformer abuses the "key" to implicitly indicate the 
field to be returned (ie: {{my_json_fieldName:[json]}}, it means that nothing 
about the resulting {{ReturnFields}} datastructure indicates that the field 
({{my_json_fieldName}}) should be returned at all.

Because of the existing sloppy code in SOLR-11891, that means this bug in 
ChildDocumentTransformer only impacts current users if the documentCache is 
disabled

Example steps to reproduce w/techproducts config assuming {{solrconfig.xml}} is 
edited to disable documentCache...

{noformat}
$ curl 'http://localhost:8983/solr/techproducts/update?commit=true' -H 
'Content-Type: application/json' --data-binary '[
  {
"id": "1",
"raw_s":"{\"raw\":\"json\"}" } ]'
{
  "responseHeader":{
"status":0,
"QTime":39}}
$ curl 'http://localhost:8983/solr/techproducts/query?wt=json=id:1=raw_s'
{
  "responseHeader":{
"status":0,
"QTime":2,
"params":{
  "q":"id:1",
  "fl":"raw_s",
  "wt":"json"}},
  "response":{"numFound":1,"start":0,"docs":[
  {
"raw_s":"{\"raw\":\"json\"}"}]
  }}
$ curl 
'http://localhost:8983/solr/techproducts/query?wt=json=id:1=raw_s:%5Bjson%5D'
{
  "responseHeader":{
"status":0,
"QTime":0,
"params":{
  "q":"id:1",
  "fl":"raw_s:[json]",
  "wt":"json"}},
  "response":{"numFound":1,"start":0,"docs":[
  {
"raw_s":{"raw":"json"}}]
  }}
$ curl 
'http://localhost:8983/solr/techproducts/query?wt=xml=id:1=raw_s:%5Bjson%5D'




  0
  0
  
id:1
raw_s:[json]
xml
  


  


{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-11891) DocsStreamer populates SolrDocument w/unnecessary fields

[Hoss Man (JIRA)]

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

Hoss Man updated SOLR-11891:

Summary: DocsStreamer populates SolrDocument w/unnecessary fields  (was: 
BinaryResponseWriter fetches unnecessary fields)

> DocsStreamer populates SolrDocument w/unnecessary fields
> 
>
> Key: SOLR-11891
> URL: https://issues.apache.org/jira/browse/SOLR-11891
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Response Writers
>Affects Versions: 5.4, 6.4.2, 6.6.2
>Reporter: wei wang
>Priority: Major
> Attachments: DocsStreamer.java.diff, SOLR-11891.patch, 
> SOLR-11891.patch.BAD
>
>
> We observe that solr query time increases significantly with the number of 
> rows requested,  even all we retrieve for each document is just fl=id,score.  
> Debugged a bit and see that most of the increased time was spent in 
> BinaryResponseWriter,  converting lucene document into SolrDocument.  Inside 
> convertLuceneDocToSolrDoc():   
> [https://github.com/apache/lucene-solr/blob/df874432b9a17b547acb24a01d3491839e6a6b69/solr/core/src/java/org/apache/solr/response/DocsStreamer.java#L182]
>  
> I am a bit puzzled why we need to iterate through all the fields in the 
> document. Why can’t we just iterate through the requested field list?    
> [https://github.com/apache/lucene-solr/blob/df874432b9a17b547acb24a01d3491839e6a6b69/solr/core/src/java/org/apache/solr/response/DocsStreamer.java#L156]
>  
> e.g. when pass in the field list as 
> sdoc = convertLuceneDocToSolrDoc(doc, rctx.getSearcher().getSchema(), fnames)
> and just iterate through fnames,  there is a significant performance boost in 
> our case.  



--
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-11891) BinaryResponseWriter fetches unnecessary fields

[Hoss Man (JIRA)]

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

Hoss Man updated SOLR-11891:

Attachment: SOLR-11891.patch

> BinaryResponseWriter fetches unnecessary fields
> ---
>
> Key: SOLR-11891
> URL: https://issues.apache.org/jira/browse/SOLR-11891
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Response Writers
>Affects Versions: 5.4, 6.4.2, 6.6.2
>Reporter: wei wang
>Priority: Major
> Attachments: DocsStreamer.java.diff, SOLR-11891.patch, 
> SOLR-11891.patch.BAD
>
>
> We observe that solr query time increases significantly with the number of 
> rows requested,  even all we retrieve for each document is just fl=id,score.  
> Debugged a bit and see that most of the increased time was spent in 
> BinaryResponseWriter,  converting lucene document into SolrDocument.  Inside 
> convertLuceneDocToSolrDoc():   
> [https://github.com/apache/lucene-solr/blob/df874432b9a17b547acb24a01d3491839e6a6b69/solr/core/src/java/org/apache/solr/response/DocsStreamer.java#L182]
>  
> I am a bit puzzled why we need to iterate through all the fields in the 
> document. Why can’t we just iterate through the requested field list?    
> [https://github.com/apache/lucene-solr/blob/df874432b9a17b547acb24a01d3491839e6a6b69/solr/core/src/java/org/apache/solr/response/DocsStreamer.java#L156]
>  
> e.g. when pass in the field list as 
> sdoc = convertLuceneDocToSolrDoc(doc, rctx.getSearcher().getSchema(), fnames)
> and just iterate through fnames,  there is a significant performance boost in 
> our case.  



--
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-12107) [child] doc transformer used w/o uniqueKey in 'fl' fails with NPE unless documentCache is enabled

[Hoss Man (JIRA)]

Hoss Man created SOLR-12107:
---

 Summary: [child] doc transformer used w/o uniqueKey in 'fl' fails 
with NPE unless documentCache is enabled
 Key: SOLR-12107
 URL: https://issues.apache.org/jira/browse/SOLR-12107
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Hoss Man
Assignee: Hoss Man


discovered this while working on SOLR-11891...

The ChildDocumentTransformer implicitly assumes the uniqueKey field will 
allways be available when transforming the doc, w/o explicitly requesting it 
via {{getExtraRequestFields()}}

Because of the existing sloppy code in SOLR-11891, that means this bug in 
ChildDocumentTransformer only impacts current users if the documentCache is 
disabled



Example steps to reproduce w/techproducts config assuming {{solrconfig.xml}} is 
edited to disable documentCache...

{noformat}
$ curl 'http://localhost:8983/solr/techproducts/update?commit=true' -H 
'Content-Type: application/json' --data-binary '[
>   {
> "id": "1",
> "title": "Solr adds block join support",
> "content_type": "parentDocument",
> "_childDocuments_": [
>   {
> "id": "2",
> "comments": "SolrCloud supports it too!"
>   }
> ]
>   },
>   {
> "id": "3",
> "title": "New Lucene and Solr release is out",
> "content_type": "parentDocument",
> "_childDocuments_": [
>   {
> "id": "4",
> "comments": "Lots of new features"
>   }
> ]
>   }
> ]'
{
  "responseHeader":{
"status":0,
"QTime":69}}
$ curl 'http://localhost:8983/solr/techproducts/query?q=id:1'
{
  "responseHeader":{
"status":0,
"QTime":5,
"params":{
  "q":"id:1"}},
  "response":{"numFound":1,"start":0,"docs":[
  {
"id":"1",
"title":["Solr adds block join support"],
"content_type":["parentDocument"],
"_version_":1595047178033692672}]
  }}
$ curl 
'http://localhost:8983/solr/techproducts/query?q=id:1=id,%5Bchild+parentFilter="content_type:parentDocument"%5D'
{
  "responseHeader":{
"status":0,
"QTime":0,
"params":{
  "q":"id:1",
  "fl":"id,[child parentFilter=\"content_type:parentDocument\"]"}},
  "response":{"numFound":1,"start":0,"docs":[
  {
"id":"1",
"_childDocuments_":[
{
  "id":"2",
  "comments":"SolrCloud supports it too!",
  "_version_":1595047178033692672}]}]
  }}
$ curl 
'http://localhost:8983/solr/techproducts/query?q=id:1=%5Bchild+parentFilter="content_type:parentDocument"%5D'
{
  "error":{
"trace":"java.lang.NullPointerException\n\tat 
org.apache.solr.response.transform.ChildDocTransformer.transform(ChildDocTransformerFactory.java:133)\n\tat
 org.apache.solr.response.DocsStreamer.next(DocsStreamer.java:120)\n\tat 
org.apache.solr.response.DocsStreamer.next(DocsStreamer.java:57)\n\tat 
org.apache.solr.response.TextResponseWriter.writeDocuments(TextResponseWriter.java:275)\n\tat
 
org.apache.solr.response.TextResponseWriter.writeVal(TextResponseWriter.java:161)\n\tat
 
org.apache.solr.response.JSONWriter.writeNamedListAsMapWithDups(JSONResponseWriter.java:209)\n\tat
 
org.apache.solr.response.JSONWriter.writeNamedList(JSONResponseWriter.java:325)\n\tat
 
org.apache.solr.response.JSONWriter.writeResponse(JSONResponseWriter.java:120)\n\tat
 
org.apache.solr.response.JSONResponseWriter.write(JSONResponseWriter.java:71)\n\tat
 
org.apache.solr.response.QueryResponseWriterUtil.writeQueryResponse(QueryResponseWriterUtil.java:65)\n\tat
 
org.apache.solr.servlet.HttpSolrCall.writeResponse(HttpSolrCall.java:789)\n\tat 
org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:526)\n\tat 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:384)\n\tat
 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:330)\n\tat
 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1629)\n\tat
 
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:533)\n\tat
 
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)\n\tat
 
org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)\n\tat
 
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)\n\tat
 
org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:190)\n\tat
 
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1595)\n\tat
 
org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:188)\n\tat
 
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1253)\n\tat
 
org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:168)\n\tat
 
org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:473)\n\tat 

[jira] [Commented] (SOLR-11891) BinaryResponseWriter fetches unnecessary fields

[Hoss Man (JIRA)]

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

Hoss Man commented on SOLR-11891:
-

bq. We should be able to accomplish the same speed up "safely" by ensuring that 
when we do loop over the IndexableField instances, we check 
ReturnField.wantsField(fname)

It turns out this is actually more nuanced...

# {{wantsField(String)}} only returns true when the *client* wants the field -- 
not any time the field is needed for other purposes (like transformers).  The 
correct logic is to do a hash lookup on the Set from 
{{ReturnFields.getLuceneFieldNames()}}
# Once i made these changes and started doing more testing, i uncovered 2 
independent bugs in some DocTransformers that are currently dependent on the 
existing sloppy code in {{convertLuceneDocToSolrDoc}} *AND* the 
{{documentCache}} being enabled in order to function properly...
#* {{ChildDocTransformerFactory}} assumes the uniqueKey field is always going 
to be available in converted {{SolrDocument}} w/o explicitly asking for them in 
a {{getExtraRequestFields()}} impl
#* {{RawValueTransformerFactory}} assumes it doesn't need to do anything if the 
{{wt}} doesn't match it's configured type, and that those fields will 
implicitly be in the {{SolrDocument}} and get returned to the user 
automatically (as regular String values)

I'm attaching a patch that fixes all of these, and creating new linked issue to 
track the sub-bugs.

I'll do some more hammering on tests and aim to commit soon unless people have 
concerns.


> BinaryResponseWriter fetches unnecessary fields
> ---
>
> Key: SOLR-11891
> URL: https://issues.apache.org/jira/browse/SOLR-11891
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Response Writers
>Affects Versions: 5.4, 6.4.2, 6.6.2
>Reporter: wei wang
>Priority: Major
> Attachments: DocsStreamer.java.diff, SOLR-11891.patch.BAD
>
>
> We observe that solr query time increases significantly with the number of 
> rows requested,  even all we retrieve for each document is just fl=id,score.  
> Debugged a bit and see that most of the increased time was spent in 
> BinaryResponseWriter,  converting lucene document into SolrDocument.  Inside 
> convertLuceneDocToSolrDoc():   
> [https://github.com/apache/lucene-solr/blob/df874432b9a17b547acb24a01d3491839e6a6b69/solr/core/src/java/org/apache/solr/response/DocsStreamer.java#L182]
>  
> I am a bit puzzled why we need to iterate through all the fields in the 
> document. Why can’t we just iterate through the requested field list?    
> [https://github.com/apache/lucene-solr/blob/df874432b9a17b547acb24a01d3491839e6a6b69/solr/core/src/java/org/apache/solr/response/DocsStreamer.java#L156]
>  
> e.g. when pass in the field list as 
> sdoc = convertLuceneDocToSolrDoc(doc, rctx.getSearcher().getSchema(), fnames)
> and just iterate through fnames,  there is a significant performance boost in 
> our case.  



--
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-12101) Tests: Timeout for zk shortened by config of server

[Gus Heck (JIRA)]

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

Gus Heck commented on SOLR-12101:
-

Pull Request added

> Tests: Timeout for zk shortened by config of server
> ---
>
> Key: SOLR-12101
> URL: https://issues.apache.org/jira/browse/SOLR-12101
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Gus Heck
>Assignee: Mark Miller
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> After some digging I found this code in ZkTestServer:
> {code:java}
> public void run() throws InterruptedException {
>   log.info("STARTING ZK TEST SERVER");
>   // we don't call super.distribSetUp
>   zooThread = new Thread() {
> 
> @Override
> public void run() {
>   ServerConfig config = new ServerConfig() {
> {
>   setClientPort(ZkTestServer.this.clientPort);
>   this.dataDir = zkDir;
>   this.dataLogDir = zkDir;
>   this.tickTime = theTickTime;
> }
> 
> public void setClientPort(int clientPort) {
>   if (clientPortAddress != null) {
> try {
>   this.clientPortAddress = new InetSocketAddress(
>   InetAddress.getByName(clientPortAddress.getHostName()), 
> clientPort);
> } catch (UnknownHostException e) {
>   throw new RuntimeException(e);
> }
>   } else {
> this.clientPortAddress = new InetSocketAddress(clientPort);
>   }
>   log.info("client port:" + this.clientPortAddress);
> }
>   };
>   try {
> zkServer.runFromConfig(config);
>   } catch (Throwable e) {
> throw new RuntimeException(e);
>   }
> }
>   };
> {code}
> And what I noticed is that min/max timeouts are unset and theTickTime is 
> onlly ever set to a big blue 1000 leading to default min/max timeout values 
> of 2/20 seconds 
> ([https://discuss.pivotal.io/hc/en-us/articles/205187157-Pivotal-HD-About-how-to-correctly-config-zookeeper-session-timeout-parameter-minSessionTimeout-and-maxSessionTimeout]
>  --> jibes with the zk code I see in my editor).
>  
> I suggest we provide explicit min/max configs in the anonymous inner class 
> here setting them back to the 3/60 defaults. 



--
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 #337: SOLR-12101 set explicit min/max timeouts

[nsoft]

GitHub user nsoft opened a pull request:

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

SOLR-12101 set explicit min/max timeouts



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

$ git pull https://github.com/nsoft/lucene-solr SOLR-12101

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

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


commit 91af049005e65d518c888392370bcf88b590e097
Author: Gus Heck 
Date:   2018-03-15T23:10:06Z

set explicit min/max timeouts

commit a6ea66508b637e72552f426879bf03004a1d4e99
Author: Gus Heck 
Date:   2018-03-15T23:14:40Z

SOLR-12101 setters too




---

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

[JENKINS] Lucene-Solr-7.x-Linux (64bit/jdk-9.0.4) - Build # 1539 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/1539/
Java: 64bit/jdk-9.0.4 -XX:-UseCompressedOops -XX:+UseSerialGC

1 tests failed.
FAILED:  org.apache.solr.cloud.autoscaling.ScheduledTriggerTest.testTrigger

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

Stack Trace:
java.lang.AssertionError: expected:<3> but was:<2>
at 
__randomizedtesting.SeedInfo.seed([4BF3CC438AFF4F2:67740A46A16087DF]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.failNotEquals(Assert.java:647)
at org.junit.Assert.assertEquals(Assert.java:128)
at org.junit.Assert.assertEquals(Assert.java:472)
at org.junit.Assert.assertEquals(Assert.java:456)
at 
org.apache.solr.cloud.autoscaling.ScheduledTriggerTest.scheduledTriggerTest(ScheduledTriggerTest.java:112)
at 
org.apache.solr.cloud.autoscaling.ScheduledTriggerTest.testTrigger(ScheduledTriggerTest.java:65)
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)




Build Log:
[...truncated 

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

[Apache Jenkins Server]

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

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

[repro] Revision: ac9559d70de5e2454e0515a08774890ad4012eef

[repro] Repro line:  ant test  -Dtestcase=ScheduledMaintenanceTriggerTest 
-Dtests.method=testInactiveShardCleanup -Dtests.seed=DC324D755B1A977E 
-Dtests.multiplier=2 -Dtests.slow=true -Dtests.locale=th-TH 
-Dtests.timezone=Asia/Srednekolymsk -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: 
ac9559d70de5e2454e0515a08774890ad4012eef
[repro] git fetch
[repro] git checkout ac9559d70de5e2454e0515a08774890ad4012eef

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

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

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

[...truncated 3292 lines...]
[repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=5 
-Dtests.class="*.ScheduledMaintenanceTriggerTest" -Dtests.showOutput=onerror  
-Dtests.seed=DC324D755B1A977E -Dtests.multiplier=2 -Dtests.slow=true 
-Dtests.locale=th-TH -Dtests.timezone=Asia/Srednekolymsk -Dtests.asserts=true 
-Dtests.file.encoding=US-ASCII

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

[repro] Failures:
[repro]   5/5 failed: 
org.apache.solr.cloud.autoscaling.ScheduledMaintenanceTriggerTest

[repro] Re-testing 100% failures at the tip of master
[repro] ant clean

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

[...truncated 3292 lines...]
[repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=5 
-Dtests.class="*.ScheduledMaintenanceTriggerTest" -Dtests.showOutput=onerror  
-Dtests.seed=DC324D755B1A977E -Dtests.multiplier=2 -Dtests.slow=true 
-Dtests.locale=th-TH -Dtests.timezone=Asia/Srednekolymsk -Dtests.asserts=true 
-Dtests.file.encoding=US-ASCII

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

[repro] Failures at the tip of master:
[repro]   5/5 failed: 
org.apache.solr.cloud.autoscaling.ScheduledMaintenanceTriggerTest

[repro] Re-testing 100% failures at the tip of master without a seed
[repro] ant clean

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

[...truncated 3292 lines...]
[repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=5 
-Dtests.class="*.ScheduledMaintenanceTriggerTest" -Dtests.showOutput=onerror  
-Dtests.multiplier=2 -Dtests.slow=true -Dtests.locale=th-TH 
-Dtests.timezone=Asia/Srednekolymsk -Dtests.asserts=true 
-Dtests.file.encoding=US-ASCII

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

[repro] Failures at the tip of master without a seed:
[repro]   5/5 failed: 
org.apache.solr.cloud.autoscaling.ScheduledMaintenanceTriggerTest
[repro] git checkout ac9559d70de5e2454e0515a08774890ad4012eef

[...truncated 1 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

[jira] [Commented] (SOLR-12106) Validate patch validation (solr edition)

[Lucene/Solr QA (JIRA)]

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

Lucene/Solr QA commented on SOLR-12106:
---

| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green}  0m 
 0s{color} | {color:green} The patch appears to include 1 new or modified test 
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:red}-1{color} | {color:red} compile {color} | {color:red}  1m 
32s{color} | {color:red} solr-ref-guide in master failed. {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:red}-1{color} | {color:red} compile {color} | {color:red}  2m 
47s{color} | {color:red} solr-ref-guide in the patch failed. {color} |
| {color:red}-1{color} | {color:red} javac {color} | {color:red}  2m 47s{color} 
| {color:red} solr-ref-guide in the patch failed. {color} |
| {color:red}-1{color} | {color:red} Release audit (RAT) {color} | {color:red}  
2m 47s{color} | {color:red} solr-ref-guide in the patch failed. {color} |
| {color:green}+1{color} | {color:green} Release audit (RAT) {color} | 
{color:green}  0m 35s{color} | {color:green} Release audit (RAT) rat-sources 
passed {color} |
| {color:red}-1{color} | {color:red} Check forbidden APIs {color} | {color:red} 
 2m 47s{color} | {color:red} solr-ref-guide in the patch failed. {color} |
| {color:red}-1{color} | {color:red} Validate source patterns {color} | 
{color:red}  2m 47s{color} | {color:red} solr-ref-guide in the patch failed. 
{color} |
| {color:red}-1{color} | {color:red} Validate ref guide {color} | {color:red}  
2m 47s{color} | {color:red} solr-ref-guide in the patch failed. {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:red}-1{color} | {color:red} unit {color} | {color:red}  0m 26s{color} 
| {color:red} solr-ref-guide in the patch failed. {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red}  1m  5s{color} 
| {color:red} test-framework in the patch failed. {color} |
| {color:black}{color} | {color:black} {color} | {color:black}  6m 58s{color} | 
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | SOLR-12106 |
| JIRA Patch URL | 
https://issues.apache.org/jira/secure/attachment/12914788/SOLR-12106.patch |
| Optional Tests |  ratsources  validatesourcepatterns  validaterefguide  
compile  javac  unit  checkforbiddenapis  |
| uname | Linux lucene2-us-west.apache.org 4.4.0-112-generic #135-Ubuntu SMP 
Fri Jan 19 11:48:36 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | ant |
| Personality | 
/home/jenkins/jenkins-slave/workspace/PreCommit-SOLR-Build/sourcedir/dev-tools/test-patch/lucene-solr-yetus-personality.sh
 |
| git revision | master / ac9559d |
| ant | version: Apache Ant(TM) version 1.9.6 compiled on July 8 2015 |
| Default Java | 1.8.0_152 |
| compile | 
https://builds.apache.org/job/PreCommit-SOLR-Build/1/artifact/out/branch-compile-solr_solr-ref-guide.txt
 |
| compile | 
https://builds.apache.org/job/PreCommit-SOLR-Build/1/artifact/out/patch-compile-solr_solr-ref-guide.txt
 |
| javac | 
https://builds.apache.org/job/PreCommit-SOLR-Build/1/artifact/out/patch-compile-solr_solr-ref-guide.txt
 |
| Release audit (RAT) | 
https://builds.apache.org/job/PreCommit-SOLR-Build/1/artifact/out/patch-compile-solr_solr-ref-guide.txt
 |
| Check forbidden APIs | 
https://builds.apache.org/job/PreCommit-SOLR-Build/1/artifact/out/patch-compile-solr_solr-ref-guide.txt
 |
| Validate source patterns | 
https://builds.apache.org/job/PreCommit-SOLR-Build/1/artifact/out/patch-compile-solr_solr-ref-guide.txt
 |
| Validate ref guide | 
https://builds.apache.org/job/PreCommit-SOLR-Build/1/artifact/out/patch-compile-solr_solr-ref-guide.txt
 |
| unit | 
https://builds.apache.org/job/PreCommit-SOLR-Build/1/artifact/out/patch-unit-solr_solr-ref-guide.txt
 |
| unit | 
https://builds.apache.org/job/PreCommit-SOLR-Build/1/artifact/out/patch-unit-solr_test-framework.txt
 |
|  Test Results | 
https://builds.apache.org/job/PreCommit-SOLR-Build/1/testReport/ |
| modules | C: solr/solr-ref-guide solr/test-framework U: solr |
| Console output | https://builds.apache.org/job/PreCommit-SOLR-Build/1/console 
|
| Powered by | Apache Yetus 0.7.0   http://yetus.apache.org |


This message was automatically generated.



> Validate patch validation (solr edition)
> 
>
> Key: SOLR-12106
> URL: https://issues.apache.org/jira/browse/SOLR-12106
> Project: Solr
>  Issue Type: Test
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Tests
>Reporter: Steve Rowe
>Assignee: Steve Rowe
>Priority: Trivial
> Attachments: SOLR-12106.patch

[jira] [Updated] (SOLR-12106) Validate patch validation (solr edition)

[Steve Rowe (JIRA)]

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

Steve Rowe updated SOLR-12106:
--
Attachment: SOLR-12106.patch

> Validate patch validation (solr edition)
> 
>
> Key: SOLR-12106
> URL: https://issues.apache.org/jira/browse/SOLR-12106
> Project: Solr
>  Issue Type: Test
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Tests
>Reporter: Steve Rowe
>Assignee: Steve Rowe
>Priority: Trivial
> Attachments: SOLR-12106.patch
>
>
> Issue to host patches for testing automatic patch validation.



--
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-12106) Validate patch validation (solr edition)

[Steve Rowe (JIRA)]

Steve Rowe created SOLR-12106:
-

 Summary: Validate patch validation (solr edition)
 Key: SOLR-12106
 URL: https://issues.apache.org/jira/browse/SOLR-12106
 Project: Solr
  Issue Type: Test
  Security Level: Public (Default Security Level. Issues are Public)
  Components: Tests
Reporter: Steve Rowe
Assignee: Steve Rowe
 Attachments: SOLR-12106.patch

Issue to host patches for testing automatic patch validation.




--
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-12094) JsonRecordReader ignores root fields after split

[Dawid Weiss (JIRA)]

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

Dawid Weiss commented on SOLR-12094:


Thanks for the patch! I'll be away for a week and I am not familiar with this 
code at all, but if nobody picks it up I'll try to dig in, review it and commit 
it. If you could run the test suite a few times (and precommit) to ensure the 
patch passes, it'd be great.

There are similar issues with DIH that I reported a while ago, but never got to 
fixing too. Sigh.

> JsonRecordReader ignores root fields after split
> 
>
> Key: SOLR-12094
> URL: https://issues.apache.org/jira/browse/SOLR-12094
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrJ
>Affects Versions: master (8.0)
>Reporter: Przemysław Szeremiota
>Priority: Major
> Attachments: SOLR-12094.patch, json-record-reader-bug.patch
>
>
> JsonRecordReader, when configured with other than top-level split, ignores 
> all top-level JSON nodes after split ends, for example:
> {code}
> {
>   "first": "John",
>   "last": "Doe",
>   "grade": 8,
>   "exams": [
> {
> "subject": "Maths",
> "test": "term1",
> "marks": 90
> },
> {
> "subject": "Biology",
> "test": "term1",
> "marks": 86
> }
>   ],
>   "after": "456"
> }
> {code}
> Node "after" won't be visible in SolrInputDocument constructed from 
> /update/json/docs.
> I don't have fix, only (breaking) patch for relevant test



--
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-8210) Validate patch validation

[Lucene/Solr QA (JIRA)]

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

Lucene/Solr QA commented on LUCENE-8210:


| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green}  0m 
 0s{color} | {color:green} The patch appears to include 2 new or modified test 
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  0m 
32s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  0m 
31s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green}  0m 
31s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Release audit (RAT) {color} | 
{color:green}  0m 27s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Check forbidden APIs {color} | 
{color:green}  0m 23s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Validate source patterns {color} | 
{color:green}  0m 23s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:red}-1{color} | {color:red} unit {color} | {color:red}  3m 46s{color} 
| {color:red} common in the patch failed. {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red}  0m 29s{color} 
| {color:red} icu in the patch failed. {color} |
| {color:black}{color} | {color:black} {color} | {color:black}  7m  8s{color} | 
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | lucene.analysis.charfilter.HTMLStripCharFilterTest |
|   | lucene.analysis.icu.TestICUFoldingFilter |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | LUCENE-8210 |
| JIRA Patch URL | 
https://issues.apache.org/jira/secure/attachment/12914751/LUCENE-8210.patch |
| Optional Tests |  compile  javac  unit  ratsources  checkforbiddenapis  
validatesourcepatterns  |
| uname | Linux lucene1-us-west 3.13.0-88-generic #135-Ubuntu SMP Wed Jun 8 
21:10:42 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | ant |
| Personality | 
/home/jenkins/jenkins-slave/workspace/PreCommit-LUCENE-Build/sourcedir/dev-tools/test-patch/lucene-solr-yetus-personality.sh
 |
| git revision | master / ac9559d |
| ant | version: Apache Ant(TM) version 1.9.3 compiled on April 8 2014 |
| Default Java | 1.8.0_144 |
| unit | 
https://builds.apache.org/job/PreCommit-LUCENE-Build/9/artifact/out/patch-unit-lucene_analysis_common.txt
 |
| unit | 
https://builds.apache.org/job/PreCommit-LUCENE-Build/9/artifact/out/patch-unit-lucene_analysis_icu.txt
 |
|  Test Results | 
https://builds.apache.org/job/PreCommit-LUCENE-Build/9/testReport/ |
| modules | C: lucene/analysis/common lucene/analysis/icu U: lucene/analysis |
| Console output | 
https://builds.apache.org/job/PreCommit-LUCENE-Build/9/console |
| Powered by | Apache Yetus 0.7.0   http://yetus.apache.org |


This message was automatically generated.



> Validate patch validation 
> --
>
> Key: LUCENE-8210
> URL: https://issues.apache.org/jira/browse/LUCENE-8210
> Project: Lucene - Core
>  Issue Type: Test
>  Components: general/test
>Reporter: Steve Rowe
>Assignee: Steve Rowe
>Priority: Major
> Attachments: LUCENE-8210.patch
>
>
> Issue to host patches for testing automatic patch validation.



--
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-12094) JsonRecordReader ignores root fields after split

[Andrzej Wislowski (JIRA)]

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

Andrzej Wislowski commented on SOLR-12094:
--

Hi, I have added a patch file  [^SOLR-12094.patch] in which I buffer extracting 
records to fill in missing fields from the json top level.

> JsonRecordReader ignores root fields after split
> 
>
> Key: SOLR-12094
> URL: https://issues.apache.org/jira/browse/SOLR-12094
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrJ
>Affects Versions: master (8.0)
>Reporter: Przemysław Szeremiota
>Priority: Major
> Attachments: SOLR-12094.patch, json-record-reader-bug.patch
>
>
> JsonRecordReader, when configured with other than top-level split, ignores 
> all top-level JSON nodes after split ends, for example:
> {code}
> {
>   "first": "John",
>   "last": "Doe",
>   "grade": 8,
>   "exams": [
> {
> "subject": "Maths",
> "test": "term1",
> "marks": 90
> },
> {
> "subject": "Biology",
> "test": "term1",
> "marks": 86
> }
>   ],
>   "after": "456"
> }
> {code}
> Node "after" won't be visible in SolrInputDocument constructed from 
> /update/json/docs.
> I don't have fix, only (breaking) patch for relevant test



--
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-12094) JsonRecordReader ignores root fields after split

[Andrzej Wislowski (JIRA)]

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

Andrzej Wislowski updated SOLR-12094:
-
Attachment: SOLR-12094.patch

> JsonRecordReader ignores root fields after split
> 
>
> Key: SOLR-12094
> URL: https://issues.apache.org/jira/browse/SOLR-12094
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrJ
>Affects Versions: master (8.0)
>Reporter: Przemysław Szeremiota
>Priority: Major
> Attachments: SOLR-12094.patch, json-record-reader-bug.patch
>
>
> JsonRecordReader, when configured with other than top-level split, ignores 
> all top-level JSON nodes after split ends, for example:
> {code}
> {
>   "first": "John",
>   "last": "Doe",
>   "grade": 8,
>   "exams": [
> {
> "subject": "Maths",
> "test": "term1",
> "marks": 90
> },
> {
> "subject": "Biology",
> "test": "term1",
> "marks": 86
> }
>   ],
>   "after": "456"
> }
> {code}
> Node "after" won't be visible in SolrInputDocument constructed from 
> /update/json/docs.
> I don't have fix, only (breaking) patch for relevant test



--
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-12105) Support Inplace updates in cdcr

[Amrit Sarkar (JIRA)]

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

Amrit Sarkar updated SOLR-12105:

Summary: Support Inplace updates in cdcr  (was: Support Inplace updates in 
CDCR)

> Support Inplace updates in cdcr
> ---
>
> Key: SOLR-12105
> URL: https://issues.apache.org/jira/browse/SOLR-12105
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: CDCR
>Reporter: Amrit Sarkar
>Priority: Minor
>
> Inplace updates are not forwarded to target clusters as of today. Add the 
> support.



--
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-12105) Support Inplace updates in CDCR

[Amrit Sarkar (JIRA)]

Amrit Sarkar created SOLR-12105:
---

 Summary: Support Inplace updates in CDCR
 Key: SOLR-12105
 URL: https://issues.apache.org/jira/browse/SOLR-12105
 Project: Solr
  Issue Type: Improvement
  Security Level: Public (Default Security Level. Issues are Public)
  Components: CDCR
Reporter: Amrit Sarkar


Inplace updates are not forwarded to target clusters as of today. Introduce the 
support.



--
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-12105) Support Inplace updates in CDCR

[Amrit Sarkar (JIRA)]

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

Amrit Sarkar updated SOLR-12105:

Description: Inplace updates are not forwarded to target clusters as of 
today. Add the support.  (was: Inplace updates are not forwarded to target 
clusters as of today. Introduce the support.)

> Support Inplace updates in CDCR
> ---
>
> Key: SOLR-12105
> URL: https://issues.apache.org/jira/browse/SOLR-12105
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: CDCR
>Reporter: Amrit Sarkar
>Priority: Minor
>
> Inplace updates are not forwarded to target clusters as of today. Add the 
> support.



--
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-12104) Improve test framework within Solr to randomize cdcr usage

[Amrit Sarkar (JIRA)]

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

Amrit Sarkar updated SOLR-12104:

Priority: Minor  (was: Major)

> Improve test framework within Solr to randomize cdcr usage
> --
>
> Key: SOLR-12104
> URL: https://issues.apache.org/jira/browse/SOLR-12104
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: CDCR
>Reporter: Amrit Sarkar
>Priority: Minor
>  Labels: test
>
> We identified multiple issues in {{cdcr}} recently as Cdcr tests are written 
> separately / separate module than the other components and changing behavior 
> in one component affects Cdcr usage.
> Here we try to introduce randomization of {{CdcrUpdateLog}} and {{UpdateLog}} 
> in underlying testframework to identify and fix components respectively.



--
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-12104) Improve test framework within Solr to randomize cdcr usage

[Amrit Sarkar (JIRA)]

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

Amrit Sarkar updated SOLR-12104:

Labels: test  (was: )

> Improve test framework within Solr to randomize cdcr usage
> --
>
> Key: SOLR-12104
> URL: https://issues.apache.org/jira/browse/SOLR-12104
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: CDCR
>Reporter: Amrit Sarkar
>Priority: Major
>  Labels: test
>
> We identified multiple issues in {{cdcr}} recently as Cdcr tests are written 
> separately / separate module than the other components and changing behavior 
> in one component affects Cdcr usage.
> Here we try to introduce randomization of {{CdcrUpdateLog}} and {{UpdateLog}} 
> in underlying testframework to identify and fix components respectively.



--
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-12104) Improve test framework within Solr to randomize cdcr usage

[Amrit Sarkar (JIRA)]

Amrit Sarkar created SOLR-12104:
---

 Summary: Improve test framework within Solr to randomize cdcr usage
 Key: SOLR-12104
 URL: https://issues.apache.org/jira/browse/SOLR-12104
 Project: Solr
  Issue Type: Improvement
  Security Level: Public (Default Security Level. Issues are Public)
  Components: CDCR
Reporter: Amrit Sarkar


We identified multiple issues in {{cdcr}} recently as Cdcr tests are written 
separately / separate module than the other components and changing behavior in 
one component affects Cdcr usage.

Here we try to introduce randomization of {{CdcrUpdateLog}} and {{UpdateLog}} 
in underlying testframework to identify and fix components respectively.



--
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-9935) When hl.method=unified add support for hl.fragsize param

[David Smiley (JIRA)]

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

David Smiley commented on SOLR-9935:


Yes it's resolved. What not obvious is that the semantics are not identical 
between the UH and the original Highlighter (and I forget what the FVH does 
here). The OH breaks at the word break following hl.fragsize chars, whereas the 
UH does so at the sentence (not word) break. Technically the UH's choice is 
configurable via {{hl.bs.type}} but as a practical matter it probably doesn't 
make sense to use {{WORD}} or {{CHAR}}, since then the highlights would never 
contain any words to the left of the highlighted word (based on how the UH uses 
the underlying BreakIterator).

Fragmenting is a rather difficult problem, I've found.  It's hard to satisfy 
everyone's desires.

> When hl.method=unified add support for hl.fragsize param
> 
>
> Key: SOLR-9935
> URL: https://issues.apache.org/jira/browse/SOLR-9935
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: highlighter
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Major
> Fix For: 6.4
>
> Attachments: SOLR_9935_UH_fragsize.patch, SOLR_9935_UH_fragsize.patch
>
>
> In LUCENE-7620 the UnifiedHighlighter is getting a BreakIterator that allows 
> it to support the equivalent of Solr's {{hl.fragsize}}.  So lets support this 
> on the Solr side.



--
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 # 21646 - Unstable!

[Policeman Jenkins Server]

Error processing tokens: Error while parsing action 
'Text/ZeroOrMore/FirstOf/Token/DelimitedToken/DelimitedToken_Action3' at input 
position (line 79, pos 4):
)"}
   ^

java.lang.OutOfMemoryError: Java heap space

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

[jira] [Resolved] (SOLR-11960) Add collection level properties

[JIRA]

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

Tomás Fernández Löbbe resolved SOLR-11960.
--
   Resolution: Fixed
Fix Version/s: master (8.0)

Resolving. Sorry for the delay Alan!

> Add collection level properties
> ---
>
> Key: SOLR-11960
> URL: https://issues.apache.org/jira/browse/SOLR-11960
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Peter Rusko
>Assignee: Tomás Fernández Löbbe
>Priority: Blocker
> Fix For: 7.3, master (8.0)
>
> Attachments: SOLR-11960.patch, SOLR-11960.patch, SOLR-11960.patch, 
> SOLR-11960.patch, SOLR-11960.patch, SOLR-11960_2.patch
>
>
> Solr has cluster properties, but no easy and extendable way of defining 
> properties that affect a single collection. Collection properties could be 
> stored in a single zookeeper node per collection, making it possible to 
> trigger zookeeper watchers for only those Solr nodes that have cores of that 
> collection.



--
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-8210) Validate patch validation

[Lucene/Solr QA (JIRA)]

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

Lucene/Solr QA commented on LUCENE-8210:


| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green}  0m 
 0s{color} | {color:green} The patch appears to include 2 new or modified test 
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  0m 
22s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  0m 
20s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green}  0m 
20s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Release audit (RAT) {color} | 
{color:green}  0m 17s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Check forbidden APIs {color} | 
{color:green}  0m 14s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Validate source patterns {color} | 
{color:green}  0m 14s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:red}-1{color} | {color:red} unit {color} | {color:red}  2m  7s{color} 
| {color:red} common in the patch failed. {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red}  0m 20s{color} 
| {color:red} icu in the patch failed. {color} |
| {color:black}{color} | {color:black} {color} | {color:black}  4m 30s{color} | 
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | lucene.analysis.charfilter.HTMLStripCharFilterTest |
|   | lucene.analysis.icu.TestICUFoldingFilter |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | LUCENE-8210 |
| JIRA Patch URL | 
https://issues.apache.org/jira/secure/attachment/12914751/LUCENE-8210.patch |
| Optional Tests |  compile  javac  unit  ratsources  checkforbiddenapis  
validatesourcepatterns  |
| uname | Linux lucene2-us-west.apache.org 4.4.0-112-generic #135-Ubuntu SMP 
Fri Jan 19 11:48:36 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | ant |
| Personality | 
/home/jenkins/jenkins-slave/workspace/PreCommit-LUCENE-Build/sourcedir/dev-tools/test-patch/lucene-solr-yetus-personality.sh
 |
| git revision | master / ac9559d |
| ant | version: Apache Ant(TM) version 1.9.6 compiled on July 8 2015 |
| Default Java | 1.8.0_152 |
| unit | 
https://builds.apache.org/job/PreCommit-LUCENE-Build/8/artifact/out/patch-unit-lucene_analysis_common.txt
 |
| unit | 
https://builds.apache.org/job/PreCommit-LUCENE-Build/8/artifact/out/patch-unit-lucene_analysis_icu.txt
 |
|  Test Results | 
https://builds.apache.org/job/PreCommit-LUCENE-Build/8/testReport/ |
| modules | C: lucene/analysis/common lucene/analysis/icu U: lucene/analysis |
| Console output | 
https://builds.apache.org/job/PreCommit-LUCENE-Build/8/console |
| Powered by | Apache Yetus 0.7.0   http://yetus.apache.org |


This message was automatically generated.



> Validate patch validation 
> --
>
> Key: LUCENE-8210
> URL: https://issues.apache.org/jira/browse/LUCENE-8210
> Project: Lucene - Core
>  Issue Type: Test
>  Components: general/test
>Reporter: Steve Rowe
>Assignee: Steve Rowe
>Priority: Major
> Attachments: LUCENE-8210.patch
>
>
> Issue to host patches for testing automatic patch validation.



--
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-10912) Adding automatic patch validation

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10912:


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

SOLR-10912: reverting personality plugins changes to include junit+unit and 
javac+compile, since this combo works, and neither one individually does.


> Adding automatic patch validation
> -
>
> Key: SOLR-10912
> URL: https://issues.apache.org/jira/browse/SOLR-10912
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Build
>Reporter: Mano Kovacs
>Assignee: Steve Rowe
>Priority: Major
> Attachments: SOLR-10912.ok-patch-in-core.patch, SOLR-10912.patch, 
> SOLR-10912.patch, SOLR-10912.sample-patch.patch, 
> SOLR-10912.solj-contrib-facet-error.patch
>
>
> Proposing introduction of automated patch validation, similar what Hadoop or 
> other Apache projects are using (see link). This would ensure that every 
> patch passes a certain set of criterions before getting approved. It would 
> save time for developer (faster feedback loop), save time for committers 
> (less step to do manually), and would increase quality.
> Hadoop is currently using Apache Yetus to run validations, which seems to be 
> a good direction to start. This jira could be the board of discussing the 
> preferred solution.



--
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-10912) Adding automatic patch validation

[Allen Wittenauer (JIRA)]

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

Allen Wittenauer commented on SOLR-10912:
-

compile does a basic compile test.  javac looks in the output log for specific 
java warnings/errors generated from the compile phase when java's lint mode is 
activated.

> Adding automatic patch validation
> -
>
> Key: SOLR-10912
> URL: https://issues.apache.org/jira/browse/SOLR-10912
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Build
>Reporter: Mano Kovacs
>Assignee: Steve Rowe
>Priority: Major
> Attachments: SOLR-10912.ok-patch-in-core.patch, SOLR-10912.patch, 
> SOLR-10912.patch, SOLR-10912.sample-patch.patch, 
> SOLR-10912.solj-contrib-facet-error.patch
>
>
> Proposing introduction of automated patch validation, similar what Hadoop or 
> other Apache projects are using (see link). This would ensure that every 
> patch passes a certain set of criterions before getting approved. It would 
> save time for developer (faster feedback loop), save time for committers 
> (less step to do manually), and would increase quality.
> Hadoop is currently using Apache Yetus to run validations, which seems to be 
> a good direction to start. This jira could be the board of discussing the 
> preferred solution.



--
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-8210) Validate patch validation

[Lucene/Solr QA (JIRA)]

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

Lucene/Solr QA commented on LUCENE-8210:


| (/) *{color:green}+1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
|| || || || {color:brown} Prechecks {color} ||
|| || || || {color:brown} master Compile Tests {color} ||
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} Release audit (RAT) {color} | 
{color:green}  0m  5s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Check forbidden APIs {color} | 
{color:green}  0m  2s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Validate source patterns {color} | 
{color:green}  0m  2s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:black}{color} | {color:black} {color} | {color:black}  1m 26s{color} | 
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | LUCENE-8210 |
| JIRA Patch URL | 
https://issues.apache.org/jira/secure/attachment/12914751/LUCENE-8210.patch |
| Optional Tests |  javac  ratsources  checkforbiddenapis  
validatesourcepatterns  |
| uname | Linux lucene2-us-west.apache.org 4.4.0-112-generic #135-Ubuntu SMP 
Fri Jan 19 11:48:36 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | ant |
| Personality | 
/home/jenkins/jenkins-slave/workspace/PreCommit-LUCENE-Build/sourcedir/dev-tools/test-patch/lucene-solr-yetus-personality.sh
 |
| git revision | master / bd20e36 |
| ant | version: Apache Ant(TM) version 1.9.6 compiled on July 8 2015 |
| Default Java | 1.8.0_152 |
| modules | C: lucene/analysis/common lucene/analysis/icu U: lucene/analysis |
| Console output | 
https://builds.apache.org/job/PreCommit-LUCENE-Build/7/console |
| Powered by | Apache Yetus 0.7.0   http://yetus.apache.org |


This message was automatically generated.



> Validate patch validation 
> --
>
> Key: LUCENE-8210
> URL: https://issues.apache.org/jira/browse/LUCENE-8210
> Project: Lucene - Core
>  Issue Type: Test
>  Components: general/test
>Reporter: Steve Rowe
>Assignee: Steve Rowe
>Priority: Major
> Attachments: LUCENE-8210.patch
>
>
> Issue to host patches for testing automatic patch validation.



--
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-10912) Adding automatic patch validation

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10912:


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

SOLR-10912: attempted personality plugins fix: trying just junit/javac instead 
of unit/compile (which didn't actually do anything at all)


> Adding automatic patch validation
> -
>
> Key: SOLR-10912
> URL: https://issues.apache.org/jira/browse/SOLR-10912
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Build
>Reporter: Mano Kovacs
>Assignee: Steve Rowe
>Priority: Major
> Attachments: SOLR-10912.ok-patch-in-core.patch, SOLR-10912.patch, 
> SOLR-10912.patch, SOLR-10912.sample-patch.patch, 
> SOLR-10912.solj-contrib-facet-error.patch
>
>
> Proposing introduction of automated patch validation, similar what Hadoop or 
> other Apache projects are using (see link). This would ensure that every 
> patch passes a certain set of criterions before getting approved. It would 
> save time for developer (faster feedback loop), save time for committers 
> (less step to do manually), and would increase quality.
> Hadoop is currently using Apache Yetus to run validations, which seems to be 
> a good direction to start. This jira could be the board of discussing the 
> preferred solution.



--
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-Windows (32bit/jdk1.8.0_144) - Build # 506 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Windows/506/
Java: 32bit/jdk1.8.0_144 -client -XX:+UseG1GC

3 tests failed.
FAILED:  org.apache.solr.common.util.TestTimeSource.testEpochTime

Error Message:
SimTimeSource:50.0 time diff=34833650

Stack Trace:
java.lang.AssertionError: SimTimeSource:50.0 time diff=34833650
at 
__randomizedtesting.SeedInfo.seed([6DC30080CAEB5EE:3EB0432D987E17A8]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.common.util.TestTimeSource.doTestEpochTime(TestTimeSource.java:48)
at 
org.apache.solr.common.util.TestTimeSource.testEpochTime(TestTimeSource.java:32)
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.common.util.TestTimeSource.testEpochTime

Error Message:
SimTimeSource:50.0 time diff=19857600

Stack Trace:
java.lang.AssertionError: SimTimeSource:50.0 time diff=19857600
at 

[jira] [Commented] (LUCENE-8210) Validate patch validation

[Lucene/Solr QA (JIRA)]

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

Lucene/Solr QA commented on LUCENE-8210:


| (/) *{color:green}+1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green}  0m 
 0s{color} | {color:green} The patch appears to include 2 new or modified test 
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} Release audit (RAT) {color} | 
{color:green}  0m  5s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Check forbidden APIs {color} | 
{color:green}  0m  2s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Validate source patterns {color} | 
{color:green}  0m  2s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green}  0m  
2s{color} | {color:green} Validate source patterns validate-source-patterns 
passed {color} |
| {color:black}{color} | {color:black} {color} | {color:black}  1m 31s{color} | 
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | LUCENE-8210 |
| JIRA Patch URL | 
https://issues.apache.org/jira/secure/attachment/12914751/LUCENE-8210.patch |
| Optional Tests |  compile  unit  ratsources  checkforbiddenapis  
validatesourcepatterns  |
| uname | Linux lucene2-us-west.apache.org 4.4.0-112-generic #135-Ubuntu SMP 
Fri Jan 19 11:48:36 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | ant |
| Personality | 
/home/jenkins/jenkins-slave/workspace/PreCommit-LUCENE-Build/sourcedir/dev-tools/test-patch/lucene-solr-yetus-personality.sh
 |
| git revision | master / 63fde15 |
| ant | version: Apache Ant(TM) version 1.9.6 compiled on July 8 2015 |
|  Test Results | 
https://builds.apache.org/job/PreCommit-LUCENE-Build/6/testReport/ |
| modules | C: lucene/analysis/common lucene/analysis/icu U: lucene/analysis |
| Console output | 
https://builds.apache.org/job/PreCommit-LUCENE-Build/6/console |
| Powered by | Apache Yetus 0.7.0   http://yetus.apache.org |


This message was automatically generated.



> Validate patch validation 
> --
>
> Key: LUCENE-8210
> URL: https://issues.apache.org/jira/browse/LUCENE-8210
> Project: Lucene - Core
>  Issue Type: Test
>  Components: general/test
>Reporter: Steve Rowe
>Assignee: Steve Rowe
>Priority: Major
> Attachments: LUCENE-8210.patch
>
>
> Issue to host patches for testing automatic patch validation.



--
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-12094) JsonRecordReader ignores root fields after split

[JIRA]

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

Przemysław Szeremiota commented on SOLR-12094:
--

Thank you Dawid for fixing my poor issue formatting.

Yes, it is a bug: visibility of root fields in output depends on their order 
within input document, so functionally indifferent JSON with "exams" as a first 
field would have all root-level fields skipped from resulting document.

> JsonRecordReader ignores root fields after split
> 
>
> Key: SOLR-12094
> URL: https://issues.apache.org/jira/browse/SOLR-12094
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrJ
>Affects Versions: master (8.0)
>Reporter: Przemysław Szeremiota
>Priority: Major
> Attachments: json-record-reader-bug.patch
>
>
> JsonRecordReader, when configured with other than top-level split, ignores 
> all top-level JSON nodes after split ends, for example:
> {code}
> {
>   "first": "John",
>   "last": "Doe",
>   "grade": 8,
>   "exams": [
> {
> "subject": "Maths",
> "test": "term1",
> "marks": 90
> },
> {
> "subject": "Biology",
> "test": "term1",
> "marks": 86
> }
>   ],
>   "after": "456"
> }
> {code}
> Node "after" won't be visible in SolrInputDocument constructed from 
> /update/json/docs.
> I don't have fix, only (breaking) patch for relevant test



--
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-11960) Add collection level properties

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-11960:


Commit 3b8eb6cd3e53727812f82711b9aa96d6f511e184 in lucene-solr's branch 
refs/heads/branch_7_3 from [~tomasflobbe]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=3b8eb6c ]

SOLR-11960: Don't add property listeners on core registration


> Add collection level properties
> ---
>
> Key: SOLR-11960
> URL: https://issues.apache.org/jira/browse/SOLR-11960
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Peter Rusko
>Assignee: Tomás Fernández Löbbe
>Priority: Blocker
> Fix For: 7.3
>
> Attachments: SOLR-11960.patch, SOLR-11960.patch, SOLR-11960.patch, 
> SOLR-11960.patch, SOLR-11960.patch, SOLR-11960_2.patch
>
>
> Solr has cluster properties, but no easy and extendable way of defining 
> properties that affect a single collection. Collection properties could be 
> stored in a single zookeeper node per collection, making it possible to 
> trigger zookeeper watchers for only those Solr nodes that have cores of that 
> collection.



--
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-11960) Add collection level properties

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-11960:


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

SOLR-11960: Don't add property listeners on core registration


> Add collection level properties
> ---
>
> Key: SOLR-11960
> URL: https://issues.apache.org/jira/browse/SOLR-11960
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Peter Rusko
>Assignee: Tomás Fernández Löbbe
>Priority: Blocker
> Fix For: 7.3
>
> Attachments: SOLR-11960.patch, SOLR-11960.patch, SOLR-11960.patch, 
> SOLR-11960.patch, SOLR-11960.patch, SOLR-11960_2.patch
>
>
> Solr has cluster properties, but no easy and extendable way of defining 
> properties that affect a single collection. Collection properties could be 
> stored in a single zookeeper node per collection, making it possible to 
> trigger zookeeper watchers for only those Solr nodes that have cores of that 
> collection.



--
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-10912) Adding automatic patch validation

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10912:


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

SOLR-10912: updating copy of Jenkins precommit job script: proc max limit code 
seems not to work on jenkins slaves, so put it at a fixed 10k; added 
customization of artifact url so console output links in the JIRA comment 
report work properly; no longer attempting to cache the yetus download, since 
it always downloads every time anyway.


> Adding automatic patch validation
> -
>
> Key: SOLR-10912
> URL: https://issues.apache.org/jira/browse/SOLR-10912
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Build
>Reporter: Mano Kovacs
>Assignee: Steve Rowe
>Priority: Major
> Attachments: SOLR-10912.ok-patch-in-core.patch, SOLR-10912.patch, 
> SOLR-10912.patch, SOLR-10912.sample-patch.patch, 
> SOLR-10912.solj-contrib-facet-error.patch
>
>
> Proposing introduction of automated patch validation, similar what Hadoop or 
> other Apache projects are using (see link). This would ensure that every 
> patch passes a certain set of criterions before getting approved. It would 
> save time for developer (faster feedback loop), save time for committers 
> (less step to do manually), and would increase quality.
> Hadoop is currently using Apache Yetus to run validations, which seems to be 
> a good direction to start. This jira could be the board of discussing the 
> preferred solution.



--
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-10912) Adding automatic patch validation

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10912:


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

SOLR-10912: excluding apparently unnecessary plugins: 'junit' and 'javac' (the 
'unit' and 'compile' plugins are producing output but the 'j' ones aren't)


> Adding automatic patch validation
> -
>
> Key: SOLR-10912
> URL: https://issues.apache.org/jira/browse/SOLR-10912
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Build
>Reporter: Mano Kovacs
>Assignee: Steve Rowe
>Priority: Major
> Attachments: SOLR-10912.ok-patch-in-core.patch, SOLR-10912.patch, 
> SOLR-10912.patch, SOLR-10912.sample-patch.patch, 
> SOLR-10912.solj-contrib-facet-error.patch
>
>
> Proposing introduction of automated patch validation, similar what Hadoop or 
> other Apache projects are using (see link). This would ensure that every 
> patch passes a certain set of criterions before getting approved. It would 
> save time for developer (faster feedback loop), save time for committers 
> (less step to do manually), and would increase quality.
> Hadoop is currently using Apache Yetus to run validations, which seems to be 
> a good direction to start. This jira could be the board of discussing the 
> preferred solution.



--
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-7887) Upgrade Solr to use log4j2 -- log4j 1 now officially end of life

[Erick Erickson (JIRA)]

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

Erick Erickson commented on SOLR-7887:
--

Tomás: 

Thanks, but I can't upload a new diff to the Reviewboard that Varun opened. On 
the one I created there's an "update" button, whereas when I sign on there's 
nothing similar on Varun's that I can see.

Anyway, I'll ping Alan about pushing this over the weekend unless there are 
objections.

Erick

> Upgrade Solr to use log4j2 -- log4j 1 now officially end of life
> 
>
> Key: SOLR-7887
> URL: https://issues.apache.org/jira/browse/SOLR-7887
> Project: Solr
>  Issue Type: Task
>Affects Versions: 5.2.1
>Reporter: Shawn Heisey
>Assignee: Erick Erickson
>Priority: Major
> Attachments: SOLR-7887-WIP.patch, SOLR-7887-eoe-review.patch, 
> SOLR-7887-eoe-review.patch, SOLR-7887.patch, SOLR-7887.patch, 
> SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, 
> SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, 
> SOLR-7887.patch, SOLR-7887.patch
>
>
> The logging services project has officially announced the EOL of log4j 1:
> https://blogs.apache.org/foundation/entry/apache_logging_services_project_announces
> In the official binary jetty deployment, we use use log4j 1.2 as our final 
> logging destination, so the admin UI has a log watcher that actually uses 
> log4j and java.util.logging classes.  That will need to be extended to add 
> log4j2.  I think that might be the largest pain point to this upgrade.
> There is some crossover between log4j2 and slf4j.  Figuring out exactly which 
> jars need to be in the lib/ext directory will take some research.



--
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-11960) Add collection level properties

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-11960:


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

SOLR-11960: Don't add property listeners on core registration


> Add collection level properties
> ---
>
> Key: SOLR-11960
> URL: https://issues.apache.org/jira/browse/SOLR-11960
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Peter Rusko
>Assignee: Tomás Fernández Löbbe
>Priority: Blocker
> Fix For: 7.3
>
> Attachments: SOLR-11960.patch, SOLR-11960.patch, SOLR-11960.patch, 
> SOLR-11960.patch, SOLR-11960.patch, SOLR-11960_2.patch
>
>
> Solr has cluster properties, but no easy and extendable way of defining 
> properties that affect a single collection. Collection properties could be 
> stored in a single zookeeper node per collection, making it possible to 
> trigger zookeeper watchers for only those Solr nodes that have cores of that 
> collection.



--
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-8210) Validate patch validation

[Lucene/Solr QA (JIRA)]

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

Lucene/Solr QA commented on LUCENE-8210:


| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green}  0m 
 0s{color} | {color:green} The patch appears to include 2 new or modified test 
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  0m 
22s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  1m 
14s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green}  1m 
14s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Release audit (RAT) {color} | 
{color:green}  1m  2s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Check forbidden APIs {color} | 
{color:green}  0m 54s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Validate source patterns {color} | 
{color:green}  0m 54s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:red}-1{color} | {color:red} unit {color} | {color:red}  7m 40s{color} 
| {color:red} common in the patch failed. {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red}  1m 29s{color} 
| {color:red} icu in the patch failed. {color} |
| {color:black}{color} | {color:black} {color} | {color:black} 14m 42s{color} | 
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | lucene.analysis.charfilter.HTMLStripCharFilterTest |
|   | lucene.analysis.icu.TestICUFoldingFilter |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | LUCENE-8210 |
| JIRA Patch URL | 
https://issues.apache.org/jira/secure/attachment/12914751/LUCENE-8210.patch |
| Optional Tests |  compile  javac  unit  ratsources  checkforbiddenapis  
validatesourcepatterns  |
| uname | Linux lucene2-us-west.apache.org 4.4.0-112-generic #135-Ubuntu SMP 
Fri Jan 19 11:48:36 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | ant |
| Personality | 
/home/jenkins/jenkins-slave/workspace/PreCommit-LUCENE-Build/sourcedir/dev-tools/test-patch/lucene-solr-yetus-personality.sh
 |
| git revision | master / d50890e |
| ant | version: Apache Ant(TM) version 1.9.6 compiled on July 8 2015 |
| Default Java | 1.8.0_152 |
| unit | 
https://builds.apache.org/job/PreCommit-LUCENE-Build/5/artifact/out/patch-unit-lucene_analysis_common.txt
 |
| unit | 
https://builds.apache.org/job/PreCommit-LUCENE-Build/5/artifact/out/patch-unit-lucene_analysis_icu.txt
 |
|  Test Results | 
https://builds.apache.org/job/PreCommit-LUCENE-Build/5/testReport/ |
| modules | C: lucene/analysis/common lucene/analysis/icu U: lucene/analysis |
| Console output | 
https://builds.apache.org/job/PreCommit-LUCENE-Build/5/console |
| Powered by | Apache Yetus 0.7.0   http://yetus.apache.org |


This message was automatically generated.



> Validate patch validation 
> --
>
> Key: LUCENE-8210
> URL: https://issues.apache.org/jira/browse/LUCENE-8210
> Project: Lucene - Core
>  Issue Type: Test
>  Components: general/test
>Reporter: Steve Rowe
>Assignee: Steve Rowe
>Priority: Major
> Attachments: LUCENE-8210.patch
>
>
> Issue to host patches for testing automatic patch validation.



--
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-8210) Validate patch validation

[Lucene/Solr QA (JIRA)]

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

Lucene/Solr QA commented on LUCENE-8210:


| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green}  0m 
 0s{color} | {color:green} The patch appears to include 2 new or modified test 
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  0m 
33s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  0m 
31s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green}  0m 
31s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Release audit (RAT) {color} | 
{color:green}  0m 26s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Check forbidden APIs {color} | 
{color:green}  0m 22s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Validate source patterns {color} | 
{color:green}  0m 23s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:red}-1{color} | {color:red} unit {color} | {color:red}  3m 13s{color} 
| {color:red} common in the patch failed. {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red}  0m 27s{color} 
| {color:red} icu in the patch failed. {color} |
| {color:black}{color} | {color:black} {color} | {color:black}  6m 35s{color} | 
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | lucene.analysis.charfilter.HTMLStripCharFilterTest |
|   | lucene.analysis.icu.TestICUFoldingFilter |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | LUCENE-8210 |
| JIRA Patch URL | 
https://issues.apache.org/jira/secure/attachment/12914751/LUCENE-8210.patch |
| Optional Tests |  compile  javac  unit  ratsources  checkforbiddenapis  
validatesourcepatterns  |
| uname | Linux lucene1-us-west 3.13.0-88-generic #135-Ubuntu SMP Wed Jun 8 
21:10:42 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | ant |
| Personality | 
/home/jenkins/jenkins-slave/workspace/PreCommit-LUCENE-Build/sourcedir/dev-tools/test-patch/lucene-solr-yetus-personality.sh
 |
| git revision | master / d50890e |
| ant | version: Apache Ant(TM) version 1.9.3 compiled on April 8 2014 |
| Default Java | 1.8.0_144 |
| unit | 
https://builds.apache.org/job/PreCommit-LUCENE-Build/4/artifacts/out/patch-unit-lucene_analysis_common.txt
 |
| unit | 
https://builds.apache.org/job/PreCommit-LUCENE-Build/4/artifacts/out/patch-unit-lucene_analysis_icu.txt
 |
|  Test Results | 
https://builds.apache.org/job/PreCommit-LUCENE-Build/4/testReport/ |
| modules | C: lucene/analysis/common lucene/analysis/icu U: lucene/analysis |
| Console output | 
https://builds.apache.org/job/PreCommit-LUCENE-Build/4/console |
| Powered by | Apache Yetus 0.7.0   http://yetus.apache.org |


This message was automatically generated.



> Validate patch validation 
> --
>
> Key: LUCENE-8210
> URL: https://issues.apache.org/jira/browse/LUCENE-8210
> Project: Lucene - Core
>  Issue Type: Test
>  Components: general/test
>Reporter: Steve Rowe
>Assignee: Steve Rowe
>Priority: Major
> Attachments: LUCENE-8210.patch
>
>
> Issue to host patches for testing automatic patch validation.



--
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-12094) JsonRecordReader ignores root fields after split

[Dawid Weiss (JIRA)]

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

Dawid Weiss commented on SOLR-12094:


Uh, sorry. I didn't get what "split" does. I think it's a bug indeed.

> JsonRecordReader ignores root fields after split
> 
>
> Key: SOLR-12094
> URL: https://issues.apache.org/jira/browse/SOLR-12094
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrJ
>Affects Versions: master (8.0)
>Reporter: Przemysław Szeremiota
>Priority: Major
> Attachments: json-record-reader-bug.patch
>
>
> JsonRecordReader, when configured with other than top-level split, ignores 
> all top-level JSON nodes after split ends, for example:
> {code}
> {
>   "first": "John",
>   "last": "Doe",
>   "grade": 8,
>   "exams": [
> {
> "subject": "Maths",
> "test": "term1",
> "marks": 90
> },
> {
> "subject": "Biology",
> "test": "term1",
> "marks": 86
> }
>   ],
>   "after": "456"
> }
> {code}
> Node "after" won't be visible in SolrInputDocument constructed from 
> /update/json/docs.
> I don't have fix, only (breaking) patch for relevant test



--
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-8210) Validate patch validation

[Lucene/Solr QA (JIRA)]

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

Lucene/Solr QA commented on LUCENE-8210:


| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green}  0m 
 0s{color} | {color:green} The patch appears to include 2 new or modified test 
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  0m 
31s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  0m 
30s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green}  0m 
30s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Release audit (RAT) {color} | 
{color:green}  0m 26s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Check forbidden APIs {color} | 
{color:green}  0m 22s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Validate source patterns {color} | 
{color:green}  0m 22s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:red}-1{color} | {color:red} unit {color} | {color:red}  3m 21s{color} 
| {color:red} common in the patch failed. {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red}  0m 31s{color} 
| {color:red} icu in the patch failed. {color} |
| {color:black}{color} | {color:black} {color} | {color:black}  6m 43s{color} | 
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | lucene.analysis.charfilter.HTMLStripCharFilterTest |
|   | lucene.analysis.icu.TestICUFoldingFilter |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | LUCENE-8210 |
| JIRA Patch URL | 
https://issues.apache.org/jira/secure/attachment/12914751/LUCENE-8210.patch |
| Optional Tests |  compile  javac  unit  ratsources  checkforbiddenapis  
validatesourcepatterns  |
| uname | Linux lucene1-us-west 3.13.0-88-generic #135-Ubuntu SMP Wed Jun 8 
21:10:42 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | ant |
| Personality | 
/home/jenkins/jenkins-slave/workspace/PreCommit-LUCENE-Build/sourcedir/dev-tools/test-patch/lucene-solr-yetus-personality.sh
 |
| git revision | master / d50890e |
| ant | version: Apache Ant(TM) version 1.9.3 compiled on April 8 2014 |
| Default Java | 1.8.0_144 |
| unit | 
https://builds.apache.org/job/PreCommit-LUCENE-Build/3/artifact/patchprocess/patch-unit-lucene_analysis_common.txt
 |
| unit | 
https://builds.apache.org/job/PreCommit-LUCENE-Build/3/artifact/patchprocess/patch-unit-lucene_analysis_icu.txt
 |
|  Test Results | 
https://builds.apache.org/job/PreCommit-LUCENE-Build/3/testReport/ |
| modules | C: lucene/analysis/common lucene/analysis/icu U: lucene/analysis |
| Console output | 
https://builds.apache.org/job/PreCommit-LUCENE-Build/3/console |
| Powered by | Apache Yetus 0.7.0   http://yetus.apache.org |


This message was automatically generated.



> Validate patch validation 
> --
>
> Key: LUCENE-8210
> URL: https://issues.apache.org/jira/browse/LUCENE-8210
> Project: Lucene - Core
>  Issue Type: Test
>  Components: general/test
>Reporter: Steve Rowe
>Assignee: Steve Rowe
>Priority: Major
> Attachments: LUCENE-8210.patch
>
>
> Issue to host patches for testing automatic patch validation.



--
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-12094) JsonRecordReader ignores root fields after split

[Dawid Weiss (JIRA)]

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

Dawid Weiss commented on SOLR-12094:


There is something I don't understand. In your patch this node is outside of 
the {{/exams}} path:
{code}
  public void testRecursiveWildcard2() throws Exception {
String json = "{\n" +
"  \"first\": \"John\",\n" +
"  \"last\": \"Doe\",\n" +
"  \"grade\": 8,\n" +
"  \"exams\": [\n" +
"  {\n" +
"\"subject\": \"Maths\",\n" +
"\"test\"   : \"term1\",\n" +
"\"marks\":90},\n" +
"{\n" +
" \"subject\": \"Biology\",\n" +
" \"test\"   : \"term1\",\n" +
" \"marks\":86}\n" +
"  ],\n" +
"  \"after\": \"456\"\n" +
"}";

JsonRecordReader streamer;
List> records;

streamer = JsonRecordReader.getInst("/exams", 
Collections.singletonList("/**"));
records = streamer.getAllRecords(new StringReader(json));
assertEquals(2, records.size());
for (Map record : records) {
  assertEquals(7, record.size());
  assertTrue(record.containsKey("subject"));
  assertTrue(record.containsKey("test"));
  assertTrue(record.containsKey("marks"));
  assertTrue(record.containsKey("first"));
  assertTrue(record.containsKey("last"));
  assertTrue(record.containsKey("grade"));
  assertTrue(record.containsKey("after"));
}
{code}

So it fails for a reason -- {{after}} shouldn't be there and that's the correct 
behavior?

> JsonRecordReader ignores root fields after split
> 
>
> Key: SOLR-12094
> URL: https://issues.apache.org/jira/browse/SOLR-12094
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrJ
>Affects Versions: master (8.0)
>Reporter: Przemysław Szeremiota
>Priority: Major
> Attachments: json-record-reader-bug.patch
>
>
> JsonRecordReader, when configured with other than top-level split, ignores 
> all top-level JSON nodes after split ends, for example:
> {code}
> {
>   "first": "John",
>   "last": "Doe",
>   "grade": 8,
>   "exams": [
> {
> "subject": "Maths",
> "test": "term1",
> "marks": 90
> },
> {
> "subject": "Biology",
> "test": "term1",
> "marks": 86
> }
>   ],
>   "after": "456"
> }
> {code}
> Node "after" won't be visible in SolrInputDocument constructed from 
> /update/json/docs.
> I don't have fix, only (breaking) patch for relevant test



--
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-8175) ICUTokenizer might return corrupt tokens due to concurrency bug in ICU4J

[Adrien Grand (JIRA)]

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

Adrien Grand commented on LUCENE-8175:
--

I just tried with the rc of icu4j-61 and I can't reproduce the bug. (y)

> ICUTokenizer might return corrupt tokens due to concurrency bug in ICU4J
> 
>
> Key: LUCENE-8175
> URL: https://issues.apache.org/jira/browse/LUCENE-8175
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Adrien Grand
>Priority: Critical
>
> I was digging some test failures with {{testRandomHugeStrings}} that occurred 
> since the upgrade to ICU4J 60.2 which happen to boil down to this bug: 
> http://bugs.icu-project.org/trac/ticket/13512 which is fixed but not released 
> yet.
> In short an int[] is shared across several threads while it shouldn't. As a 
> consequence, ICUTokenizer may sometimes return corrupt tokens. I pinged on 
> the issue to know when a release fixing this bug is expected.



--
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-8210) Validate patch validation

[Steve Rowe (JIRA)]

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

Steve Rowe updated LUCENE-8210:
---
Attachment: LUCENE-8210.patch

> Validate patch validation 
> --
>
> Key: LUCENE-8210
> URL: https://issues.apache.org/jira/browse/LUCENE-8210
> Project: Lucene - Core
>  Issue Type: Test
>  Components: general/test
>Reporter: Steve Rowe
>Assignee: Steve Rowe
>Priority: Major
> Attachments: LUCENE-8210.patch
>
>
> Issue to host patches for testing automatic patch validation.



--
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-12103) Raise CryptoKeys.DEFAULT_KEYPAIR_LENGTH from 1024 to 2048.

[Mark Miller (JIRA)]

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

Mark Miller updated SOLR-12103:
---
Attachment: SOLR-12103.patch

> Raise CryptoKeys.DEFAULT_KEYPAIR_LENGTH from 1024 to 2048.
> --
>
> Key: SOLR-12103
> URL: https://issues.apache.org/jira/browse/SOLR-12103
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Mark Miller
>Assignee: Mark Miller
>Priority: Major
> Attachments: SOLR-12103.patch
>
>
> Our security scan flagged this - 1024 is too low to prevent against brute 
> force attacks. This was already raised once in SOLR-9609, raising again.



--
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-12103) Raise CryptoKeys.DEFAULT_KEYPAIR_LENGTH from 1024 to 2048.

[Mark Miller (JIRA)]

Mark Miller created SOLR-12103:
--

 Summary: Raise CryptoKeys.DEFAULT_KEYPAIR_LENGTH from 1024 to 2048.
 Key: SOLR-12103
 URL: https://issues.apache.org/jira/browse/SOLR-12103
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Mark Miller
Assignee: Mark Miller


Our security scan flagged this - 1024 is too low to prevent against brute force 
attacks. This was already raised once in SOLR-9609, raising again.



--
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-12098) Document the Lucene spins auto-detection and its effect on CMS dynamic defaults

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar resolved SOLR-12098.
--
Resolution: Fixed
  Assignee: Shalin Shekhar Mangar

Thanks Cassandra!

> Document the Lucene spins auto-detection and its effect on CMS dynamic 
> defaults
> ---
>
> Key: SOLR-12098
> URL: https://issues.apache.org/jira/browse/SOLR-12098
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Shalin Shekhar Mangar
>Assignee: Shalin Shekhar Mangar
>Priority: Major
> Fix For: 7.3, master (8.0)
>
> Attachments: SOLR-12098.patch, SOLR-12098.patch
>
>
> Lucene auto-detects whether the underlying directory is on a rotational or 
> SSD type disk and based on that it sets defaults for 
> ConcurrentMergeScheduler. We should document this and the system property 
> based workaround in the Taking Solr to Production page (and perhaps also in 
> solrconfig.xml sections)



--
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-12098) Document the Lucene spins auto-detection and its effect on CMS dynamic defaults

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-12098:


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

SOLR-12098: Document the Lucene spins auto-detection and its effect on CMS 
dynamic defaults

(cherry picked from commit d50890e)

(cherry picked from commit ad82d65)


> Document the Lucene spins auto-detection and its effect on CMS dynamic 
> defaults
> ---
>
> Key: SOLR-12098
> URL: https://issues.apache.org/jira/browse/SOLR-12098
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Shalin Shekhar Mangar
>Priority: Major
> Fix For: 7.3, master (8.0)
>
> Attachments: SOLR-12098.patch, SOLR-12098.patch
>
>
> Lucene auto-detects whether the underlying directory is on a rotational or 
> SSD type disk and based on that it sets defaults for 
> ConcurrentMergeScheduler. We should document this and the system property 
> based workaround in the Taking Solr to Production page (and perhaps also in 
> solrconfig.xml sections)



--
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-12098) Document the Lucene spins auto-detection and its effect on CMS dynamic defaults

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-12098:


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

SOLR-12098: Document the Lucene spins auto-detection and its effect on CMS 
dynamic defaults


> Document the Lucene spins auto-detection and its effect on CMS dynamic 
> defaults
> ---
>
> Key: SOLR-12098
> URL: https://issues.apache.org/jira/browse/SOLR-12098
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Shalin Shekhar Mangar
>Priority: Major
> Fix For: 7.3, master (8.0)
>
> Attachments: SOLR-12098.patch, SOLR-12098.patch
>
>
> Lucene auto-detects whether the underlying directory is on a rotational or 
> SSD type disk and based on that it sets defaults for 
> ConcurrentMergeScheduler. We should document this and the system property 
> based workaround in the Taking Solr to Production page (and perhaps also in 
> solrconfig.xml sections)



--
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-12098) Document the Lucene spins auto-detection and its effect on CMS dynamic defaults

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-12098:


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

SOLR-12098: Document the Lucene spins auto-detection and its effect on CMS 
dynamic defaults

(cherry picked from commit d50890e)


> Document the Lucene spins auto-detection and its effect on CMS dynamic 
> defaults
> ---
>
> Key: SOLR-12098
> URL: https://issues.apache.org/jira/browse/SOLR-12098
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Shalin Shekhar Mangar
>Priority: Major
> Fix For: 7.3, master (8.0)
>
> Attachments: SOLR-12098.patch, SOLR-12098.patch
>
>
> Lucene auto-detects whether the underlying directory is on a rotational or 
> SSD type disk and based on that it sets defaults for 
> ConcurrentMergeScheduler. We should document this and the system property 
> based workaround in the Taking Solr to Production page (and perhaps also in 
> solrconfig.xml sections)



--
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-8210) Validate patch validation

[Steve Rowe (JIRA)]

Steve Rowe created LUCENE-8210:
--

 Summary: Validate patch validation 
 Key: LUCENE-8210
 URL: https://issues.apache.org/jira/browse/LUCENE-8210
 Project: Lucene - Core
  Issue Type: Test
  Components: general/test
Reporter: Steve Rowe
Assignee: Steve Rowe


Issue to host patches for testing automatic patch validation.



--
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-8209) CommonGramFilter should work on stacked tokens.

[Adrien Grand (JIRA)]

Adrien Grand created LUCENE-8209:


 Summary: CommonGramFilter should work on stacked tokens.
 Key: LUCENE-8209
 URL: https://issues.apache.org/jira/browse/LUCENE-8209
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Adrien Grand


Currently it doesn't.

ShingleFilter has the same issue but CommonGramFilter might be easier to fix 
given that it supports fewer options and only needs to work at index time (ie. 
no need to be able to consume graphs).

CommonGramsQueryFilter might be a bit harder to fix if we want to make it 
support arbitrary graph inputs.



--
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-12071) PULL replica cores initialisation fails when Cdcr enabled

[Amrit Sarkar (JIRA)]

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

Amrit Sarkar updated SOLR-12071:

Attachment: SOLR-12071.patch

> PULL replica cores initialisation fails when Cdcr enabled
> -
>
> Key: SOLR-12071
> URL: https://issues.apache.org/jira/browse/SOLR-12071
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: CDCR
>Affects Versions: 7.2
>Reporter: Amrit Sarkar
>Assignee: Varun Thacker
>Priority: Major
> Attachments: SOLR-12071.patch, SOLR-12071.patch, SOLR-12071.patch
>
>
> {{CdcrUpdateLog}} never gets picked up for PULL type replicas and hence the 
> core initialisation fails when a collection is CDCR enabled, obviously it 
> can't be a leader, but followers.
> {code}
>[junit4]   2> 47345 INFO  (qtp1256767285-28) [n:127.0.0.1:50646_solr 
> c:cdcr-cluster2 s:shard1 r:core_node4 x:cdcr-cluster2_shard1_replica_p2] 
> o.a.s.m.SolrMetricManager Closing metric reporters for 
> registry=solr.collection.cdcr-cluster2.shard1.leader, tag=895903268
>[junit4]   2> 47353 INFO  
> (searcherExecutor-32-thread-1-processing-n:127.0.0.1:50646_solr 
> x:cdcr-cluster2_shard1_replica_t1 s:shard1 c:cdcr-cluster2 r:core_node3) 
> [n:127.0.0.1:50646_solr c:cdcr-cluster2 s:shard1 r:core_node3 
> x:cdcr-cluster2_shard1_replica_t1] o.a.s.c.SolrCore 
> [cdcr-cluster2_shard1_replica_t1] Registered new searcher 
> Searcher@638c50cd[cdcr-cluster2_shard1_replica_t1] 
> main{ExitableDirectoryReader(UninvertingDirectoryReader())}
>[junit4]   2> 47353 ERROR (qtp1256767285-28) [n:127.0.0.1:50646_solr 
> c:cdcr-cluster2 s:shard1 r:core_node4 x:cdcr-cluster2_shard1_replica_p2] 
> o.a.s.h.RequestHandlerBase org.apache.solr.common.SolrException: Error 
> CREATEing SolrCore 'cdcr-cluster2_shard1_replica_p2': Unable to create core 
> [cdcr-cluster2_shard1_replica_p2] Caused by: Solr instance is not configured 
> with the cdcr update log.
>[junit4]   2>  at 
> org.apache.solr.core.CoreContainer.create(CoreContainer.java:993)
>[junit4]   2>  at 
> org.apache.solr.handler.admin.CoreAdminOperation.lambda$static$0(CoreAdminOperation.java:90)
>[junit4]   2>  at 
> org.apache.solr.handler.admin.CoreAdminOperation.execute(CoreAdminOperation.java:358)
>[junit4]   2>  at 
> org.apache.solr.handler.admin.CoreAdminHandler$CallInfo.call(CoreAdminHandler.java:389)
>[junit4]   2>  at 
> org.apache.solr.handler.admin.CoreAdminHandler.handleRequestBody(CoreAdminHandler.java:174)
>[junit4]   2>  at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:195)
>[junit4]   2>  at 
> org.apache.solr.servlet.HttpSolrCall.handleAdmin(HttpSolrCall.java:736)
>[junit4]   2>  at 
> org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:717)
>[junit4]   2>  at 
> org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:498)
>[junit4]   2>  at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:384)
>[junit4]   2>  at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:330)
>[junit4]   2>  at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1637)
>[junit4]   2>  at 
> org.apache.solr.client.solrj.embedded.JettySolrRunner$DebugFilter.doFilter(JettySolrRunner.java:139)
>[junit4]   2>  at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1637)
>[junit4]   2>  at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:533)
>[junit4]   2>  at 
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:188)
>[junit4]   2>  at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1595)
>[junit4]   2>  at 
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:188)
>[junit4]   2>  at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1253)
>[junit4]   2>  at 
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:168)
>[junit4]   2>  at 
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:473)
>[junit4]   2>  at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1564)
>[junit4]   2>  at 
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:166)
>[junit4]   2>  at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1155)
>[junit4]   2>  at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
>[junit4] 

[jira] [Commented] (LUCENE-8202) Add a FixedShingleFilter

[Adrien Grand (JIRA)]

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

Adrien Grand commented on LUCENE-8202:
--

Thanks Alan, I agree this issue looks easier to address if we don't have to 
support all the features that ShingleFilter accumulated over the years and 
focus on index-time phrase tokenization. Some comments about the patch:
 - Can you make this filter experimental, ideally it would get merged with 
ShingleFilter eventually?
 - Can you clarify in the sentence about stacked shingles that this is how this 
filter differs from ShingleFilter. I think it's important for users to realize 
when it makes sense to use this one.
 - Let's not use upper case for variables that are not static? (GAP_TOKEN and 
END_TOKEN)
 - Let's make tokenPool an ArrayDeque instead for efficiency?
 - Token doesn't need the type attribute, does it?
 - advanceStack runs in quadratic time with shingleSize, is it something we can 
fix? If not then let's put an upper bound on the value that shingleSize may 
take (which might be a good move regardless).
 - Token.reset should use AttributeSource.copyTo rather than 
captureState+restoreState? This would save a lot of cloning.
 - If it only cares about index-time I'm confused why it tries to work on graph 
inputs, I think it's safe to assume and document that the FlattenGraphFilter 
must be applied prior to the FixedShingleFilter? Said otherwise, say you have 
an existing analyzer. I think we should have the goal that wrapping this 
analyzer (AnalyzerWrapper) with a FixedShingleFilter should emit exactly all 
the exact phrases of length `shingleSize` that you could search if you indexed 
with the wrapped analyzer directly? For instance if I look at the 
{{testMultiLengthPathShingles}} test, it indexes the shingle "the usa is". But 
this is not a phrase that you can search if you create the same analysis chain 
without the shingle filter in the end ("the" and "usa" are at position 0 and 1, 
but "is" is at position 6).

> Add a FixedShingleFilter
> 
>
> Key: LUCENE-8202
> URL: https://issues.apache.org/jira/browse/LUCENE-8202
> Project: Lucene - Core
>  Issue Type: New Feature
>Reporter: Alan Woodward
>Assignee: Alan Woodward
>Priority: Major
> Attachments: LUCENE-8202.patch
>
>
> In LUCENE-3475 I tried to make a ShingleGraphFilter that could accept and 
> emit arbitrary graphs, while duplicating all the functionality of the 
> existing ShingleFilter.  This ends up being extremely hairy, and doesn't play 
> well with query parsers.
> I'd like to step back and try and create a simpler shingle filter that can be 
> used for index-time phrase tokenization only.  It will have a single fixed 
> shingle size, can deal with single-token synonyms, and won't emit unigrams.



--
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-8208) Vector.isNumericallyIdentical() can produce unexpected results

[ASF subversion and git services (JIRA)]

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

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

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

LUCENE-8208: Use a tighter definition of identical when it comes to vectors.


> Vector.isNumericallyIdentical() can produce unexpected results
> --
>
> Key: LUCENE-8208
> URL: https://issues.apache.org/jira/browse/LUCENE-8208
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/spatial3d
>Reporter: Ignacio Vera
>Assignee: Karl Wright
>Priority: Major
> Attachments: LUCENE-8208.patch
>
>
> The method {{Vector.isNumericallyIdentical()}} seems to produce wrong results 
> in some cases. For example it considers that vectors (1,0,0) and (-1,0,0) are 
> numerically identical whichI is probably wrong.
> This behavior might produce unexpected behaviors down the line.
>  



--
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-8208) Vector.isNumericallyIdentical() can produce unexpected results

[ASF subversion and git services (JIRA)]

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

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

Commit 6c61b155799ed3829e7e63a5ef4be8d9d51cd298 in lucene-solr's branch 
refs/heads/branch_7x from [~kwri...@metacarta.com]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=6c61b15 ]

LUCENE-8208: Use a tighter definition of identical when it comes to vectors.


> Vector.isNumericallyIdentical() can produce unexpected results
> --
>
> Key: LUCENE-8208
> URL: https://issues.apache.org/jira/browse/LUCENE-8208
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/spatial3d
>Reporter: Ignacio Vera
>Assignee: Karl Wright
>Priority: Major
> Attachments: LUCENE-8208.patch
>
>
> The method {{Vector.isNumericallyIdentical()}} seems to produce wrong results 
> in some cases. For example it considers that vectors (1,0,0) and (-1,0,0) are 
> numerically identical whichI is probably wrong.
> This behavior might produce unexpected behaviors down the line.
>  



--
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-8208) Vector.isNumericallyIdentical() can produce unexpected results

[ASF subversion and git services (JIRA)]

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

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

Commit 793614bd14821e5a3d965e77869d8ba658b18a9e in lucene-solr's branch 
refs/heads/branch_6x from [~kwri...@metacarta.com]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=793614b ]

LUCENE-8208: Use a tighter definition of identical when it comes to vectors.


> Vector.isNumericallyIdentical() can produce unexpected results
> --
>
> Key: LUCENE-8208
> URL: https://issues.apache.org/jira/browse/LUCENE-8208
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/spatial3d
>Reporter: Ignacio Vera
>Assignee: Karl Wright
>Priority: Major
> Attachments: LUCENE-8208.patch
>
>
> The method {{Vector.isNumericallyIdentical()}} seems to produce wrong results 
> in some cases. For example it considers that vectors (1,0,0) and (-1,0,0) are 
> numerically identical whichI is probably wrong.
> This behavior might produce unexpected behaviors down the line.
>  



--
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] (LUCENE-8208) Vector.isNumericallyIdentical() can produce unexpected results

[Karl Wright (JIRA)]

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

Karl Wright resolved LUCENE-8208.
-
   Resolution: Fixed
Fix Version/s: master (8.0)
   7.3
   6.7

> Vector.isNumericallyIdentical() can produce unexpected results
> --
>
> Key: LUCENE-8208
> URL: https://issues.apache.org/jira/browse/LUCENE-8208
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/spatial3d
>Reporter: Ignacio Vera
>Assignee: Karl Wright
>Priority: Major
> Fix For: 6.7, 7.3, master (8.0)
>
> Attachments: LUCENE-8208.patch
>
>
> The method {{Vector.isNumericallyIdentical()}} seems to produce wrong results 
> in some cases. For example it considers that vectors (1,0,0) and (-1,0,0) are 
> numerically identical whichI is probably wrong.
> This behavior might produce unexpected behaviors down the line.
>  



--
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-12065) Restore replica always in buffering state

[Amrit Sarkar (JIRA)]

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

Amrit Sarkar updated SOLR-12065:

Attachment: SOLR-12071.patch

> Restore replica always in buffering state
> -
>
> Key: SOLR-12065
> URL: https://issues.apache.org/jira/browse/SOLR-12065
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Varun Thacker
>Assignee: Varun Thacker
>Priority: Major
> Attachments: SOLR-12071.patch, restore_snippet.log
>
>
> Steps to reproduce:
>  
>  - 
> [http://localhost:8983/solr/admin/collections?action=CREATE=test_backup=1=1]
>  - curl [http://127.0.0.1:8983/solr/test_backup/update?commit=true] -H 
> 'Content-type:application/json' -d '
>  [ \{"id" : "1"}
> ]' 
>  - 
> [http://localhost:8983/solr/admin/collections?action=BACKUP=test_backup=test_backup=/Users/varunthacker/backups]
>  - 
> [http://localhost:8983/solr/admin/collections?action=RESTORE=test_backup=/Users/varunthacker/backups=test_restore]
>  * curl [http://127.0.0.1:8983/solr/test_restore/update?commit=true] -H 
> 'Content-type:application/json' -d '
>  [
> {"id" : "2"}
> ]'
>  * Snippet when you try adding a document
> {code:java}
> INFO - 2018-03-07 22:48:11.555; [c:test_restore s:shard1 r:core_node22 
> x:test_restore_shard1_replica_n21] 
> org.apache.solr.update.processor.DistributedUpdateProcessor; Ignoring commit 
> while not ACTIVE - state: BUFFERING replay: false
> INFO - 2018-03-07 22:48:11.556; [c:test_restore s:shard1 r:core_node22 
> x:test_restore_shard1_replica_n21] 
> org.apache.solr.update.processor.LogUpdateProcessorFactory$LogUpdateProcessor;
>  [test_restore_shard1_replica_n21] webapp=/solr path=/update 
> params={commit=true}{add=[2 (1594320896973078528)],commit=} 0 4{code}
>  * If you see "TLOG.state" from [http://localhost:8983/solr/admin/metrics] 
> it's always 1 (BUFFERING)
>  
>  



--
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-10912) Adding automatic patch validation

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10912:


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

SOLR-10912: Add scripts for automatic patch validation


> Adding automatic patch validation
> -
>
> Key: SOLR-10912
> URL: https://issues.apache.org/jira/browse/SOLR-10912
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Build
>Reporter: Mano Kovacs
>Assignee: Steve Rowe
>Priority: Major
> Attachments: SOLR-10912.ok-patch-in-core.patch, SOLR-10912.patch, 
> SOLR-10912.patch, SOLR-10912.sample-patch.patch, 
> SOLR-10912.solj-contrib-facet-error.patch
>
>
> Proposing introduction of automated patch validation, similar what Hadoop or 
> other Apache projects are using (see link). This would ensure that every 
> patch passes a certain set of criterions before getting approved. It would 
> save time for developer (faster feedback loop), save time for committers 
> (less step to do manually), and would increase quality.
> Hadoop is currently using Apache Yetus to run validations, which seems to be 
> a good direction to start. This jira could be the board of discussing the 
> preferred solution.



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