[JENKINS] Lucene-Solr-master-Linux (64bit/jdk-9) - Build # 20775 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/20775/
Java: 64bit/jdk-9 -XX:+UseCompressedOops -XX:+UseG1GC --illegal-access=deny

11 tests failed.
FAILED:  
org.apache.solr.client.solrj.io.stream.StreamExpressionTest.testParallelDaemonCommitStream

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

Stack Trace:
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at https://127.0.0.1:37189/solr: create the collection time out:180s
at 
__randomizedtesting.SeedInfo.seed([3F004C74A721AA1C:9FF61DF162506482]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:658)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:255)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:244)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:483)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:413)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1096)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:875)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:808)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:178)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:195)
at 
org.apache.solr.client.solrj.io.stream.StreamExpressionTest.testParallelDaemonCommitStream(StreamExpressionTest.java:4644)
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.ra

[jira] [Commented] (SOLR-11380) SolrJ must stream docs to server instead of writing to a byte[] first

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-11380:


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

SOLR-11380: use the inNull() method to check for empty UpdateRequest


> SolrJ must stream docs to server instead of writing to a byte[] first 
> --
>
> Key: SOLR-11380
> URL: https://issues.apache.org/jira/browse/SOLR-11380
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Noble Paul
>Assignee: Noble Paul
> Fix For: 7.2, master (8.0)
>
> Attachments: SOLR-11380.patch
>
>




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

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

[jira] [Commented] (SOLR-11380) SolrJ must stream docs to server instead of writing to a byte[] first

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-11380:


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

SOLR-11380: use the inNull() method to check for empty UpdateRequest


> SolrJ must stream docs to server instead of writing to a byte[] first 
> --
>
> Key: SOLR-11380
> URL: https://issues.apache.org/jira/browse/SOLR-11380
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Noble Paul
>Assignee: Noble Paul
> Fix For: 7.2, master (8.0)
>
> Attachments: SOLR-11380.patch
>
>




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

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

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

[Policeman Jenkins Server]

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

1 tests failed.
FAILED:  
org.apache.solr.cloud.CollectionsAPIDistributedZkTest.testCollectionsAPI

Error Message:
Error from server at 
http://127.0.0.1:49826/solr/awhollynewcollection_0_shard4_replica_n6: 
ClusterState says we are the leader 
(http://127.0.0.1:49826/solr/awhollynewcollection_0_shard4_replica_n6), but 
locally we don't think so. Request came from null

Stack Trace:
org.apache.solr.client.solrj.impl.CloudSolrClient$RouteException: Error from 
server at http://127.0.0.1:49826/solr/awhollynewcollection_0_shard4_replica_n6: 
ClusterState says we are the leader 
(http://127.0.0.1:49826/solr/awhollynewcollection_0_shard4_replica_n6), but 
locally we don't think so. Request came from null
at 
__randomizedtesting.SeedInfo.seed([7EAA753834CF9256:36DF018C32FCBDC3]:0)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:541)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1008)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:875)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:937)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:937)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:937)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:937)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:937)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:808)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:178)
at 
org.apache.solr.client.solrj.request.UpdateRequest.commit(UpdateRequest.java:233)
at 
org.apache.solr.cloud.CollectionsAPIDistributedZkTest.testCollectionsAPI(CollectionsAPIDistributedZkTest.java:459)
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(TestRuleStoreCla

[JENKINS] Lucene-Solr-Tests-master - Build # 2138 - Still Failing

[Apache Jenkins Server]

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

All tests passed

Build Log:
[...truncated 1794 lines...]
   [junit4] JVM J1: stdout was not empty, see: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/lucene/build/core/test/temp/junit4-J1-20171031_050437_2478891515106087960845.sysout
   [junit4] >>> JVM J1 emitted unexpected output (verbatim) 
   [junit4] #
   [junit4] # There is insufficient memory for the Java Runtime Environment to 
continue.
   [junit4] # Native memory allocation (mmap) failed to map 20971520 bytes for 
committing reserved memory.
   [junit4] # An error report file with more information is saved as:
   [junit4] # 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/lucene/build/core/test/J1/hs_err_pid6959.log
   [junit4] <<< JVM J1: EOF 

   [junit4] JVM J1: stderr was not empty, see: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/lucene/build/core/test/temp/junit4-J1-20171031_050437_2474570365342939563780.syserr
   [junit4] >>> JVM J1 emitted unexpected output (verbatim) 
   [junit4] Java HotSpot(TM) 64-Bit Server VM warning: INFO: 
os::commit_memory(0xecd8, 20971520, 0) failed; error='Cannot 
allocate memory' (errno=12)
   [junit4] <<< JVM J1: EOF 

[...truncated 46 lines...]
   [junit4] ERROR: JVM J1 ended with an exception, command line: 
/usr/local/asfpackages/java/jdk1.8.0_144/jre/bin/java 
-XX:+HeapDumpOnOutOfMemoryError 
-XX:HeapDumpPath=/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/heapdumps
 -ea -esa -Dtests.prefix=tests -Dtests.seed=6A7022F4D9C0A95F -Xmx512M 
-Dtests.iters= -Dtests.verbose=false -Dtests.infostream=false 
-Dtests.codec=random -Dtests.postingsformat=random 
-Dtests.docvaluesformat=random -Dtests.locale=random -Dtests.timezone=random 
-Dtests.directory=random -Dtests.linedocsfile=europarl.lines.txt.gz 
-Dtests.luceneMatchVersion=8.0.0 -Dtests.cleanthreads=perMethod 
-Djava.util.logging.config.file=/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/lucene/tools/junit4/logging.properties
 -Dtests.nightly=false -Dtests.weekly=false -Dtests.monster=false 
-Dtests.slow=true -Dtests.asserts=true -Dtests.multiplier=2 -DtempDir=./temp 
-Djava.io.tmpdir=./temp 
-Djunit4.tempDir=/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/lucene/build/core/test/temp
 
-Dcommon.dir=/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/lucene
 
-Dclover.db.dir=/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/lucene/build/clover/db
 
-Djava.security.policy=/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/lucene/tools/junit4/tests.policy
 -Dtests.LUCENE_VERSION=8.0.0 -Djetty.testMode=1 -Djetty.insecurerandom=1 
-Dsolr.directoryFactory=org.apache.solr.core.MockDirectoryFactory 
-Djava.awt.headless=true -Djdk.map.althashing.threshold=0 
-Dtests.src.home=/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master 
-Djava.security.egd=file:/dev/./urandom 
-Djunit4.childvm.cwd=/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/lucene/build/core/test/J1
 -Djunit4.childvm.id=1 -Djunit4.childvm.count=3 -Dtests.leaveTemporary=false 
-Dtests.filterstacks=true 
-Djava.security.manager=org.apache.lucene.util.TestSecurityManager 
-Dfile.encoding=UTF-8 -classpath 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/lucene/build/codecs/classes/java:/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/lucene/build/test-framework/classes/java:/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/lucene/test-framework/lib/junit-4.10.jar:/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/lucene/test-framework/lib/randomizedtesting-runner-2.5.3.jar:/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/lucene/build/core/classes/java:/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/lucene/build/core/classes/test:/home/jenkins/tools/ant/apache-ant-1.8.4/lib/ant-launcher.jar:/x1/jenkins/.ant/lib/ivy-2.3.0.jar:/home/jenkins/tools/ant/apache-ant-1.8.4/lib/ant-junit.jar:/home/jenkins/tools/ant/apache-ant-1.8.4/lib/ant-apache-log4j.jar:/home/jenkins/tools/ant/apache-ant-1.8.4/lib/ant-junit4.jar:/home/jenkins/tools/ant/apache-ant-1.8.4/lib/ant-jai.jar:/home/jenkins/tools/ant/apache-ant-1.8.4/lib/ant-javamail.jar:/home/jenkins/tools/ant/apache-ant-1.8.4/lib/ant-apache-bsf.jar:/home/jenkins/tools/ant/apache-ant-1.8.4/lib/ant-commons-net.jar:/home/jenkins/tools/ant/apache-ant-1.8.4/lib/ant-antlr.jar:/home/jenkins/tools/ant/apache-ant-1.8.4/lib/ant-jsch.jar:/home/jenkins/tools/ant/apache-ant-1.8.4/lib/ant-apache-oro.jar:/home/jenkins/tools/ant/apache-ant-1.8.4/lib/ant-commons-logging.jar:/home/jenkins/tools/ant/apache-ant-1.8.4/lib/ant.jar:/home/jenkins/tools/ant/apache-ant-1.8.4/lib/ant-netrexx.jar:/home/jenkins/tools/ant/apache-ant-1.8.4/lib/ant-testutil.jar:/home/jenkins/tools/ant/apache-ant-1.8.4/lib/ant-jdepend.jar:/home/jenkins/tools/ant/apache-ant-1.8.4/lib/ant-apache-bcel.jar:/home/jenkins/tools/

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

[Policeman Jenkins Server]

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

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

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

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

[jira] [Commented] (SOLR-11380) SolrJ must stream docs to server instead of writing to a byte[] first

[Noble Paul (JIRA)]

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

Noble Paul commented on SOLR-11380:
---

Correct. The code is identical AND useless. 

The point is even if we make it better, it is extremely difficult to do a 
Streaming WRITE to an {{InputStream}} .

> SolrJ must stream docs to server instead of writing to a byte[] first 
> --
>
> Key: SOLR-11380
> URL: https://issues.apache.org/jira/browse/SOLR-11380
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Noble Paul
>Assignee: Noble Paul
> Fix For: 7.2, master (8.0)
>
> Attachments: SOLR-11380.patch
>
>




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

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

[JENKINS] Lucene-Solr-Tests-7.x - Build # 199 - Still Failing

[Apache Jenkins Server]

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

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

Error Message:
expected: but was:

Stack Trace:
java.lang.AssertionError: expected: but was:
at 
__randomizedtesting.SeedInfo.seed([39042BD03F00148:8BC47D67AD0C6CB0]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.failNotEquals(Assert.java:647)
at org.junit.Assert.assertEquals(Assert.java:128)
at org.junit.Assert.assertEquals(Assert.java:147)
at 
org.apache.solr.cloud.AbstractCloudBackupRestoreTestCase.testBackupAndRestore(AbstractCloudBackupRestoreTestCase.java:277)
at 
org.apache.solr.cloud.AbstractCloudBackupRestoreTestCase.test(AbstractCloudBackupRestoreTestCase.java:136)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java: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)




Build Log:
[...truncated 11578 lines...]
   [junit4] Suite: org.apache.solr.cloud.TestLocalFSCloudBackupRestore
   [j

[jira] [Commented] (SOLR-11380) SolrJ must stream docs to server instead of writing to a byte[] first

[David Smiley (JIRA)]

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

David Smiley commented on SOLR-11380:
-

Ok but the code is identical on both sides of the {{else}} which can't be 
intended?

> SolrJ must stream docs to server instead of writing to a byte[] first 
> --
>
> Key: SOLR-11380
> URL: https://issues.apache.org/jira/browse/SOLR-11380
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Noble Paul
>Assignee: Noble Paul
> Fix For: 7.2, master (8.0)
>
> Attachments: SOLR-11380.patch
>
>




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

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

[jira] [Updated] (SOLR-6944) ReplicationFactorTest and HttpPartitionTest both fail with org.apache.http.NoHttpResponseException: The target server failed to respond

[Erick Erickson (JIRA)]

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

Erick Erickson updated SOLR-6944:
-
Attachment: stdout.41
stdout.131
stdout.251
stdout.319
stdout.385

On my Mac Pro, this test doesn't fail (ReplicationFactorTest), but on a Dell 
server I have access to I get several distinct  failure patterns in the file 
above.

My work on SOLR-11438 is done, that's the point of doing all the beasting and 
running in to these errors. So I'll reset @BadApple on ReplicationFactorTest 
before checking that JIRA in.

I'd love to be able to take that annotation off the tests for 
ReplicationFactorTest, but we have too much noise as is.

Anyone with any bandwidth who wants me to try any fixes just let me know. I'll 
probably be working on this off and on as time passes; it may be at the root of 
other test issues too.

> ReplicationFactorTest and HttpPartitionTest both fail with 
> org.apache.http.NoHttpResponseException: The target server failed to respond
> ---
>
> Key: SOLR-6944
> URL: https://issues.apache.org/jira/browse/SOLR-6944
> Project: Solr
>  Issue Type: Test
>Reporter: Mark Miller
>Assignee: Erick Erickson
> Attachments: SOLR-6944.patch, stdout.131, stdout.251, stdout.319, 
> stdout.385, stdout.41
>
>
> Our only recourse is to do a client side retry on such errors. I have some 
> retry code for this from SOLR-4509 that I will pull over here.



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

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

[jira] [Resolved] (SOLR-11380) SolrJ must stream docs to server instead of writing to a byte[] first

[Noble Paul (JIRA)]

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

Noble Paul resolved SOLR-11380.
---
   Resolution: Fixed
Fix Version/s: master (8.0)
   7.2

> SolrJ must stream docs to server instead of writing to a byte[] first 
> --
>
> Key: SOLR-11380
> URL: https://issues.apache.org/jira/browse/SOLR-11380
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Noble Paul
>Assignee: Noble Paul
> Fix For: 7.2, master (8.0)
>
> Attachments: SOLR-11380.patch
>
>




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

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

[jira] [Commented] (SOLR-11380) SolrJ must stream docs to server instead of writing to a byte[] first

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-11380:


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

SOLR-11380: SolrJ must stream docs to server instead of writing to a buffer 
first


> SolrJ must stream docs to server instead of writing to a byte[] first 
> --
>
> Key: SOLR-11380
> URL: https://issues.apache.org/jira/browse/SOLR-11380
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Noble Paul
>Assignee: Noble Paul
> Fix For: 7.2, master (8.0)
>
> Attachments: SOLR-11380.patch
>
>




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

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

[jira] [Comment Edited] (SOLR-11380) SolrJ must stream docs to server instead of writing to a byte[] first

[Noble Paul (JIRA)]

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

Noble Paul edited comment on SOLR-11380 at 10/31/17 4:14 AM:
-

The {{if (contentStream\[0\] instanceof RequestWriter.LazyContentStream)}} 
check is done because the payload size cannot be determined ahead of time. The 
{{ContentStream}} interface is not suitable to generate and write content 
just-in-time. The new {{ContentWriter}} interface is similar to our 
{{QueryResponseWriter}} interface.  


was (Author: noble.paul):
The {{ if (contentStream\[0\]  instanceof RequestWriter.LazyContentStream)}} 
check is done because the payload size cannot be determined ahead of time. The 
{{ContentStream}} interface is not suitable to generate and write content 
just-in-time. The new {{ContentWriter}} interface is similar to our 
{{QueryResponseWriter}} interface.  

> SolrJ must stream docs to server instead of writing to a byte[] first 
> --
>
> Key: SOLR-11380
> URL: https://issues.apache.org/jira/browse/SOLR-11380
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Noble Paul
>Assignee: Noble Paul
> Attachments: SOLR-11380.patch
>
>




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

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

[jira] [Commented] (SOLR-11380) SolrJ must stream docs to server instead of writing to a byte[] first

[Noble Paul (JIRA)]

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

Noble Paul commented on SOLR-11380:
---

The {{ if (contentStream\[0\]  instanceof RequestWriter.LazyContentStream)}} 
check is done because the payload size cannot be determined ahead of time. The 
{{ContentStream}} interface is not suitable to generate and write content 
just-in-time. The new {{ContentWriter}} interface is similar to our 
{{QueryResponseWriter}} interface.  

> SolrJ must stream docs to server instead of writing to a byte[] first 
> --
>
> Key: SOLR-11380
> URL: https://issues.apache.org/jira/browse/SOLR-11380
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Noble Paul
>Assignee: Noble Paul
> Attachments: SOLR-11380.patch
>
>




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

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

[jira] [Commented] (SOLR-11380) SolrJ must stream docs to server instead of writing to a byte[] first

[David Smiley (JIRA)]

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

David Smiley commented on SOLR-11380:
-

Noble, why does HttpSolrClient check {{if (contentStream\[0\] instanceof 
RequestWriter.LazyContentStream)}} and do the same dozen lines of code for both 
true & false?  This looks like something you had in-progress.

> SolrJ must stream docs to server instead of writing to a byte[] first 
> --
>
> Key: SOLR-11380
> URL: https://issues.apache.org/jira/browse/SOLR-11380
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Noble Paul
>Assignee: Noble Paul
> Attachments: SOLR-11380.patch
>
>




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

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

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

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/20774/
Java: 64bit/jdk-9 -XX:+UseCompressedOops -XX:+UseSerialGC --illegal-access=deny

2 tests failed.
FAILED:  
org.apache.solr.cloud.autoscaling.AutoAddReplicasIntegrationTest.testSimple

Error Message:
Timeout waiting for all live and active

Stack Trace:
java.lang.AssertionError: Timeout waiting for all live and active
at 
__randomizedtesting.SeedInfo.seed([320D9B3B1A72B7AC:ABEBFC53D81637D]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.cloud.autoscaling.AutoAddReplicasIntegrationTest.testSimple(AutoAddReplicasIntegrationTest.java:95)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.base/java.lang.Thread.run(Thread.java:844)


FAILED:  org.apache.solr.search.function.TestFunctionQuery.testLongComparisons

Error Message:
Exception during query

Stack Trace:
java.lang.RuntimeException: Exception during query
at 
__randomizedtesting.SeedInfo.seed([320D9B3B1A72B

[jira] [Commented] (LUCENE-8025) compute avgdl correctly for DOCS_ONLY

[Robert Muir (JIRA)]

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

Robert Muir commented on LUCENE-8025:
-

I added DFI and LM as well, they are the worst case: just fall apart completely 
today for omitTFAP because the bogus sumTotalTF=docFreq makes them lose the 
ability to discriminate term importance too.

> compute avgdl correctly for DOCS_ONLY
> -
>
> Key: LUCENE-8025
> URL: https://issues.apache.org/jira/browse/LUCENE-8025
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Robert Muir
> Attachments: LUCENE-8025.patch
>
>
> Spinoff of LUCENE-8007:
> If you omit term frequencies, we should score as if all tf values were 1. 
> This is the way it worked for e.g. ClassicSimilarity and you can understand 
> how it degrades. 
> However for sims such as BM25, we bail out on computing avg doclength (and 
> just return a bogus value of 1) today, screwing up stuff related to length 
> normalization too, which is separate.
> Instead of a bogus value, we should substitute sumDocFreq for 
> sumTotalTermFreq (all postings have freq of 1, since you omitted them).



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

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

[jira] [Comment Edited] (LUCENE-8025) compute avgdl correctly for DOCS_ONLY

[Robert Muir (JIRA)]

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

Robert Muir edited comment on LUCENE-8025 at 10/31/17 3:23 AM:
---

I opened this as a separate issue because we may want to backport it. Relevance 
pretty much falls apart in this case today with these sims (except Classic 
which does not use a pivot, hence unchanged). Here are my results on the 
bengali collection (I had it handy from working with the analyzer):

||Sim||Baseline MAP||DOCS_ONLY MAP (master)||DOCS_ONLY MAP (patch)||
|Classic|0.2266|0.1231|0.1231|
|BM25|0.2947|0.0531|0.1390|
|I(ne)B2|0.3074|0.0534|0.1485|
|I(ne)B1|0.2848|0.0529|0.1248|
|PL2|0.2856|0.0148|0.1377|
|LM(dirichlet)|0.2982|0.0035|0.1803|
|DFI(chisquare)|0.2887|0.0035|0.1703|

I can dig up some other datasets to confirm.

edit: updated table with 2 additional sims.


was (Author: rcmuir):
I opened this as a separate issue because we may want to backport it. Relevance 
pretty much falls apart in this case today with these sims (except Classic 
which does not use a pivot, hence unchanged). Here are my results on the 
bengali collection (I had it handy from working with the analyzer):

||Sim||Baseline MAP||DOCS_ONLY MAP (master)||DOCS_ONLY MAP (patch)||
|Classic|0.2266|0.1231|0.1231|
|BM25|0.2947|0.0531|0.1390|
|I(ne)B2|0.3074|0.0534|0.1485|
|I(ne)B1|0.2848|0.0529|0.1248|
|PL2|0.2856|0.0148|0.1377|

I can dig up some other datasets to confirm.

> compute avgdl correctly for DOCS_ONLY
> -
>
> Key: LUCENE-8025
> URL: https://issues.apache.org/jira/browse/LUCENE-8025
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Robert Muir
> Attachments: LUCENE-8025.patch
>
>
> Spinoff of LUCENE-8007:
> If you omit term frequencies, we should score as if all tf values were 1. 
> This is the way it worked for e.g. ClassicSimilarity and you can understand 
> how it degrades. 
> However for sims such as BM25, we bail out on computing avg doclength (and 
> just return a bogus value of 1) today, screwing up stuff related to length 
> normalization too, which is separate.
> Instead of a bogus value, we should substitute sumDocFreq for 
> sumTotalTermFreq (all postings have freq of 1, since you omitted them).



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

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

[jira] [Commented] (LUCENE-8007) Require that codecs always store totalTermFreq, sumDocFreq and sumTotalTermFreq

[Robert Muir (JIRA)]

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

Robert Muir commented on LUCENE-8007:
-

I spun off the bogus calculations into LUCENE-8025 as it seems like a more 
serious issue. But based on what i see there, definitely think we should remove 
these two -1s, they only cause problems. It will also simplify distributed 
stats and so on where you have to special case the situation/makes stuff more 
complex than it needs to be.


> Require that codecs always store totalTermFreq, sumDocFreq and 
> sumTotalTermFreq
> ---
>
> Key: LUCENE-8007
> URL: https://issues.apache.org/jira/browse/LUCENE-8007
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Adrien Grand
> Fix For: master (8.0)
>
> Attachments: LUCENE-8007.patch, LUCENE-8007.patch
>
>
> Javadocs allow codecs to not store some index statistics. Given discussion 
> that occurred on LUCENE-4100, this was mostly implemented this way to support 
> pre-flex codecs. We should now require that all codecs store these statistics.



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

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

[jira] [Updated] (SOLR-10884) Add nodeMatrix Stream Evaluator

[Joel Bernstein (JIRA)]

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

Joel Bernstein updated SOLR-10884:
--
Description: The *nodeMatrix* Stream Evaluator vectorizes the connections 
of the nodes returned by a *nodes()* graph expression. The nodeMatrix can then 
be used for clustering etc...  (was: The *nodeMatrix* Stream Evaluator 
vectorizes the connections in a node-set returned by a *nodes* graph 
expression. The nodeMatrix can then be used for clustering etc...)

> Add nodeMatrix Stream Evaluator
> ---
>
> Key: SOLR-10884
> URL: https://issues.apache.org/jira/browse/SOLR-10884
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
> Fix For: 7.2
>
>
> The *nodeMatrix* Stream Evaluator vectorizes the connections of the nodes 
> returned by a *nodes()* graph expression. The nodeMatrix can then be used for 
> clustering etc...



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

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

[jira] [Updated] (SOLR-10884) Add nodeMatrix Stream Evaluator

[Joel Bernstein (JIRA)]

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

Joel Bernstein updated SOLR-10884:
--
Description: The *nodeMatrix* Stream Evaluator vectorizes the connections 
in a node-set returned by a *nodes* graph expression. The nodeMatrix can then 
be used for clustering etc...  (was: The *nodeMatrix* Stream Evaluator 
vectorizes the connections in a node set returned by a *nodes* graph 
expression. The nodeMatrix can then be used for clustering etc...)

> Add nodeMatrix Stream Evaluator
> ---
>
> Key: SOLR-10884
> URL: https://issues.apache.org/jira/browse/SOLR-10884
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
> Fix For: 7.2
>
>
> The *nodeMatrix* Stream Evaluator vectorizes the connections in a node-set 
> returned by a *nodes* graph expression. The nodeMatrix can then be used for 
> clustering etc...



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

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

[jira] [Assigned] (SOLR-10884) Add nodeMatrix Stream Evaluator

[Joel Bernstein (JIRA)]

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

Joel Bernstein reassigned SOLR-10884:
-

Assignee: Joel Bernstein

> Add nodeMatrix Stream Evaluator
> ---
>
> Key: SOLR-10884
> URL: https://issues.apache.org/jira/browse/SOLR-10884
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
> Fix For: 7.2
>
>
> The *nodeMatrix* Stream Evaluator vectorizes the connections in a node set 
> returned by a *nodes* graph expression. The nodeMatrix can then be used for 
> clustering etc...



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

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

[jira] [Updated] (SOLR-10884) Add nodeMatrix Stream Evaluator

[Joel Bernstein (JIRA)]

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

Joel Bernstein updated SOLR-10884:
--
Description: The *nodeMatrix* Stream Evaluator vectorizes the connections 
in a node set returned by a *nodes* graph expression. The nodeMatrix can then 
be used for clustering etc...  (was: The *nodeVectors* Stream Evaluator 
vectorizes the connections in a node set returned by a gatherNodes expression. 
The nodeVectors can then be clustered. This will cluster nodes based on their 
connections in a graph.)

> Add nodeMatrix Stream Evaluator
> ---
>
> Key: SOLR-10884
> URL: https://issues.apache.org/jira/browse/SOLR-10884
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
> Fix For: 7.2
>
>
> The *nodeMatrix* Stream Evaluator vectorizes the connections in a node set 
> returned by a *nodes* graph expression. The nodeMatrix can then be used for 
> clustering etc...



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

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

[jira] [Updated] (SOLR-10884) Add nodeMatrix Stream Evaluator

[Joel Bernstein (JIRA)]

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

Joel Bernstein updated SOLR-10884:
--
Fix Version/s: 7.2

> Add nodeMatrix Stream Evaluator
> ---
>
> Key: SOLR-10884
> URL: https://issues.apache.org/jira/browse/SOLR-10884
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
> Fix For: 7.2
>
>
> The *nodeMatrix* Stream Evaluator vectorizes the connections in a node set 
> returned by a *nodes* graph expression. The nodeMatrix can then be used for 
> clustering etc...



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

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

[jira] [Updated] (SOLR-10884) Add nodeMatrix Stream Evaluator

[Joel Bernstein (JIRA)]

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

Joel Bernstein updated SOLR-10884:
--
Summary: Add nodeMatrix Stream Evaluator  (was: Add nodeVectors Stream 
Evaluator)

> Add nodeMatrix Stream Evaluator
> ---
>
> Key: SOLR-10884
> URL: https://issues.apache.org/jira/browse/SOLR-10884
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
>
> The *nodeVectors* Stream Evaluator vectorizes the connections in a node set 
> returned by a gatherNodes expression. The nodeVectors can then be clustered. 
> This will cluster nodes based on their connections in a graph.



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

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

[jira] [Commented] (SOLR-11380) SolrJ must stream docs to server instead of writing to a byte[] first

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-11380:


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

SOLR-11380: SolrJ must stream docs to server instead of writing to a buffer 
first


> SolrJ must stream docs to server instead of writing to a byte[] first 
> --
>
> Key: SOLR-11380
> URL: https://issues.apache.org/jira/browse/SOLR-11380
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Noble Paul
>Assignee: Noble Paul
> Attachments: SOLR-11380.patch
>
>




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

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

[jira] [Updated] (LUCENE-8025) compute avgdl correctly for DOCS_ONLY

[Robert Muir (JIRA)]

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

Robert Muir updated LUCENE-8025:

Attachment: LUCENE-8025.patch

patch. it falls back to the bogus value only if sumDocFreq is unavailable, 
which doesn't happen with any codecs since lucene 4 or so.

note for SimilarityBase it doesn't just correct avgdl but also the 
numberOfFieldTokens, which was previously (bogusly) set to docFreq as if the 
term being scored was the only one in the collection! I will update tests 
across more sims such as LM and DFI that are sensitive to this to see any 
improvement.

> compute avgdl correctly for DOCS_ONLY
> -
>
> Key: LUCENE-8025
> URL: https://issues.apache.org/jira/browse/LUCENE-8025
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Robert Muir
> Attachments: LUCENE-8025.patch
>
>
> Spinoff of LUCENE-8007:
> If you omit term frequencies, we should score as if all tf values were 1. 
> This is the way it worked for e.g. ClassicSimilarity and you can understand 
> how it degrades. 
> However for sims such as BM25, we bail out on computing avg doclength (and 
> just return a bogus value of 1) today, screwing up stuff related to length 
> normalization too, which is separate.
> Instead of a bogus value, we should substitute sumDocFreq for 
> sumTotalTermFreq (all postings have freq of 1, since you omitted them).



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

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

[jira] [Updated] (SOLR-11380) SolrJ must stream docs to server instead of writing to a byte[] first

[Noble Paul (JIRA)]

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

Noble Paul updated SOLR-11380:
--
Issue Type: Improvement  (was: Bug)

> SolrJ must stream docs to server instead of writing to a byte[] first 
> --
>
> Key: SOLR-11380
> URL: https://issues.apache.org/jira/browse/SOLR-11380
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Noble Paul
>Assignee: Noble Paul
> Attachments: SOLR-11380.patch
>
>




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

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

[jira] [Commented] (LUCENE-8025) compute avgdl correctly for DOCS_ONLY

[Robert Muir (JIRA)]

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

Robert Muir commented on LUCENE-8025:
-

I opened this as a separate issue because we may want to backport it. Relevance 
pretty much falls apart in this case today with these sims (except Classic 
which does not use a pivot, hence unchanged). Here are my results on the 
bengali collection (I had it handy from working with the analyzer):

||Sim||Baseline MAP||DOCS_ONLY MAP (master)||DOCS_ONLY MAP (patch)||
|Classic|0.2266|0.1231|0.1231|
|BM25|0.2947|0.0531|0.1390|
|I(ne)B2|0.3074|0.0534|0.1485|
|I(ne)B1|0.2848|0.0529|0.1248|
|PL2|0.2856|0.0148|0.1377|

I can dig up some other datasets to confirm.

> compute avgdl correctly for DOCS_ONLY
> -
>
> Key: LUCENE-8025
> URL: https://issues.apache.org/jira/browse/LUCENE-8025
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Robert Muir
>
> Spinoff of LUCENE-8007:
> If you omit term frequencies, we should score as if all tf values were 1. 
> This is the way it worked for e.g. ClassicSimilarity and you can understand 
> how it degrades. 
> However for sims such as BM25, we bail out on computing avg doclength (and 
> just return a bogus value of 1) today, screwing up stuff related to length 
> normalization too, which is separate.
> Instead of a bogus value, we should substitute sumDocFreq for 
> sumTotalTermFreq (all postings have freq of 1, since you omitted them).



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

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

[jira] [Created] (LUCENE-8025) compute avgdl correctly for DOCS_ONLY

[Robert Muir (JIRA)]

Robert Muir created LUCENE-8025:
---

 Summary: compute avgdl correctly for DOCS_ONLY
 Key: LUCENE-8025
 URL: https://issues.apache.org/jira/browse/LUCENE-8025
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Robert Muir


Spinoff of LUCENE-8007:

If you omit term frequencies, we should score as if all tf values were 1. This 
is the way it worked for e.g. ClassicSimilarity and you can understand how it 
degrades. 

However for sims such as BM25, we bail out on computing avg doclength (and just 
return a bogus value of 1) today, screwing up stuff related to length 
normalization too, which is separate.

Instead of a bogus value, we should substitute sumDocFreq for sumTotalTermFreq 
(all postings have freq of 1, since you omitted them).




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

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

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

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/707/
Java: 32bit/jdk1.8.0_144 -server -XX:+UseG1GC

1 tests failed.
FAILED:  org.apache.solr.handler.admin.AutoscalingHistoryHandlerTest.testHistory

Error Message:
replica never fully recovered

Stack Trace:
java.lang.AssertionError: replica never fully recovered
at 
__randomizedtesting.SeedInfo.seed([DA0EEED0D7C161CC:B7F24A2D6D899ECB]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.handler.admin.AutoscalingHistoryHandlerTest.waitForRecovery(AutoscalingHistoryHandlerTest.java:303)
at 
org.apache.solr.handler.admin.AutoscalingHistoryHandlerTest.testHistory(AutoscalingHistoryHandlerTest.java:255)
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)




Build Log:
[...truncated 12338 lines...]
   [junit4] Suite: org.apache.solr.handler.admin.AutoscalingHistoryHandlerTest
   [junit4]   2> Creating dataDir

[jira] [Resolved] (SOLR-11576) CollectionsAPIDistributedZkTest.testCollectionsAPI() get failed when query node has stale clusterstate

[Cao Manh Dat (JIRA)]

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

Cao Manh Dat resolved SOLR-11576.
-
   Resolution: Fixed
 Assignee: Cao Manh Dat
Fix Version/s: master (8.0)
   7.2

> CollectionsAPIDistributedZkTest.testCollectionsAPI() get failed when query 
> node has stale clusterstate
> --
>
> Key: SOLR-11576
> URL: https://issues.apache.org/jira/browse/SOLR-11576
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Cao Manh Dat
>Assignee: Cao Manh Dat
> Fix For: 7.2, master (8.0)
>
> Attachments: SOLR-11576.patch
>
>
> From 
> http://jenkins.sarowe.net/job/Lucene-Solr-tests-master/13463/testReport/junit/org.apache.solr.cloud/CollectionsAPIDistributedZkTest/testCollectionsAPI/
> {code}
> org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
> from server at https://127.0.0.1:33695/solr/awhollynewcollection_0: 
> {"awhollynewcollection_0":6}
>   at 
> __randomizedtesting.SeedInfo.seed([C10CAFE495CBEBDE:8979DB5093F8C44B]:0)
>   at 
> org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:626)
>   at 
> org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:253)
>   at 
> org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:242)
>   at 
> org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:483)
>   at 
> org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:413)
>   at 
> org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1086)
>   at 
> org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:867)
> {code}
> The problem here is QueryController (the node who receive the query) has a 
> stale clusterstate. Therefore HttpShardHandler could not find an active 
> replica for querying. 



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

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

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

[Policeman Jenkins Server]

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

1 tests failed.
FAILED:  
org.apache.solr.cloud.CollectionsAPIDistributedZkTest.testCollectionsAPI

Error Message:
Error from server at http://127.0.0.1:33704/solr/awhollynewcollection_0: 
{"awhollynewcollection_0":5}

Stack Trace:
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at http://127.0.0.1:33704/solr/awhollynewcollection_0: 
{"awhollynewcollection_0":5}
at 
__randomizedtesting.SeedInfo.seed([7FDC08545B534090:37A97CE05D606F05]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:626)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:253)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:242)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:483)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:413)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1096)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:875)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:982)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:982)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:982)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:982)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:982)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:808)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:178)
at org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:942)
at 
org.apache.solr.cloud.CollectionsAPIDistributedZkTest.testCollectionsAPI(CollectionsAPIDistributedZkTest.java:460)
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.

[jira] [Updated] (SOLR-11576) CollectionsAPIDistributedZkTest.testCollectionsAPI() get failed when query node has stale clusterstate

[Cao Manh Dat (JIRA)]

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

Cao Manh Dat updated SOLR-11576:

Summary: CollectionsAPIDistributedZkTest.testCollectionsAPI() get failed 
when query node has stale clusterstate  (was: 
CollectionsAPIDistributedZkTest.testCollectionsAPI() failures)

> CollectionsAPIDistributedZkTest.testCollectionsAPI() get failed when query 
> node has stale clusterstate
> --
>
> Key: SOLR-11576
> URL: https://issues.apache.org/jira/browse/SOLR-11576
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Cao Manh Dat
> Attachments: SOLR-11576.patch
>
>
> From 
> http://jenkins.sarowe.net/job/Lucene-Solr-tests-master/13463/testReport/junit/org.apache.solr.cloud/CollectionsAPIDistributedZkTest/testCollectionsAPI/
> {code}
> org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
> from server at https://127.0.0.1:33695/solr/awhollynewcollection_0: 
> {"awhollynewcollection_0":6}
>   at 
> __randomizedtesting.SeedInfo.seed([C10CAFE495CBEBDE:8979DB5093F8C44B]:0)
>   at 
> org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:626)
>   at 
> org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:253)
>   at 
> org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:242)
>   at 
> org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:483)
>   at 
> org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:413)
>   at 
> org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1086)
>   at 
> org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:867)
> {code}
> The problem here is QueryController (the node who receive the query) has a 
> stale clusterstate. Therefore HttpShardHandler could not find an active 
> replica for querying. 



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

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

[jira] [Commented] (SOLR-11576) CollectionsAPIDistributedZkTest.testCollectionsAPI() failures

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-11576:


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

SOLR-11576: CollectionsAPIDistributedZkTest.testCollectionsAPI() get failed 
when query node has stale clusterstate


> CollectionsAPIDistributedZkTest.testCollectionsAPI() failures
> -
>
> Key: SOLR-11576
> URL: https://issues.apache.org/jira/browse/SOLR-11576
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Cao Manh Dat
> Attachments: SOLR-11576.patch
>
>
> From 
> http://jenkins.sarowe.net/job/Lucene-Solr-tests-master/13463/testReport/junit/org.apache.solr.cloud/CollectionsAPIDistributedZkTest/testCollectionsAPI/
> {code}
> org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
> from server at https://127.0.0.1:33695/solr/awhollynewcollection_0: 
> {"awhollynewcollection_0":6}
>   at 
> __randomizedtesting.SeedInfo.seed([C10CAFE495CBEBDE:8979DB5093F8C44B]:0)
>   at 
> org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:626)
>   at 
> org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:253)
>   at 
> org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:242)
>   at 
> org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:483)
>   at 
> org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:413)
>   at 
> org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1086)
>   at 
> org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:867)
> {code}
> The problem here is QueryController (the node who receive the query) has a 
> stale clusterstate. Therefore HttpShardHandler could not find an active 
> replica for querying. 



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

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

[jira] [Commented] (SOLR-11576) CollectionsAPIDistributedZkTest.testCollectionsAPI() failures

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-11576:


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

SOLR-11576: CollectionsAPIDistributedZkTest.testCollectionsAPI() get failed 
when query node has stale clusterstate


> CollectionsAPIDistributedZkTest.testCollectionsAPI() failures
> -
>
> Key: SOLR-11576
> URL: https://issues.apache.org/jira/browse/SOLR-11576
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Cao Manh Dat
> Attachments: SOLR-11576.patch
>
>
> From 
> http://jenkins.sarowe.net/job/Lucene-Solr-tests-master/13463/testReport/junit/org.apache.solr.cloud/CollectionsAPIDistributedZkTest/testCollectionsAPI/
> {code}
> org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
> from server at https://127.0.0.1:33695/solr/awhollynewcollection_0: 
> {"awhollynewcollection_0":6}
>   at 
> __randomizedtesting.SeedInfo.seed([C10CAFE495CBEBDE:8979DB5093F8C44B]:0)
>   at 
> org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:626)
>   at 
> org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:253)
>   at 
> org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:242)
>   at 
> org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:483)
>   at 
> org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:413)
>   at 
> org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1086)
>   at 
> org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:867)
> {code}
> The problem here is QueryController (the node who receive the query) has a 
> stale clusterstate. Therefore HttpShardHandler could not find an active 
> replica for querying. 



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

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

[jira] [Updated] (LUCENE-8024) Remove unnecessary norms.advanceExact check in score()

[Robert Muir (JIRA)]

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

Robert Muir updated LUCENE-8024:

Attachment: LUCENE-8024.patch

Patching changing these cases to:
{code}
boolean found = norms.advanceExact(doc);
assert found;
norm = doSomethingWith(norms.longValue());
{code}

> Remove unnecessary norms.advanceExact check in score()
> --
>
> Key: LUCENE-8024
> URL: https://issues.apache.org/jira/browse/LUCENE-8024
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Robert Muir
> Attachments: LUCENE-8024.patch
>
>
> This should no longer be needed, since the index-time boost is removed, and 
> since sims are no longer asked to score non-existent terms.
> E.g. core tests pass with:
> {noformat}
> --- 
> a/lucene/core/src/java/org/apache/lucene/search/similarities/BM25Similarity.java
> +++ 
> b/lucene/core/src/java/org/apache/lucene/search/similarities/BM25Similarity.java
> @@ -230,11 +230,8 @@ public class BM25Similarity extends Similarity {
>if (norms == null) {
>  norm = k1;
>} else {
> -if (norms.advanceExact(doc)) {
> -  norm = cache[((byte) norms.longValue()) & 0xFF];
> -} else {
> -  norm = cache[0];
> -}
> +norms.advanceExact(doc);
> +norm = cache[((byte) norms.longValue()) & 0xFF];
>}
>return weightValue * (float) (freq / (freq + norm));
>  }
> {noformat}



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

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

[JENKINS] Lucene-Solr-Tests-master - Build # 2137 - Failure

[Apache Jenkins Server]

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

All tests passed

Build Log:
[...truncated 224 lines...]
   [junit4] JVM J2: stdout was not empty, see: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/lucene/build/core/test/temp/junit4-J2-20171031_003234_1394535635647974001236.sysout
   [junit4] >>> JVM J2 emitted unexpected output (verbatim) 
   [junit4] #
   [junit4] # There is insufficient memory for the Java Runtime Environment to 
continue.
   [junit4] # Native memory allocation (mmap) failed to map 66060288 bytes for 
committing reserved memory.
   [junit4] # An error report file with more information is saved as:
   [junit4] # 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/lucene/build/core/test/J2/hs_err_pid15445.log
   [junit4] <<< JVM J2: EOF 

   [junit4] JVM J2: stderr was not empty, see: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/lucene/build/core/test/temp/junit4-J2-20171031_003234_1398266228173309876036.syserr
   [junit4] >>> JVM J2 emitted unexpected output (verbatim) 
   [junit4] Java HotSpot(TM) 64-Bit Server VM warning: INFO: 
os::commit_memory(0xfa98, 66060288, 0) failed; error='Cannot 
allocate memory' (errno=12)
   [junit4] <<< JVM J2: EOF 

[...truncated 3 lines...]
   [junit4] JVM J1: stdout was not empty, see: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/lucene/build/core/test/temp/junit4-J1-20171031_003234_1397781273232471248489.sysout
   [junit4] >>> JVM J1 emitted unexpected output (verbatim) 
   [junit4] #
   [junit4] # There is insufficient memory for the Java Runtime Environment to 
continue.
   [junit4] # Native memory allocation (mmap) failed to map 65536 bytes for 
committing reserved memory.
   [junit4] # An error report file with more information is saved as:
   [junit4] # 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/lucene/build/core/test/J1/hs_err_pid15446.log
   [junit4] #
   [junit4] # Compiler replay data is saved as:
   [junit4] # 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/lucene/build/core/test/J1/replay_pid15446.log
   [junit4] <<< JVM J1: EOF 

   [junit4] JVM J1: stderr was not empty, see: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/lucene/build/core/test/temp/junit4-J1-20171031_003234_1394273289362843267134.syserr
   [junit4] >>> JVM J1 emitted unexpected output (verbatim) 
   [junit4] Java HotSpot(TM) 64-Bit Server VM warning: INFO: 
os::commit_memory(0x7f2280d47000, 65536, 1) failed; error='Cannot allocate 
memory' (errno=12)
   [junit4] <<< JVM J1: EOF 

[...truncated 1037 lines...]
   [junit4] ERROR: JVM J1 ended with an exception, command line: 
/usr/local/asfpackages/java/jdk1.8.0_144/jre/bin/java 
-XX:+HeapDumpOnOutOfMemoryError 
-XX:HeapDumpPath=/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/heapdumps
 -ea -esa -Dtests.prefix=tests -Dtests.seed=4D260B1F82F82316 -Xmx512M 
-Dtests.iters= -Dtests.verbose=false -Dtests.infostream=false 
-Dtests.codec=random -Dtests.postingsformat=random 
-Dtests.docvaluesformat=random -Dtests.locale=random -Dtests.timezone=random 
-Dtests.directory=random -Dtests.linedocsfile=europarl.lines.txt.gz 
-Dtests.luceneMatchVersion=8.0.0 -Dtests.cleanthreads=perMethod 
-Djava.util.logging.config.file=/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/lucene/tools/junit4/logging.properties
 -Dtests.nightly=false -Dtests.weekly=false -Dtests.monster=false 
-Dtests.slow=true -Dtests.asserts=true -Dtests.multiplier=2 -DtempDir=./temp 
-Djava.io.tmpdir=./temp 
-Djunit4.tempDir=/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/lucene/build/core/test/temp
 
-Dcommon.dir=/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/lucene
 
-Dclover.db.dir=/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/lucene/build/clover/db
 
-Djava.security.policy=/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/lucene/tools/junit4/tests.policy
 -Dtests.LUCENE_VERSION=8.0.0 -Djetty.testMode=1 -Djetty.insecurerandom=1 
-Dsolr.directoryFactory=org.apache.solr.core.MockDirectoryFactory 
-Djava.awt.headless=true -Djdk.map.althashing.threshold=0 
-Dtests.src.home=/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master 
-Djava.security.egd=file:/dev/./urandom 
-Djunit4.childvm.cwd=/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/lucene/build/core/test/J1
 -Djunit4.childvm.id=1 -Djunit4.childvm.count=3 -Dtests.leaveTemporary=false 
-Dtests.filterstacks=true 
-Djava.security.manager=org.apache.lucene.util.TestSecurityManager 
-Dfile.encoding=UTF-8 -classpath 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/lucene/build/codecs/classes/java:/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/lucene/build/test-framework/classes/java:/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/lucene/test-framework/lib/junit-4.10.jar:/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Te

[jira] [Comment Edited] (SOLR-11564) Failure in TestFunctionQuery.testFunctions()

[Steve Rowe (JIRA)]

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

Steve Rowe edited comment on SOLR-11564 at 10/31/17 12:55 AM:
--

I committed a fix (but didn't notice that this issue already existed): 

master: http://git-wip-us.apache.org/repos/asf/lucene-solr/commit/84fa17d4
branch_7x: http://git-wip-us.apache.org/repos/asf/lucene-solr/commit/789911d9


was (Author: steve_rowe):
I committed a fix (but didn't notice that this issue already existed): 

http://git-wip-us.apache.org/repos/asf/lucene-solr/commit/84fa17d4

> Failure in TestFunctionQuery.testFunctions()
> 
>
> Key: SOLR-11564
> URL: https://issues.apache.org/jira/browse/SOLR-11564
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Affects Versions: master (8.0)
> Environment: Linux ns-l1 4.10.0-37-generic #41-Ubuntu SMP Fri Oct 6 
> 20:20:37 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
> openjdk version "1.8.0_131"
> OpenJDK Runtime Environment (build 1.8.0_131-8u131-b11-2ubuntu1.17.04.3-b11)
> OpenJDK 64-Bit Server VM (build 25.131-b11, mixed mode)
> Ryzen ThreadRipper 1950x, 48GB ram Samsung Pro PCI.m2 ssd disk.
>Reporter: Gus Heck
>Assignee: Steve Rowe
> Attachments: fail.txt
>
>
> This testsuite is another one I have become 'used to seeing' occasionally in 
> failure lists when I run tests, only to find that it doesn't fail if I re-run 
> run it individually.  In this case it seems that with the following command I 
> get a reproducible failure, but the failure does not occur if the test is run 
> individually, only if the TestFunctionQuery suite is run as a whole. 
> {code}
> ant test  -Dtestcase=TestFunctionQuery  -Dtests.seed=CD96A396443584F7 
> -Dtests.locale=fr-FR -Dtests.timezone=Brazil/DeNoronha -Dtests.asserts=true 
> -Dtests.file.encoding=UTF-8 > fail.txt
> {code}
> for contrast:
> {code}
> ant test  -Dtestcase=TestFunctionQuery -Dtests.method=testFunctions 
> -Dtests.seed=CD96A396443584F7 -Dtests.locale=fr-FR 
> -Dtests.timezone=Brazil/DeNoronha -Dtests.asserts=true 
> -Dtests.file.encoding=UTF-8
> {code}
> passes just fine... note the additional -Dtests.method property.



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

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

[jira] [Resolved] (SOLR-11564) Failure in TestFunctionQuery.testFunctions()

[Steve Rowe (JIRA)]

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

Steve Rowe resolved SOLR-11564.
---
Resolution: Fixed
  Assignee: Steve Rowe

I committed a fix (but didn't notice that this issue already existed): 

http://git-wip-us.apache.org/repos/asf/lucene-solr/commit/84fa17d4

> Failure in TestFunctionQuery.testFunctions()
> 
>
> Key: SOLR-11564
> URL: https://issues.apache.org/jira/browse/SOLR-11564
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Affects Versions: master (8.0)
> Environment: Linux ns-l1 4.10.0-37-generic #41-Ubuntu SMP Fri Oct 6 
> 20:20:37 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
> openjdk version "1.8.0_131"
> OpenJDK Runtime Environment (build 1.8.0_131-8u131-b11-2ubuntu1.17.04.3-b11)
> OpenJDK 64-Bit Server VM (build 25.131-b11, mixed mode)
> Ryzen ThreadRipper 1950x, 48GB ram Samsung Pro PCI.m2 ssd disk.
>Reporter: Gus Heck
>Assignee: Steve Rowe
> Attachments: fail.txt
>
>
> This testsuite is another one I have become 'used to seeing' occasionally in 
> failure lists when I run tests, only to find that it doesn't fail if I re-run 
> run it individually.  In this case it seems that with the following command I 
> get a reproducible failure, but the failure does not occur if the test is run 
> individually, only if the TestFunctionQuery suite is run as a whole. 
> {code}
> ant test  -Dtestcase=TestFunctionQuery  -Dtests.seed=CD96A396443584F7 
> -Dtests.locale=fr-FR -Dtests.timezone=Brazil/DeNoronha -Dtests.asserts=true 
> -Dtests.file.encoding=UTF-8 > fail.txt
> {code}
> for contrast:
> {code}
> ant test  -Dtestcase=TestFunctionQuery -Dtests.method=testFunctions 
> -Dtests.seed=CD96A396443584F7 -Dtests.locale=fr-FR 
> -Dtests.timezone=Brazil/DeNoronha -Dtests.asserts=true 
> -Dtests.file.encoding=UTF-8
> {code}
> passes just fine... note the additional -Dtests.method property.



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

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

[jira] [Commented] (SOLR-10934) create a link+anchor checker for the ref-guide PDF using PDFBox

[Hoss Man (JIRA)]

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

Hoss Man commented on SOLR-10934:
-

I think we'll have to abandon any plans of running a robust link checker on the 
PDF -- or any "single page" output format using the master 
{{SolrRefGuide-all.adoc}} file.  The metadata we need to be confident that 
links/anchors are going where we expect just doesn't exist at that point.

What we _might_ want to consider, is refactoring our build.xml, so that the 
same {{}} task options use to generate the PDF, could 
also be used to generate a bare bones version of the html-site -- ie: not using 
jekyll, just using raw asciidoctor with the "html5" output option.  Then we 
could (in theory) run the same HTML link checking code we currently have 
against that output dir -- just for the purpose of checking the links, not with 
any plan to ever publish it.

That way, we could have something like {{ant precommit}} fail if there are any 
broken links in the ref-guide -- using entirely ivy managed dependencies, w/o 
requiring a local install of ruby/jekyll.

> create a link+anchor checker for the ref-guide PDF using PDFBox
> ---
>
> Key: SOLR-10934
> URL: https://issues.apache.org/jira/browse/SOLR-10934
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Hoss Man
> Attachments: SOLR-10934.patch
>
>
> We currently have CheckLinksAndAnchors.java which is automatically run 
> against the ref-guide HTML as part of the build to use JSoup to find bad 
> links/anchors that asciidoctor doesn't complain about -- but not everyone 
> does/can build the HTML version of the ref-guide sincif we can e it requires 
> manually installing jekyll.
> The PDF build only requires things installed by ivy (via JRuby) and we 
> already have some PDFBox based code in ReducePDFSize.java that operates on 
> this PDF every time it's run -- so if we can find a way to do similar checks 
> using the PDFBox API we could catch these broken links faster.



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

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

[jira] [Comment Edited] (LUCENE-8024) Remove unnecessary norms.advanceExact check in score()

[Robert Muir (JIRA)]

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

Robert Muir edited comment on LUCENE-8024 at 10/31/17 12:42 AM:


It looks dumb to fix this but its hard to reason about 3 cases when only 2 
really exist (norms are omitted or you have a value >= 1 for the doc). This can 
make it more clear there isn't divide by zero issues and other problems related 
to the norm. Zero length is an impossible value, its either missing (which you 
can detect up-front for the entire segment), or its a positive value. 


was (Author: rcmuir):
It looks dumb to fix this but its hard to reason about 3 cases when only 2 
really exist (norms are omitted or you have a value > 1 for the doc). This can 
make it more clear there isn't divide by zero issues and other problems related 
to the norm. Zero length is an impossible value, its either missing (which you 
can detect up-front for the entire segment), or its a positive value. 

> Remove unnecessary norms.advanceExact check in score()
> --
>
> Key: LUCENE-8024
> URL: https://issues.apache.org/jira/browse/LUCENE-8024
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Robert Muir
>
> This should no longer be needed, since the index-time boost is removed, and 
> since sims are no longer asked to score non-existent terms.
> E.g. core tests pass with:
> {noformat}
> --- 
> a/lucene/core/src/java/org/apache/lucene/search/similarities/BM25Similarity.java
> +++ 
> b/lucene/core/src/java/org/apache/lucene/search/similarities/BM25Similarity.java
> @@ -230,11 +230,8 @@ public class BM25Similarity extends Similarity {
>if (norms == null) {
>  norm = k1;
>} else {
> -if (norms.advanceExact(doc)) {
> -  norm = cache[((byte) norms.longValue()) & 0xFF];
> -} else {
> -  norm = cache[0];
> -}
> +norms.advanceExact(doc);
> +norm = cache[((byte) norms.longValue()) & 0xFF];
>}
>return weightValue * (float) (freq / (freq + norm));
>  }
> {noformat}



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

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

[jira] [Commented] (LUCENE-8024) Remove unnecessary norms.advanceExact check in score()

[Robert Muir (JIRA)]

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

Robert Muir commented on LUCENE-8024:
-

It looks dumb to fix this but its hard to reason about 3 cases when only 2 
really exist (norms are omitted or you have a value > 1 for the doc). This can 
make it more clear there isn't divide by zero issues and other problems related 
to the norm. Zero length is an impossible value, its either missing (which you 
can detect up-front for the entire segment), or its a positive value. 

> Remove unnecessary norms.advanceExact check in score()
> --
>
> Key: LUCENE-8024
> URL: https://issues.apache.org/jira/browse/LUCENE-8024
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Robert Muir
>
> This should no longer be needed, since the index-time boost is removed, and 
> since sims are no longer asked to score non-existent terms.
> E.g. core tests pass with:
> {noformat}
> --- 
> a/lucene/core/src/java/org/apache/lucene/search/similarities/BM25Similarity.java
> +++ 
> b/lucene/core/src/java/org/apache/lucene/search/similarities/BM25Similarity.java
> @@ -230,11 +230,8 @@ public class BM25Similarity extends Similarity {
>if (norms == null) {
>  norm = k1;
>} else {
> -if (norms.advanceExact(doc)) {
> -  norm = cache[((byte) norms.longValue()) & 0xFF];
> -} else {
> -  norm = cache[0];
> -}
> +norms.advanceExact(doc);
> +norm = cache[((byte) norms.longValue()) & 0xFF];
>}
>return weightValue * (float) (freq / (freq + norm));
>  }
> {noformat}



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

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

[jira] [Resolved] (LUCENE-8020) Don't force sim to score bogus terms (e.g. docfreq=0)

[Robert Muir (JIRA)]

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

Robert Muir resolved LUCENE-8020.
-
Resolution: Fixed

I spun off LUCENE-8023 and LUCENE-8024 to simplify sim impls.

> Don't force sim to score bogus terms (e.g. docfreq=0)
> -
>
> Key: LUCENE-8020
> URL: https://issues.apache.org/jira/browse/LUCENE-8020
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Robert Muir
> Attachments: LUCENE-8020.patch, LUCENE-8020.patch, LUCENE-8020.patch
>
>
> Today all sim formulas have to be "hacked" to deal with the fact that they 
> may be passed stats such as docFreq=0, totalTermFreq=0. This happens easily 
> with spans and there is even a dedicated test for it. All formulas have hacks 
> such as what you see in https://issues.apache.org/jira/browse/LUCENE-6818:
> Instead of:
> {code}
> expected = stats.getTotalTermFreq() * docLen / stats.getNumberOfFieldTokens();
> {code}
> they must do tricks such as:
> {code}
> expected = (1 + stats.getTotalTermFreq()) * docLen / (1 + 
> stats.getNumberOfFieldTokens());
> {code}
> There is no good reason for this, it is just sloppiness in the 
> Query/Weight/Scorer api. I think formulas should work unmodified, we 
> shouldn't pass terms that dont exist or bogus statistics.
> It adds a lot of complexity to the scoring api and makes it difficult to have 
> meaningful/useful explanations, to debug problems, etc. It also makes it 
> really hard to add a new sim.



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

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

[jira] [Created] (LUCENE-8024) Remove unnecessary norms.advanceExact check in score()

[Robert Muir (JIRA)]

Robert Muir created LUCENE-8024:
---

 Summary: Remove unnecessary norms.advanceExact check in score()
 Key: LUCENE-8024
 URL: https://issues.apache.org/jira/browse/LUCENE-8024
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Robert Muir


This should no longer be needed, since the index-time boost is removed, and 
since sims are no longer asked to score non-existent terms.

E.g. core tests pass with:
{noformat}
--- 
a/lucene/core/src/java/org/apache/lucene/search/similarities/BM25Similarity.java
+++ 
b/lucene/core/src/java/org/apache/lucene/search/similarities/BM25Similarity.java
@@ -230,11 +230,8 @@ public class BM25Similarity extends Similarity {
   if (norms == null) {
 norm = k1;
   } else {
-if (norms.advanceExact(doc)) {
-  norm = cache[((byte) norms.longValue()) & 0xFF];
-} else {
-  norm = cache[0];
-}
+norms.advanceExact(doc);
+norm = cache[((byte) norms.longValue()) & 0xFF];
   }
   return weightValue * (float) (freq / (freq + norm));
 }
{noformat}



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

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

[jira] [Updated] (SOLR-10934) create a link+anchor checker for the ref-guide PDF using PDFBox

[Hoss Man (JIRA)]

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

Hoss Man updated SOLR-10934:

Attachment: SOLR-10934.patch



Ok, I'm attaching a really rough and dirty patch that includes:

* A quick and dirty CheckPDFLinksAndAnchors inspired by the SO post mentioned 
and the original PrintURLs.java demo from pdfbox
* a build.xml 'nocommit' target to run it against our PDF
* some "broken" changes to our ref-guide content to deliberatey introduce a few 
errors...
*# anchor duplicated in multiple source pages
*# links to each of the diff dup anchors
*# link to an anchor that doesn't exist in the specified source doc, but does 
exist in a diff doc
*# links to an source doc thta doesn't exist
*# links to an anchor that doesn't exist (in a source doc that does)

The results aren't promising...

# FAIL: the dup anchors cause asciidoctor to print a WARNING (even w/o any link 
checking) that i'd forgotten about, but as far as i can tell from my 
exploration of the {{PDDocumentCatalog}} that duplicated information is lost in 
the underlying PDF (or if it does make it into the PDF, PDFBox loses it when 
parsing the PDF, because the "Catalog" is just a Map)
# FAIL: the PDF Annotations to each of the dup links both wind up mapping to 
the page with the first occurange -- again: either because the catalog in the 
file can only track one location for a given anchor, or because that's just how 
PDF Box deals with the precedence of dup dict keys when reading the file
# FAIL: if an anchor doesn't exist in the specified source {{\*.adoc}} file, 
but does exist somehwere else in the final PDF, then that's where asciidoctor 
points the generated link -- there's nothing weird about it i can detect from 
PDFBox
# GOOD: link's to a source {{\*.adoc}} file that doesn't actaully exist on disk 
are fairly easy to detect -- asciidoctor's default behavior is to assume that 
these are links to other docs that will be converted seperately, so they show 
up as "relative URIs" which we can treat as a failure (ie: if a link in a PDF 
is to a non-absolute URI, it must be a content error)
# GOOD: link's to an anchor that doesn't exist are likewise easy to identify: 
the "annotation" is preserved but has no destiation, which we can treat as a 
failure.

The important bits of the output w/this patch are included below...

{noformat}
-build-raw-pdf:
[asciidoctor:convert] Render SolrRefGuide-all.adoc from 
/home/hossman/lucene/dev/solr/build/solr-ref-guide/content/pdf to 
/home/hossman/lucene/dev/solr/build/solr-ref-guide/pdf-tmp with backend=pdf
[asciidoctor:convert] asciidoctor: ERROR: about-this-guide.adoc: line 1: 
invalid part, must have at least one section (e.g., chapter, appendix, etc.)
[asciidoctor:convert] asciidoctor: ERROR: solr-glossary.adoc: line 1: invalid 
part, must have at least one section (e.g., chapter, appendix, etc.)
[asciidoctor:convert] asciidoctor: WARNING: errata.adoc: line 30: id assigned 
to section already in use: nocommit_dup_anchor_name
[asciidoctor:convert] asciidoctor: ERROR: SolrRefGuide-all.adoc: line 37: 
invalid part, must have at least one section (e.g., chapter, appendix, etc.)
 [move] Moving 1 file to 
/home/hossman/lucene/dev/solr/build/solr-ref-guide/pdf-tmp
...
nocommit:
 [java] Page 753:'Link to bogus page @ anchor that does not exist'=> BOGUS 
URI: nocommit_bogus_page.pdf#nocommit_bogus_x2
 [java] Page 753:'Link to about @ anchor that does not exist' => link with 
no page dest

{noformat}



All in all these results are disappointing.

The "Single Page" output behavior of asciidoctor, combined with the "bugs" in 
asciidoctors handling of duplicated anchors in page includes, combined with the 
underlying structure of the PDF, make it really hard to find the same types of 
failures we can find when parsing the jekyll generated pages using our 
white-box knowledge of "there must be no dup anchors across all pages"


> create a link+anchor checker for the ref-guide PDF using PDFBox
> ---
>
> Key: SOLR-10934
> URL: https://issues.apache.org/jira/browse/SOLR-10934
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Hoss Man
> Attachments: SOLR-10934.patch
>
>
> We currently have CheckLinksAndAnchors.java which is automatically run 
> against the ref-guide HTML as part of the build to use JSoup to find bad 
> links/anchors that asciidoctor doesn't complain about -- but not everyone 
> does/can build the HTML version of the ref-guide sincif we can e it requires 
> manually installing jekyll.
> The PDF build only requires things installed by ivy (via JRuby) and we 
> already have some PDFBox based code in ReducePDFSize.java that operates on 
> this PDF every t

[jira] [Commented] (LUCENE-8020) Don't force sim to score bogus terms (e.g. docfreq=0)

[ASF subversion and git services (JIRA)]

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

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

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

LUCENE-8020: don't force sim to score bogus terms (e.g. docfreq=0)


> Don't force sim to score bogus terms (e.g. docfreq=0)
> -
>
> Key: LUCENE-8020
> URL: https://issues.apache.org/jira/browse/LUCENE-8020
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Robert Muir
> Attachments: LUCENE-8020.patch, LUCENE-8020.patch, LUCENE-8020.patch
>
>
> Today all sim formulas have to be "hacked" to deal with the fact that they 
> may be passed stats such as docFreq=0, totalTermFreq=0. This happens easily 
> with spans and there is even a dedicated test for it. All formulas have hacks 
> such as what you see in https://issues.apache.org/jira/browse/LUCENE-6818:
> Instead of:
> {code}
> expected = stats.getTotalTermFreq() * docLen / stats.getNumberOfFieldTokens();
> {code}
> they must do tricks such as:
> {code}
> expected = (1 + stats.getTotalTermFreq()) * docLen / (1 + 
> stats.getNumberOfFieldTokens());
> {code}
> There is no good reason for this, it is just sloppiness in the 
> Query/Weight/Scorer api. I think formulas should work unmodified, we 
> shouldn't pass terms that dont exist or bogus statistics.
> It adds a lot of complexity to the scoring api and makes it difficult to have 
> meaningful/useful explanations, to debug problems, etc. It also makes it 
> really hard to add a new sim.



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

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

[JENKINS] Solr-Artifacts-master - Build # 3205 - Failure

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Solr-Artifacts-master/3205/

No tests ran.

Build Log:
[...truncated 7959 lines...]
  [javadoc] # There is insufficient memory for the Java Runtime Environment to 
continue.
  [javadoc] # Native memory allocation (mmap) failed to map 3145728 bytes for 
committing reserved memory.
  [javadoc] # An error report file with more information is saved as:
  [javadoc] # 
/x1/jenkins/jenkins-slave/workspace/Solr-Artifacts-master/solr/hs_err_pid9883.log

BUILD FAILED
/x1/jenkins/jenkins-slave/workspace/Solr-Artifacts-master/solr/build.xml:549: 
The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Solr-Artifacts-master/solr/build.xml:451: 
The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Solr-Artifacts-master/solr/test-framework/build.xml:97:
 The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Solr-Artifacts-master/lucene/common-build.xml:556:
 The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Solr-Artifacts-master/lucene/common-build.xml:551:
 The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Solr-Artifacts-master/lucene/common-build.xml:782:
 The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Solr-Artifacts-master/lucene/core/build.xml:54:
 The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Solr-Artifacts-master/lucene/common-build.xml:2195:
 Javadoc returned 1

Total time: 8 minutes 31 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
Publishing Javadoc
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any

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

[jira] [Commented] (SOLR-11565) Add unit Stream Evaluator to support unitizing of vectors and matrices

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-11565:


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

SOLR-11565: Add unit Stream Evaluator to support unitizing of vectors


> Add unit Stream Evaluator to support unitizing of vectors and matrices
> --
>
> Key: SOLR-11565
> URL: https://issues.apache.org/jira/browse/SOLR-11565
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
> Fix For: 7.2
>
> Attachments: SOLR-11565.patch
>
>
> This ticket will add the unit Stream Evaluator which returns the unit vector 
> for a numeric vector.
> https://en.wikipedia.org/wiki/Unit_vector



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

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

[jira] [Commented] (SOLR-11565) Add unit Stream Evaluator to support unitizing of vectors and matrices

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-11565:


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

SOLR-11565: Add unit Stream Evaluator to support unitizing of vectors


> Add unit Stream Evaluator to support unitizing of vectors and matrices
> --
>
> Key: SOLR-11565
> URL: https://issues.apache.org/jira/browse/SOLR-11565
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
> Fix For: 7.2
>
> Attachments: SOLR-11565.patch
>
>
> This ticket will add the unit Stream Evaluator which returns the unit vector 
> for a numeric vector.
> https://en.wikipedia.org/wiki/Unit_vector



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

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

[jira] [Updated] (SOLR-11565) Add unit Stream Evaluator to support unitizing of vectors and matrices

[Joel Bernstein (JIRA)]

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

Joel Bernstein updated SOLR-11565:
--
Summary: Add unit Stream Evaluator to support unitizing of vectors and 
matrices  (was: Add unit Stream Evaluator to support unitizing of vectors)

> Add unit Stream Evaluator to support unitizing of vectors and matrices
> --
>
> Key: SOLR-11565
> URL: https://issues.apache.org/jira/browse/SOLR-11565
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
> Fix For: 7.2
>
> Attachments: SOLR-11565.patch
>
>
> This ticket will add the unit Stream Evaluator which returns the unit vector 
> for a numeric vector.
> https://en.wikipedia.org/wiki/Unit_vector



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

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

[jira] [Updated] (SOLR-11565) Add unit Stream Evaluator to support unitizing of vectors

[Joel Bernstein (JIRA)]

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

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

> Add unit Stream Evaluator to support unitizing of vectors
> -
>
> Key: SOLR-11565
> URL: https://issues.apache.org/jira/browse/SOLR-11565
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
> Fix For: 7.2
>
> Attachments: SOLR-11565.patch
>
>
> This ticket will add the unit Stream Evaluator which returns the unit vector 
> for a numeric vector.
> https://en.wikipedia.org/wiki/Unit_vector



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

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

[jira] [Updated] (LUCENE-8023) Remove divide-by-zero formula hacks across sim impls

[Robert Muir (JIRA)]

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

Robert Muir updated LUCENE-8023:

Description: 
Follow-up to LUCENE-8020

With the scoring api no longer passing e.g. docFreq=0 in corner cases such as 
SpanOrQuery, we can revert formula hacks that we added to many similarities. It 
may not be very significant for ranking but it removes confusion and makes it 
possible to have good explain() etc. 

  was:
Follow-up to LUCENE-8020

With the scoring api no longer passing e.g. docFreq=0 in corner cases such as 
SpanOrQuery, we can revert formula hacks that we added to many similarities. It 
may be very significant for ranking but it removes confusion and makes it 
possible to have good explain() etc. 


> Remove divide-by-zero formula hacks across sim impls
> 
>
> Key: LUCENE-8023
> URL: https://issues.apache.org/jira/browse/LUCENE-8023
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Robert Muir
>
> Follow-up to LUCENE-8020
> With the scoring api no longer passing e.g. docFreq=0 in corner cases such as 
> SpanOrQuery, we can revert formula hacks that we added to many similarities. 
> It may not be very significant for ranking but it removes confusion and makes 
> it possible to have good explain() etc. 



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

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

[jira] [Created] (LUCENE-8023) Remove divide-by-zero formula hacks across sim impls

[Robert Muir (JIRA)]

Robert Muir created LUCENE-8023:
---

 Summary: Remove divide-by-zero formula hacks across sim impls
 Key: LUCENE-8023
 URL: https://issues.apache.org/jira/browse/LUCENE-8023
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Robert Muir


Follow-up to LUCENE-8020

With the scoring api no longer passing e.g. docFreq=0 in corner cases such as 
SpanOrQuery, we can revert formula hacks that we added to many similarities. It 
may be very significant for ranking but it removes confusion and makes it 
possible to have good explain() etc. 



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

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

Re: VOTE: Solr Reference Guide for 7.1 (RC1)

[Varun Thacker]

+1

On Mon, Oct 30, 2017 at 2:42 PM, Tomas Fernandez Lobbe 
wrote:

> +1
>
> On Oct 30, 2017, at 2:07 PM, Anshum Gupta  wrote:
>
> I didn’t spend as much time I would’ve liked but overall it looks good to
> me.
>
> +1.
>
> Thanks for doing this Cassandra (and everyone else) !
>
> -Anshum
>
>
>
> On Oct 27, 2017, at 11:59 AM, Cassandra Targett 
> wrote:
>
> Please vote to release the Solr Reference Guide for Solr 7.1.
>
> The artifacts can be downloaded from:
> https://dist.apache.org/repos/dist/dev/lucene/solr/ref-
> guide/apache-solr-ref-guide-7.1-RC1/
>
> $ cat apache-solr-ref-guide-7.1.pdf.sha1
> 4d43f5511ef5645cd344efabab5f04a9db3ce09b  apache-solr-ref-guide-7.1.pdf
>
> The HTML version has also been uploaded:
> https://lucene.apache.org/solr/guide/7_1/
>
> Here's my +1.
>
> Cassandra
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>
>
>

[jira] [Commented] (LUCENE-8007) Require that codecs always store totalTermFreq, sumDocFreq and sumTotalTermFreq

[Robert Muir (JIRA)]

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

Robert Muir commented on LUCENE-8007:
-

Based on this issue, SimilarityBase can be really improved and simplified with 
pseudocode like this:

{code}
long totalTermFreq = termStats.totalTermFreq();
if (totalTermFreq == -1) {
// term frequencies were omitted, so we assume all tf values for the field 
were 1
assert collectionStats.sumTotalTermFreq() == -1;
totalTermFreq = termStats.docFreq(); // appears 1 time per docFreq
sumTotalTermFreq = collectionStats.sumDocFreq(); // number of postings 
where each freq is 1
}
{code}

I think this is better than bogusly setting sumTotalTermFreq to docFreq and 
avgdl to 1 like we do today? It should behave much better for the omitTF case. 

Note that BM25 has the same problem for its avgdl computation too, which should 
also be fixed.

Just makes me wonder if we should reconsider returning -1 for term's 
totalTermFreq and field's sumTotalTermFreq, when we can alternatively 
substitute with docFreq and sumDocFreq and it will be the same values as if we 
actually tracked freqs of 1 and tracked these stats across them for the field? 
And postings lists return 1 as the freq for such cases today so it seems 
consistent and may simplify code like CheckIndex etc as well.

Returning -1 doesn't really provide value, i think its just the codec api 
showing too much of its guts. if you really want to know if freqs were omitted 
for the field (versus all being 1), you can inspect the IndexOptions for that.


> Require that codecs always store totalTermFreq, sumDocFreq and 
> sumTotalTermFreq
> ---
>
> Key: LUCENE-8007
> URL: https://issues.apache.org/jira/browse/LUCENE-8007
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Adrien Grand
> Fix For: master (8.0)
>
> Attachments: LUCENE-8007.patch, LUCENE-8007.patch
>
>
> Javadocs allow codecs to not store some index statistics. Given discussion 
> that occurred on LUCENE-4100, this was mostly implemented this way to support 
> pre-flex codecs. We should now require that all codecs store these statistics.



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

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

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

[Policeman Jenkins Server]

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

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

Error Message:


Stack Trace:
java.lang.AssertionError
at 
__randomizedtesting.SeedInfo.seed([EFD77C463F0B6444:A17CDD0160B41EB7]:0)
at org.junit.Assert.fail(Assert.java:92)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertTrue(Assert.java:54)
at 
org.apache.solr.cloud.CollectionsAPISolrJTest.testCreateWithDefaultConfigSet(CollectionsAPISolrJTest.java:70)
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)




Build Log:
[...truncated 12316 lines...]
   [junit4] Suite: org.apache.solr.cloud.CollectionsAPISolrJTest
   [junit4]   2> 716552 INFO  
(SUITE-CollectionsAPISolrJTest-seed#[EFD77C463F0B6444]-worker) [] 
o.a.s.SolrTestCaseJ4 SecureRandom sanity checks: 
test.sol

[JENKINS] Lucene-Solr-Tests-7.x - Build # 198 - Failure

[Apache Jenkins Server]

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

No tests ran.

Build Log:
[...truncated 7005 lines...]
ERROR: command execution failed.
ERROR: Step ‘Archive the artifacts’ failed: no workspace for 
Lucene-Solr-Tests-7.x #198
ERROR: Step ‘Publish JUnit test result report’ failed: no workspace for 
Lucene-Solr-Tests-7.x #198
ERROR: lucene is offline; cannot locate JDK 1.8 (latest)
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any
ERROR: lucene is offline; cannot locate JDK 1.8 (latest)
ERROR: lucene is offline; cannot locate JDK 1.8 (latest)

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

[jira] [Resolved] (LUCENE-8021) Add AssertingSimilarity

[Robert Muir (JIRA)]

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

Robert Muir resolved LUCENE-8021.
-
   Resolution: Fixed
Fix Version/s: master (8.0)

> Add AssertingSimilarity
> ---
>
> Key: LUCENE-8021
> URL: https://issues.apache.org/jira/browse/LUCENE-8021
> Project: Lucene - Core
>  Issue Type: Test
>Reporter: Robert Muir
> Fix For: master (8.0)
>
> Attachments: LUCENE-8021.patch
>
>
> We can use this to bounds check the incoming parameters and find issues in 
> tests.



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

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

[jira] [Commented] (LUCENE-8021) Add AssertingSimilarity

[ASF subversion and git services (JIRA)]

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

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

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

LUCENE-8021: Add AssertingSimilarity


> Add AssertingSimilarity
> ---
>
> Key: LUCENE-8021
> URL: https://issues.apache.org/jira/browse/LUCENE-8021
> Project: Lucene - Core
>  Issue Type: Test
>Reporter: Robert Muir
> Attachments: LUCENE-8021.patch
>
>
> We can use this to bounds check the incoming parameters and find issues in 
> tests.



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

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

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

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/706/
Java: 64bit/jdk-9 -XX:-UseCompressedOops -XX:+UseG1GC --illegal-access=deny

14 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.analytics.facet.PivotFacetTest

Error Message:
org.apache.solr.common.SolrException: 
http://127.0.0.1:36005/solr/collection1_shard2_replica_n2/

Stack Trace:
java.lang.RuntimeException: org.apache.solr.common.SolrException: 
http://127.0.0.1:36005/solr/collection1_shard2_replica_n2/
at __randomizedtesting.SeedInfo.seed([FACB4F65958E77DC]:0)
at 
org.apache.solr.analytics.SolrAnalyticsTestCase.commitDocs(SolrAnalyticsTestCase.java:91)
at 
org.apache.solr.analytics.facet.PivotFacetTest.populate(PivotFacetTest.java:78)
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$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 
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)
Caused by: org.apache.solr.common.SolrException: 
http://127.0.0.1:36005/solr/collection1_shard2_replica_n2/
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:589)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1008)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:875)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:808)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:178)
at 
org.apache.solr.client.solrj.request.UpdateRequest.commit(UpdateRequest.java:233)
at 
org.apache.solr.analytics.SolrAnalyticsTestCase.commitDocs(SolrAnalyticsTestCase.java:89)
... 24 more
Caused by: 
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at http://127.0.0.1:36005/solr/collection1_shard2_replica_n2: 
Expected mime type application/octet-stream but got application/json. {
  "error":{
"metadata":[
  "error-class","org.apache.solr.common.SolrException",
  "root-error-class","org.apache.solr.common.SolrException"],
"msg":"URLDecoder: Invalid digit (i) in escape (%) pattern",
"code":400}}

at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:590)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:253)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:242)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:483)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:413)
at 
org.apache

[jira] [Commented] (SOLR-11144) Analytics Component Documentation

[Houston Putman (JIRA)]

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

Houston Putman commented on SOLR-11144:
---

[~ctargett], I'm going through the changes now. Thank you for all the help!

I've updated the following and made a pull request:
* Added parameter sections for all of the facet types
* Fixed the example analytics expression, since there was a mistake in one of 
the lines.
* Changed the Strings section in Analytics-expression-sources.adoc to use and 
unordered list instead of an ordered list.
* Changed the Titles of the mismatched pages to reflect their shortnames. (So I 
removed the 'Reference' at the end of each)

[Here is the pull request.|https://github.com/apache/lucene-solr/pull/269]

Did I miss anything? Is there anything else that we need to do?

> Analytics Component Documentation
> -
>
> Key: SOLR-11144
> URL: https://issues.apache.org/jira/browse/SOLR-11144
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Affects Versions: 7.1
>Reporter: Houston Putman
>Assignee: Cassandra Targett
>Priority: Critical
>
> Adding a Solr Reference Guide page for the Analytics Component.



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

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

[GitHub] lucene-solr pull request #269: Added parameter sections for analytics facets...

[HoustonPutman]

GitHub user HoustonPutman opened a pull request:

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

Added parameter sections for analytics facets.

- Added parameter sections for all of the facet types
- Fixed the example analytics expression, since there was a mistake in one 
of the lines.
- Changed the Strings section in Analytics-expression-sources.adoc to use 
and unordered list instead of an ordered list.
- Changed the Titles of the mismatched pages to reflect their shortnames. 
(So I removed the 'Reference' at the end of each)

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

$ git pull https://github.com/HoustonPutman/lucene-solr jira/solr-11144

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

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


commit 9cb5d14496b917a715aeffbf12dc06d8b15277e7
Author: Houston Putman 
Date:   2017-10-30T21:41:32Z

Added parameter sections for analytics facets.




---

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

Re: VOTE: Solr Reference Guide for 7.1 (RC1)

[Tomas Fernandez Lobbe]

+1

> On Oct 30, 2017, at 2:07 PM, Anshum Gupta  wrote:
> 
> I didn’t spend as much time I would’ve liked but overall it looks good to me.
> 
> +1.
> 
> Thanks for doing this Cassandra (and everyone else) !
> 
> -Anshum
> 
> 
> 
>> On Oct 27, 2017, at 11:59 AM, Cassandra Targett > > wrote:
>> 
>> Please vote to release the Solr Reference Guide for Solr 7.1.
>> 
>> The artifacts can be downloaded from:
>> https://dist.apache.org/repos/dist/dev/lucene/solr/ref-guide/apache-solr-ref-guide-7.1-RC1/
>>  
>> 
>> 
>> $ cat apache-solr-ref-guide-7.1.pdf.sha1
>> 4d43f5511ef5645cd344efabab5f04a9db3ce09b  apache-solr-ref-guide-7.1.pdf
>> 
>> The HTML version has also been uploaded:
>> https://lucene.apache.org/solr/guide/7_1/
>> 
>> Here's my +1.
>> 
>> Cassandra
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>> 
> 

Re: VOTE: Solr Reference Guide for 7.1 (RC1)

[Anshum Gupta]

I didn’t spend as much time I would’ve liked but overall it looks good to me.

+1.

Thanks for doing this Cassandra (and everyone else) !

-Anshum



> On Oct 27, 2017, at 11:59 AM, Cassandra Targett  wrote:
> 
> Please vote to release the Solr Reference Guide for Solr 7.1.
> 
> The artifacts can be downloaded from:
> https://dist.apache.org/repos/dist/dev/lucene/solr/ref-guide/apache-solr-ref-guide-7.1-RC1/
> 
> $ cat apache-solr-ref-guide-7.1.pdf.sha1
> 4d43f5511ef5645cd344efabab5f04a9db3ce09b  apache-solr-ref-guide-7.1.pdf
> 
> The HTML version has also been uploaded:
> https://lucene.apache.org/solr/guide/7_1/
> 
> Here's my +1.
> 
> Cassandra
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
> 



signature.asc
Description: Message signed with OpenPGP

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

[Policeman Jenkins Server]

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

1 tests failed.
FAILED:  org.apache.solr.update.TestInPlaceUpdatesDistrib.test

Error Message:
There are still nodes recoverying - waited for 330 seconds

Stack Trace:
java.lang.AssertionError: There are still nodes recoverying - waited for 330 
seconds
at 
__randomizedtesting.SeedInfo.seed([B1D71C0FC9E4E3E6:398323D567188E1E]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:185)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:140)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:135)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.waitForRecoveriesToFinish(AbstractFullDistribZkTestBase.java:902)
at 
org.apache.solr.update.TestInPlaceUpdatesDistrib.test(TestInPlaceUpdatesDistrib.java:121)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:993)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:968)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org

Re: Solr DistributedUpdateProcessor complexity

[David Smiley]

Hoss: Thanks very much for your insight!  Hmmm; this seems tractable.  It
could probably be addressed with a "urp phase" enum of sorts... and then
splitting the DURP into some pieces that honor certain phases.  I'm just
thinking out loud here... I don't think I have time to undertake a large
refactoring of this magnitude any way.

Do you know if DURP has functionality that can be used without SolrCloud
other than the atomic updates feature?

On Sun, Oct 29, 2017 at 4:53 PM Chris Hostetter 
wrote:

>
> : DistributedUpdateProcessor (or what I call DURP for short) is very
> : complex.  One aspect of the complexity is that it appears it tries to
> : support SolrCloud and classic Solr.  Do we still need it to support
> classic
> : Solr?  When/why?  Forever?
>
> Part of the issue here is that DUP is responsible for applying atomic
> update operations regardless of wehter here is any actual "distribtued"
> updating happening -- because it has to be in cloud mode in order to
> ensure the atomic updates happen exactly once on the leader.
>
> that's the fundemental reason the UpdateProcessorChain can't just "optmize
> away" the need for DUP in non-cloud use cases and let the DUP
> internals just assert "zkEnabled" in all cases
>
> As far as the broader question of: "Do we still need it to support classic
> Solr?  When/why?  Forever?" ... that feels like a much more significant
> question that warrants it's own thread/jira with a very clear subject
> since it's a much bigger/broader topic of cnversation (with a much
> greater impact on user experience) then just a dicussion of the
> (internal) complexity involved in DistributedUpdateProcessor.
>
>
> -Hoss
> http://www.lucidworks.com/
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
> --
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
http://www.solrenterprisesearchserver.com

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

[Apache Jenkins Server]

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

No tests ran.

Build Log:
[...truncated 28018 lines...]
prepare-release-no-sign:
[mkdir] Created dir: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/lucene/build/smokeTestRelease/dist
 [copy] Copying 476 files to 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/lucene/build/smokeTestRelease/dist/lucene
 [copy] Copying 215 files to 
/x1/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] NOTE: output encoding is UTF-8
   [smoker] 
   [smoker] Load release URL 
"file:/x1/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.05 sec (4.6 MB/sec)
   [smoker]   check changes HTML...
   [smoker]   download lucene-7.2.0-src.tgz...
   [smoker] 31.2 MB in 0.14 sec (223.7 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download lucene-7.2.0.tgz...
   [smoker] 69.6 MB in 0.10 sec (670.6 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download lucene-7.2.0.zip...
   [smoker] 80.0 MB in 0.34 sec (234.8 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   unpack lucene-7.2.0.tgz...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] test demo with 1.8...
   [smoker]   got 6221 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] check Lucene's javadoc JAR
   [smoker]   unpack lucene-7.2.0.zip...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] test demo with 1.8...
   [smoker]   got 6221 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] check Lucene's javadoc JAR
   [smoker]   unpack lucene-7.2.0-src.tgz...
   [smoker] make sure no JARs/WARs in src dist...
   [smoker] run "ant validate"
   [smoker] run tests w/ Java 8 and testArgs='-Dtests.slow=false'...
   [smoker] test demo with 1.8...
   [smoker]   got 213 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] generate javadocs w/ Java 8...
   [smoker] 
   [smoker] Crawl/parse...
   [smoker] 
   [smoker] Verify...
   [smoker]   confirm all releases have coverage in TestBackwardsCompatibility
   [smoker] find all past Lucene releases...
   [smoker] run TestBackwardsCompatibility..
   [smoker] success!
   [smoker] 
   [smoker] Test Solr...
   [smoker]   test basics...
   [smoker]   get KEYS
   [smoker] 0.2 MB in 0.02 sec (14.4 MB/sec)
   [smoker]   check changes HTML...
   [smoker]   download solr-7.2.0-src.tgz...
   [smoker] 53.0 MB in 1.54 sec (34.4 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download solr-7.2.0.tgz...
   [smoker] 145.5 MB in 4.16 sec (35.0 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download solr-7.2.0.zip...
   [smoker] 146.5 MB in 2.30 sec (63.8 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   unpack solr-7.2.0.tgz...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] unpack lucene-7.2.0.tgz...
   [smoker]   **WARNING**: skipping check of 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/lucene/build/smokeTestRelease/tmp/unpack/solr-7.2.0/contrib/dataimporthandler-extras/lib/javax.mail-1.5.1.jar:
 it has javax.* classes
   [smoker]   **WARNING**: skipping check of 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/lucene/build/smokeTestRelease/tmp/unpack/solr-7.2.0/contrib/dataimporthandler-extras/lib/activation-1.1.1.jar:
 it has javax.* classes
   [smoker] copying unpacked distribution for Java 8 ...
   [smoker] test solr example w/ Java 8...
   [smoker]   start Solr instance 
(log=/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/lucene/build/smokeTestRelease/tmp/unpack/solr-7.2.0-java8/solr-example.log)...
   [smoker] No process found for Solr node running on port 8983
   [smoker]   Running techproducts example on port 8983 from 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/lucene/build/smokeTestRelease/tmp/unpack/solr-7.2.0-java8
   [smoker] Creating Solr home directory 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/lucene/build/smokeTestRelease/tmp/unpack/solr-7.2.0-java8/example/techproducts/solr
   [smoker] 
   [smoker] Starting up Solr on port 8983 using command:
   [smoker] "bin/solr" start -p 8983 -s "example/techproducts/solr"
   [smoker] 
   [smoker] Waiting up to 180 seconds to see Solr running on port 8983 [|]  
 [/]   [-]   [\]   [|]   [/]   [-]   
[\]   [|]   [/]   [-]   [\]   [|]   [/]  


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

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/6985/
Java: 64bit/jdk-9 -XX:+UseCompressedOops -XX:+UseSerialGC --illegal-access=deny

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

Error Message:
Timeout waiting for all live and active

Stack Trace:
java.lang.AssertionError: Timeout waiting for all live and active
at 
__randomizedtesting.SeedInfo.seed([EBAD2DB045234B56:D31E094E62D09F87]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.cloud.autoscaling.AutoAddReplicasIntegrationTest.testSimple(AutoAddReplicasIntegrationTest.java:95)
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 12616 lines...]
   [junit4] Suite: 
org.apache.solr.cloud.autoscaling.AutoAddReplicasIntegrationTest
   [junit4]   2> Creating dataDir: 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\te

[jira] [Commented] (SOLR-11487) Collection Alias metadata for time partitioned collections

[David Smiley (JIRA)]

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

David Smiley commented on SOLR-11487:
-

*Aliases.java*
* cloneAliases: you can probably reduce the LOC a lot here using Java 8 
streams; see https://stackoverflow.com/a/28288729/92186 for similar code
* AFAICT you've changed the storage of the value side of the map of the 
"collections" key to be a List instead of a String (comma delimited).  
But since this map is serialized to JSON and back and stored in ZooKeeper, 
wouldn't this affect compatibility with aliases.json in existing setups?  We 
definitely don't want to break things.  
* It's a shame that getCollectionAliasMap and getCollectionAliasListMap are no 
longer simple getters (albeit with unmodifiable wrappers). I don't think the 
extra code & cost is worth true immutability.  This is internal code.  As a 
compromise, perhaps instead you might consider creating a view that splits the 
comma on the fly only when it's value is asked for?  See Guava 
{{Maps.transformValues()}}.

*ZkStateReader*
* The TODO in "exportAliasToZk" is a real concern; we don't want race 
conditions between various alias modifications to cause some to be 
overridden/ignored.  I think there are two parts to this: firstly use ZK 
versions when reading/writing aliases.json so that we overwrite the version we 
are expecting. This will mean putting the version number in Aliases (see 
DocCollection.zknodeversion for the same idea) whenever we read the aliases.  
Also, if we do need to retry, that retry loop needs to incorporate fetching the 
aliases and doing the modification over again, rather than repeatedly trying in 
vain to save the serialized aliases from when it started.
* In AliasWatcher, the LOG.debug should use "{}" template to avoid possible 
expensive aliases.toString()
* I very much like that you're removing the hot loop and thinking about 
creating abstractions/mechanisms to make it nicer.  But I admit the change here 
with Observer & Observable seem very odd to me.  IMO weird that ZkStateReader 
is an Observer (Observable seems more intuitive -- it has state that can be 
observed) and likewise it's weird that a Watcher is Observable (wouldn't it 
fundamentally be an Observer?).  I think you're trying to chain some existing 
observable stuff which means the Watchers thus become Observable themselves... 
but I don't like the result even if it works.  Perhaps instead, you could have 
a Watcher subclass called ChainableWatcher, and thus remove the need for 
Observable/Observer altogether?  I don't know if it's that simple without 
trying to tackle it myself, but it's at least an idea.


> Collection Alias metadata for time partitioned collections
> --
>
> Key: SOLR-11487
> URL: https://issues.apache.org/jira/browse/SOLR-11487
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Reporter: David Smiley
> Attachments: SOLR_11487.patch, SOLR_11487.patch, SOLR_11487.patch
>
>
> SOLR-11299 outlines an approach to using a collection Alias to refer to a 
> series of collections of a time series. We'll need to store some metadata 
> about these time series collections, such as which field of the document 
> contains the timestamp to route on.
> The current {{/aliases.json}} is a Map with a key {{collection}} which is in 
> turn a Map of alias name strings to a comma delimited list of the collections.
> _If we change the comma delimited list to be another Map to hold the existing 
> list and more stuff, older CloudSolrClient (configured to talk to ZooKeeper) 
> will break_.  Although if it's configured with an HTTP Solr URL then it would 
> not break.  There's also some read/write hassle to worry about -- we may need 
> to continue to read an aliases.json in the older format.
> Alternatively, we could add a new map entry to aliases.json, say, 
> {{collection_metadata}} keyed by alias name?
> Perhaps another very different approach is to attach metadata to the 
> configset in use?



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

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

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

[Policeman Jenkins Server]

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

4 tests failed.
FAILED:  
org.apache.solr.cloud.CdcrBootstrapTest.testBootstrapWithContinousIndexingOnSourceCluster

Error Message:
Document mismatch on target after sync expected:<2000> but was:<1901>

Stack Trace:
java.lang.AssertionError: Document mismatch on target after sync 
expected:<2000> but was:<1901>
at 
__randomizedtesting.SeedInfo.seed([3F6CA6603083910D:EB29ED39D7D522F6]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.failNotEquals(Assert.java:647)
at org.junit.Assert.assertEquals(Assert.java:128)
at org.junit.Assert.assertEquals(Assert.java:472)
at 
org.apache.solr.cloud.CdcrBootstrapTest.testBootstrapWithContinousIndexingOnSourceCluster(CdcrBootstrapTest.java:294)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:748)


FAILED:  org.apache.solr.cloud.CollectionStateForma

[jira] [Resolved] (SOLR-11448) Implement an option in collection commands to wait for command results

[Andrzej Bialecki (JIRA)]

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

Andrzej Bialecki  resolved SOLR-11448.
--
   Resolution: Fixed
Fix Version/s: master (8.0)
   7.2

> Implement an option in collection commands to wait for command results
> --
>
> Key: SOLR-11448
> URL: https://issues.apache.org/jira/browse/SOLR-11448
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: AutoScaling
>Affects Versions: 7.2
>Reporter: Andrzej Bialecki 
>Assignee: Andrzej Bialecki 
> Fix For: 7.2, master (8.0)
>
> Attachments: SOLR-11448.diff
>
>
> In order to reliably track results and impact of executing collection-level 
> commands in the autoscaling framework we need an option to execute the 
> requested operation (eg. move replica) and then wait for the operation 
> results to actually take effect (the replica has been moved AND it became 
> active).
> This is different than executing commands synchronously, in which case the 
> API only waits for the operation itself to be completed (eg. moving the 
> replica succeeded) but it does not wait for the final effects of this 
> operation to take place (eg. the replica becomes active).



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

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

[jira] [Created] (SOLR-11581) NoMergeScheduler ctor should be public for allowing instantiation from SOLR

[Nawab Zada Asad iqbal (JIRA)]

Nawab Zada Asad iqbal created SOLR-11581:


 Summary: NoMergeScheduler ctor should be public for allowing 
instantiation from SOLR
 Key: SOLR-11581
 URL: https://issues.apache.org/jira/browse/SOLR-11581
 Project: Solr
  Issue Type: Improvement
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Nawab Zada Asad iqbal
Priority: Minor


There are scenarios where a SOLR user may want to use NoMergeScheduler. 
However, it is not possible to use it today, since its constructor is private 
and solrconfig.xml requires a Scheduler with public constructor.



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

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

[jira] [Created] (SOLR-11580) With hl=true and fl=id+score, Solr tries to highligh all the results on first call

[Nawab Zada Asad iqbal (JIRA)]

Nawab Zada Asad iqbal created SOLR-11580:


 Summary: With hl=true and fl=id+score, Solr tries to highligh all 
the results on first call
 Key: SOLR-11580
 URL: https://issues.apache.org/jira/browse/SOLR-11580
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
Affects Versions: 6.5
Reporter: Nawab Zada Asad iqbal
Priority: Minor


Normal solr behavior in distributed solr shards is to bring id and score on 
first request and then request full row of results and highlighted fields in 
the second call after sorting the results (on aggregator node). In Solr 6 or 
earlier a change was introduced to skip the second call if fields to return 
only has id and score. However, this misses one edge case when hl=true; and 
asks the shards to highlight all the results on the first call, which is really 
inefficient.



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

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

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

[Apache Jenkins Server]

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

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

Error Message:
KeeperErrorCode = Session expired for /overseer_elect/leader

Stack Trace:
org.apache.zookeeper.KeeperException$SessionExpiredException: KeeperErrorCode = 
Session expired for /overseer_elect/leader
at 
__randomizedtesting.SeedInfo.seed([3A7EC04E2CD5E5BE:B22AFF9482298846]:0)
at org.apache.zookeeper.KeeperException.create(KeeperException.java:127)
at org.apache.zookeeper.KeeperException.create(KeeperException.java:51)
at org.apache.zookeeper.ZooKeeper.getData(ZooKeeper.java:1212)
at 
org.apache.solr.common.cloud.SolrZkClient.lambda$getData$5(SolrZkClient.java:332)
at 
org.apache.solr.common.cloud.ZkCmdExecutor.retryOperation(ZkCmdExecutor.java:60)
at 
org.apache.solr.common.cloud.SolrZkClient.getData(SolrZkClient.java:332)
at 
org.apache.solr.cloud.OverseerTaskProcessor.getLeaderId(OverseerTaskProcessor.java:374)
at 
org.apache.solr.cloud.OverseerTaskProcessor.getLeaderNode(OverseerTaskProcessor.java:365)
at 
org.apache.solr.cloud.RollingRestartTest.waitUntilOverseerDesignateIsLeader(RollingRestartTest.java:137)
at 
org.apache.solr.cloud.RollingRestartTest.restartWithRolesTest(RollingRestartTest.java:104)
at 
org.apache.solr.cloud.RollingRestartTest.test(RollingRestartTest.java:52)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:993)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:968)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(Statem

[jira] [Commented] (SOLR-11461) contrib/ltr to move away from 6.0.0

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-11461:


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

SOLR-11461: change contrib/ltr test-files away from luceneMatchVersion 6.0.0


> contrib/ltr to move away from 6.0.0
> 
>
> Key: SOLR-11461
> URL: https://issues.apache.org/jira/browse/SOLR-11461
> Project: Solr
>  Issue Type: Sub-task
>  Components: contrib - LTR
>Reporter: Christine Poerschke
>Priority: Minor
>
> This ticket is to change the three occurrences of 
> {{6.0.0}} in {{solr/contrib/ltr}} to 
> {{$\{tests.luceneMatchVersion:LATEST\}}}
>  including testing that all the tests still pass.



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

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

[jira] [Commented] (SOLR-10132) Support facet.matches to cull facets returned with a regex

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10132:


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

SOLR-10132: A new optional facet.matches parameter to return facet buckets only 
for terms that match a regular expression. (Gus Heck, Christine Poerschke)


> Support facet.matches to cull facets returned with a regex
> --
>
> Key: SOLR-10132
> URL: https://issues.apache.org/jira/browse/SOLR-10132
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: faceting
>Affects Versions: 6.4.1
>Reporter: Gus Heck
>Assignee: Christine Poerschke
> Attachments: SOLR-10132.patch, SOLR-10132.patch, SOLR-10132.patch, 
> SOLR-10132.patch, SOLR-10132.patch
>
>
> I recently ran into a case where I really wanted to only return the next 
> level of a hierarchical facet, and while I was able to do that with a 
> coordinated set of dynamic fields, it occurred to me that this would have 
> been much much easier if I could have simply used PathHierarchyTokenizer and 
> written
> &facet.matches="/my/current/prefix/[^/]+$"
> thereby limiting the returned facets to the next level down and not return 
> the  additional  N levels I didn't (yet) want to display (numbering in the 
> thousands near the top of the tree). I suspect there are other good use 
> cases, and the patch seemed relatively tractable.



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

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

[jira] [Updated] (SOLR-11579) Building Solr using Java 9 and Maven doesn't work

[Daniel Collins (JIRA)]

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

Daniel Collins updated SOLR-11579:
--
Attachment: SOLR-11579_1
SOLR-11579_2
SOLR-11579_4

Patch 1 is just for the enforcer plugin, patch 2 is for Javadoc, and patch 4 
just updates ALL the plugins to their latest and greatest (it works for me, but 
not sure what other implications of that there are)

> Building Solr using Java 9 and Maven doesn't work
> -
>
> Key: SOLR-11579
> URL: https://issues.apache.org/jira/browse/SOLR-11579
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Build
>Affects Versions: master (8.0)
> Environment: Apache Maven 3.5.0 
> (ff8f5e7444045639af65f6095c62210b5713f426; 2017-04-03T20:39:06+01:00)
> Maven home: /Users/dcollins53/Utils/apache-maven-3.5.0
> Java version: 9, vendor: Oracle Corporation
> Java home: /Library/Java/JavaVirtualMachines/jdk-9.jdk/Contents/Home
> Default locale: en_GB, platform encoding: UTF-8
> OS name: "mac os x", version: "10.12.6", arch: "x86_64", family: "mac"
> java version "9"
> Java(TM) SE Runtime Environment (build 9+181)
> Java HotSpot(TM) 64-Bit Server VM (build 9+181, mixed mode)
>Reporter: Daniel Collins
>Priority: Minor
>  Labels: maven, maven-enforcer-plugin
> Attachments: SOLR-11579_1, SOLR-11579_2, SOLR-11579_4
>
>
> I'm calling this minor as I don't believe we officially support Java 9 (but 
> correct me if I'm wrong), and I've only tried on master (again, I don't 
> *think* branch_7x is setup for Java 9?)
> Several issues/notes:
> # enforcer plugin breaks if you try to do mvn install
> # javadoc plugin breaks if you try to do mvn javadoc:jar
> # warnings from groovy-maven-plugin (TODO)
> # a lot of the maven plugins are quite old
> # forbiddenapis has some issues with Solr (I assume due to module split-up, 
> javax is no longer part of core) (TODO)
> I have patches for 1, 2, and 4. Still working on 3 and 5.



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

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

[JENKINS] Lucene-Solr-master-Linux (64bit/jdk-9) - Build # 20771 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/20771/
Java: 64bit/jdk-9 -XX:-UseCompressedOops -XX:+UseParallelGC 
--illegal-access=deny

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

Error Message:
Property 'testprop' with value true not set correctly for collection/replica 
pair: testcollection/core_node4 property map is 
{core=testcollection_shard1_replica_n1, base_url=https://127.0.0.1:37663/_/d, 
node_name=127.0.0.1:37663__%2Fd, state=active, type=NRT, leader=true, 
property.testprop=true}.

Stack Trace:
java.lang.AssertionError: Property 'testprop' with value true not set correctly 
for collection/replica pair: testcollection/core_node4 property map is 
{core=testcollection_shard1_replica_n1, base_url=https://127.0.0.1:37663/_/d, 
node_name=127.0.0.1:37663__%2Fd, state=active, type=NRT, leader=true, 
property.testprop=true}.
at 
__randomizedtesting.SeedInfo.seed([4A3A7E3D178B53E0:C26E41E7B9773E18]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.ReplicaPropertiesBase.verifyPropertyVal(ReplicaPropertiesBase.java:95)
at 
org.apache.solr.cloud.TestCollectionAPI.replicaPropTest(TestCollectionAPI.java:501)
at 
org.apache.solr.cloud.TestCollectionAPI.test(TestCollectionAPI.java:92)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:993)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:968)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequire

[jira] [Created] (SOLR-11579) Building Solr using Java 9 and Maven doesn't work

[Daniel Collins (JIRA)]

Daniel Collins created SOLR-11579:
-

 Summary: Building Solr using Java 9 and Maven doesn't work
 Key: SOLR-11579
 URL: https://issues.apache.org/jira/browse/SOLR-11579
 Project: Solr
  Issue Type: New Feature
  Security Level: Public (Default Security Level. Issues are Public)
  Components: Build
Affects Versions: master (8.0)
 Environment: Apache Maven 3.5.0 
(ff8f5e7444045639af65f6095c62210b5713f426; 2017-04-03T20:39:06+01:00)
Maven home: /Users/dcollins53/Utils/apache-maven-3.5.0
Java version: 9, vendor: Oracle Corporation
Java home: /Library/Java/JavaVirtualMachines/jdk-9.jdk/Contents/Home
Default locale: en_GB, platform encoding: UTF-8
OS name: "mac os x", version: "10.12.6", arch: "x86_64", family: "mac"

java version "9"
Java(TM) SE Runtime Environment (build 9+181)
Java HotSpot(TM) 64-Bit Server VM (build 9+181, mixed mode)
Reporter: Daniel Collins
Priority: Minor


I'm calling this minor as I don't believe we officially support Java 9 (but 
correct me if I'm wrong), and I've only tried on master (again, I don't *think* 
branch_7x is setup for Java 9?)

Several issues/notes:
# enforcer plugin breaks as soon if you try to do mvn install
# javadoc plugin breaks if you try to do mvn javadoc:jar
# warnings from groovy-maven-plugin (TODO)
# a lot of the maven plugins are quite old
# forbiddenapis has some issues with Solr (I assume due to module split-up, 
javax is no longer part of core) (TODO)

I have patches for 1, 2, and 4. Still working on 3 and 5.




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

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

[jira] [Updated] (SOLR-11579) Building Solr using Java 9 and Maven doesn't work

[Daniel Collins (JIRA)]

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

Daniel Collins updated SOLR-11579:
--
Description: 
I'm calling this minor as I don't believe we officially support Java 9 (but 
correct me if I'm wrong), and I've only tried on master (again, I don't *think* 
branch_7x is setup for Java 9?)

Several issues/notes:
# enforcer plugin breaks if you try to do mvn install
# javadoc plugin breaks if you try to do mvn javadoc:jar
# warnings from groovy-maven-plugin (TODO)
# a lot of the maven plugins are quite old
# forbiddenapis has some issues with Solr (I assume due to module split-up, 
javax is no longer part of core) (TODO)

I have patches for 1, 2, and 4. Still working on 3 and 5.


  was:
I'm calling this minor as I don't believe we officially support Java 9 (but 
correct me if I'm wrong), and I've only tried on master (again, I don't *think* 
branch_7x is setup for Java 9?)

Several issues/notes:
# enforcer plugin breaks as soon if you try to do mvn install
# javadoc plugin breaks if you try to do mvn javadoc:jar
# warnings from groovy-maven-plugin (TODO)
# a lot of the maven plugins are quite old
# forbiddenapis has some issues with Solr (I assume due to module split-up, 
javax is no longer part of core) (TODO)

I have patches for 1, 2, and 4. Still working on 3 and 5.



> Building Solr using Java 9 and Maven doesn't work
> -
>
> Key: SOLR-11579
> URL: https://issues.apache.org/jira/browse/SOLR-11579
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Build
>Affects Versions: master (8.0)
> Environment: Apache Maven 3.5.0 
> (ff8f5e7444045639af65f6095c62210b5713f426; 2017-04-03T20:39:06+01:00)
> Maven home: /Users/dcollins53/Utils/apache-maven-3.5.0
> Java version: 9, vendor: Oracle Corporation
> Java home: /Library/Java/JavaVirtualMachines/jdk-9.jdk/Contents/Home
> Default locale: en_GB, platform encoding: UTF-8
> OS name: "mac os x", version: "10.12.6", arch: "x86_64", family: "mac"
> java version "9"
> Java(TM) SE Runtime Environment (build 9+181)
> Java HotSpot(TM) 64-Bit Server VM (build 9+181, mixed mode)
>Reporter: Daniel Collins
>Priority: Minor
>  Labels: maven, maven-enforcer-plugin
>
> I'm calling this minor as I don't believe we officially support Java 9 (but 
> correct me if I'm wrong), and I've only tried on master (again, I don't 
> *think* branch_7x is setup for Java 9?)
> Several issues/notes:
> # enforcer plugin breaks if you try to do mvn install
> # javadoc plugin breaks if you try to do mvn javadoc:jar
> # warnings from groovy-maven-plugin (TODO)
> # a lot of the maven plugins are quite old
> # forbiddenapis has some issues with Solr (I assume due to module split-up, 
> javax is no longer part of core) (TODO)
> I have patches for 1, 2, and 4. Still working on 3 and 5.



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

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

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

[Policeman Jenkins Server]

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

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

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

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

[jira] [Updated] (SOLR-11291) Adding Solr Core Reporter

[Omar Abdelnabi (JIRA)]

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

Omar Abdelnabi updated SOLR-11291:
--
Attachment: SOLR-11291.patch

This is the updated patch

> Adding Solr Core Reporter
> -
>
> Key: SOLR-11291
> URL: https://issues.apache.org/jira/browse/SOLR-11291
> Project: Solr
>  Issue Type: New Feature
>  Components: metrics
>Reporter: Omar Abdelnabi
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-11291.patch, SOLR-11291.patch
>
>
> Adds a new reporter, SolrCoreReporter, which allows metrics to be reported on 
> per-core basis.
> Also modifies the SolrMetricManager and SolrCoreMetricManager to take 
> advantage of this new reporter.
> Adds a test/example that uses the  SolrCoreReporter. Also adds randomization 
> to SolrCloudReportersTest.



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

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

[jira] [Commented] (SOLR-11566) Add transpose Stream Evaluator to support transposing of matrices

[Joel Bernstein (JIRA)]

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

Joel Bernstein commented on SOLR-11566:
---

Here is the branch_7x commit:
https://github.com/apache/lucene-solr/commit/7cbc297396c7d8b18f519d3c6beddb7df76f94b2

> Add transpose Stream Evaluator to support transposing of matrices
> -
>
> Key: SOLR-11566
> URL: https://issues.apache.org/jira/browse/SOLR-11566
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
> Fix For: 7.2
>
> Attachments: SOLR-11566.patch
>
>
> This ticket adds the transpose Stream Evaluator to support transposing of 
> matrices.



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

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

[jira] [Commented] (SOLR-11566) Add transpose Stream Evaluator to support transposing of matrices

[Joel Bernstein (JIRA)]

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

Joel Bernstein commented on SOLR-11566:
---

This was committed as SEARCH-11566 instead of SOLR-11566. Here is the commit to 
master:
https://github.com/apache/lucene-solr/commit/b7332f65b785ab3007d4c2c482f8e9f11077e9df

> Add transpose Stream Evaluator to support transposing of matrices
> -
>
> Key: SOLR-11566
> URL: https://issues.apache.org/jira/browse/SOLR-11566
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
> Fix For: 7.2
>
> Attachments: SOLR-11566.patch
>
>
> This ticket adds the transpose Stream Evaluator to support transposing of 
> matrices.



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

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

[jira] [Updated] (SOLR-11566) Add transpose Stream Evaluator to support transposing of matrices

[Joel Bernstein (JIRA)]

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

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

> Add transpose Stream Evaluator to support transposing of matrices
> -
>
> Key: SOLR-11566
> URL: https://issues.apache.org/jira/browse/SOLR-11566
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
> Fix For: 7.2
>
> Attachments: SOLR-11566.patch
>
>
> This ticket adds the transpose Stream Evaluator to support transposing of 
> matrices.



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

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

[jira] [Updated] (SOLR-11438) Solr should return rf when min_rf is specified for deletes as well as adds

[Erick Erickson (JIRA)]

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

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

Current patch, I think it's ready.

I reworked a couple of things. It seems easier if I split out the replication 
trackers into a "rollup" and "leader" trackers, these are different roles.

Additionally, rather than accumulate errors and count them, just using a simple 
counter in the LeaderReplicationTracker does the trick.

Adding in the delete-by-id was a pain. Not all requests are forwarded to all 
replicas.

I successfully beasted this test prior to modifications 1,000 times, so I'm 
pretty sure removing the BadApple annotation is OK.

I intend to beast this test another 1,000 times on my Mac Pro and a server. If 
all that goes well I'll commit later today.

precommit and tests pass.

> Solr should return rf when min_rf is specified for deletes as well as adds
> --
>
> Key: SOLR-11438
> URL: https://issues.apache.org/jira/browse/SOLR-11438
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 6.6.1, 7.0, master (8.0)
>Reporter: Erick Erickson
>Assignee: Erick Erickson
> Attachments: SOLR-11438.patch, SOLR-11438.patch
>
>
> When we add documents and specify min_rf we get back an rf parameter in the 
> response which is the number of replicas that successfully received the add. 
> However, for delete-by-id or delete-by-query we do not return this data. Is 
> there any harm in it?
> Assigning to myself to track, anyone else who wants it feel free.



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

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

[jira] [Updated] (SOLR-11438) Solr should return rf when min_rf is specified for deletes as well as adds

[Erick Erickson (JIRA)]

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

Erick Erickson updated SOLR-11438:
--
Summary: Solr should return rf when min_rf is specified for deletes as well 
as adds  (was: Solr should return rf when min_rf is specified for delete-by-id 
and delete-by-query.)

> Solr should return rf when min_rf is specified for deletes as well as adds
> --
>
> Key: SOLR-11438
> URL: https://issues.apache.org/jira/browse/SOLR-11438
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 6.6.1, 7.0, master (8.0)
>Reporter: Erick Erickson
>Assignee: Erick Erickson
> Attachments: SOLR-11438.patch
>
>
> When we add documents and specify min_rf we get back an rf parameter in the 
> response which is the number of replicas that successfully received the add. 
> However, for delete-by-id or delete-by-query we do not return this data. Is 
> there any harm in it?
> Assigning to myself to track, anyone else who wants it feel free.



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

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

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

[Policeman Jenkins Server]

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

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

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

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

[jira] [Commented] (SOLR-11578) Solr 7 Admin UI (Cloud > Graph) should reflect the Replica type to give a more accurate representation of the cluster

[Erick Erickson (JIRA)]

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

Erick Erickson commented on SOLR-11578:
---

WDYT about taking out the legend and instead when you hover over the entry a 
tool top pops up with the type? The first few times you see the legend it'll 
help, but about the third time I see it I don't need it any more ;)

So you'd still have
192.168.1.201 (P)
as the link, just when you hover over it a pop-up appears with the information..

Hmmm, random thought that just popped into my head if it wouldn't be too much 
work; a tooltip/popup with _all_ the node information would be great, i.e. all 
the information from state.json for that replica. Nothing fancy here, just the 
text from the state.json for the node like this.
 "core_node2":{
"core":"eoe12_shard1_replica_n1",
"base_url":"http://192.168.1.201:8981/solr";,
"node_name":"192.168.1.201:8981_solr",
"state":"active",
"type":"NRT",
"leader":"true"},

This would save me endless switching to see the information I see. If at all 
possible it would probably be best if this was generated on the fly (i.e. when 
you hovered your mouse over the link) rather than built up-front. I'm thinking 
of how big the page would get with a zillion replicas. If you do this be sure 
to include core_node2 please ;)




> Solr 7 Admin UI (Cloud > Graph) should reflect the Replica type to give a 
> more accurate representation of the cluster
> -
>
> Key: SOLR-11578
> URL: https://issues.apache.org/jira/browse/SOLR-11578
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Admin UI
>Affects Versions: 7.0, 7.1
>Reporter: Rohit
>Priority: Minor
> Attachments: SOLR-11578.patch, Updated Graph.png, Updated Legend.png, 
> Updated Radial Graph.png
>
>
> New replica types were introduced in Solr 7.
> 1. The Solr Admin UI --> Cloud --> Graph mode should be updated to reflect 
> the new replica types (NRT, TLOG, PULL)
> 2. It will give a better overview of the cluster as well as help in 
> troubleshooting and diagnosing issues.



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

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

[jira] [Updated] (LUCENE-8022) Regression from 6.x version on search with wildcard

[Florent BENOIT (JIRA)]

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

Florent BENOIT updated LUCENE-8022:
---
Summary: Regression from 6.x version on search with wildcard  (was: 
Regression from 6.x version)

> Regression from 6.x version on search with wildcard
> ---
>
> Key: LUCENE-8022
> URL: https://issues.apache.org/jira/browse/LUCENE-8022
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Florent BENOIT
>
> Hello,
> let say I index documents with attribute name like: prefixFileName
> and that I search with "prefixF*", it is not found.
> while searching with "prefix*" it works.
> In 6.x (and 5.x) "prefixF*" was finding the value.
> I've provided a test case
> https://gist.github.com/benoitf/6078a0a8925826d8c89916a78a883cb0
> and a pom.xml file
> https://gist.github.com/benoitf/fefaf174fa4d96c40318dc4d044495b1
> when setting property version in pom.xml to 6.6.2 it works



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

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

[jira] [Created] (LUCENE-8022) Regression from 6.x version

[Florent BENOIT (JIRA)]

Florent BENOIT created LUCENE-8022:
--

 Summary: Regression from 6.x version
 Key: LUCENE-8022
 URL: https://issues.apache.org/jira/browse/LUCENE-8022
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Florent BENOIT


Hello,

let say I index documents with attribute name like: prefixFileName

and that I search with "prefixF*", it is not found.
while searching with "prefix*" it works.

In 6.x (and 5.x) "prefixF*" was finding the value.

I've provided a test case
https://gist.github.com/benoitf/6078a0a8925826d8c89916a78a883cb0

and a pom.xml file
https://gist.github.com/benoitf/fefaf174fa4d96c40318dc4d044495b1

when setting property version in pom.xml to 6.6.2 it works






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

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

Re: [JENKINS] Lucene-Solr-7.x-Solaris (64bit/jdk1.8.0) - Build # 262 - Still unstable!

[Steve Rowe]

I committed a fix.

--
Steve
www.lucidworks.com

> On Oct 28, 2017, at 4:54 AM, Policeman Jenkins Server  
> wrote:
> 
> Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Solaris/262/
> Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseG1GC
> 
> 1 tests failed.
> FAILED:  org.apache.solr.search.function.TestFunctionQuery.testExternalField
> 
> Error Message:
> Exception during query
> 
> Stack Trace:
> java.lang.RuntimeException: Exception during query
>   at 
> __randomizedtesting.SeedInfo.seed([B7AB0D1C7890D78E:9F493DA454A95E1E]:0)
>   at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:885)
>   at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:845)
>   at 
> org.apache.solr.search.function.TestFunctionQuery.singleTest(TestFunctionQuery.java:131)
>   at 
> org.apache.solr.search.function.TestFunctionQuery.singleTest(TestFunctionQuery.java:137)
>   at 
> org.apache.solr.search.function.TestFunctionQuery.testExternalField(TestFunctionQuery.java:221)
>   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)

[jira] [Commented] (SOLR-11003) Enabling bi-directional CDCR on cluster for better failover

[Varun Thacker (JIRA)]

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

Varun Thacker commented on SOLR-11003:
--

bq. 2 shards instead of 1? The only problem / caveat is the test will become 
heavier with two separate clusters running already, I hope it don't introduce 
unnecessary zk-timeouts or such.

We'll find out. But I'd be more comfortable testing with 2 shards instead of 1. 

bq. Also removing CdcrQueue status (it causes no harm though).

Sure then let's keep it then. We can add a code comment clarifying that this is 
only to observe the queue length when the test runs

> Enabling bi-directional CDCR on cluster for better failover
> ---
>
> Key: SOLR-11003
> URL: https://issues.apache.org/jira/browse/SOLR-11003
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: CDCR
>Reporter: Amrit Sarkar
>Assignee: Varun Thacker
> Attachments: SOLR-11003-tlogutils.patch, SOLR-11003.patch, 
> SOLR-11003.patch, SOLR-11003.patch, SOLR-11003.patch, SOLR-11003.patch, 
> SOLR-11003.patch, SOLR-11003.patch, SOLR-11003.patch, SOLR-11003.patch, 
> SOLR-11003.patch, sample-configs.zip
>
>
> The latest version of Solr CDCR across collections / clusters is in 
> active-passive format, where we can index into source collection and the 
> updates gets forwarded to the passive one and vice-versa is not supported.
> https://lucene.apache.org/solr/guide/6_6/cross-data-center-replication-cdcr.html
> https://issues.apache.org/jira/browse/SOLR-6273
> We are try to get a  design ready to index in both collections and the 
> updates gets reflected across the collections in real-time (given the backlog 
> of replicating updates to other data center). ClusterACollectionA => 
> ClusterBCollectionB | ClusterBCollectionB => ClusterACollectionA.
> The STRONG RECOMMENDED way to keep indexing in ClusterACollectionA which 
> forwards the updates to ClusterBCollectionB. If ClusterACollectionA gets 
> down, we point the indexer and searcher application to ClusterBCollectionB. 
> Once ClusterACollectionA is up, depending on updates count, they will be 
> bootstrapped or forwarded to ClusterACollectionA from ClusterBCollectionB and 
> keep indexing on the ClusterBCollectionB.



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

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

[JENKINS] Lucene-Solr-NightlyTests-7.x - Build # 71 - Still Failing

[Apache Jenkins Server]

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

All tests passed

Build Log:
[...truncated 309 lines...]
   [junit4] JVM J1: stdout was not empty, see: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.x/checkout/lucene/build/core/test/temp/junit4-J1-20171030_122842_3971287405914873692104.sysout
   [junit4] >>> JVM J1 emitted unexpected output (verbatim) 
   [junit4] #
   [junit4] # There is insufficient memory for the Java Runtime Environment to 
continue.
   [junit4] # Native memory allocation (mmap) failed to map 35651584 bytes for 
committing reserved memory.
   [junit4] # An error report file with more information is saved as:
   [junit4] # 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.x/checkout/lucene/build/core/test/J1/hs_err_pid12670.log
   [junit4] <<< JVM J1: EOF 

   [junit4] JVM J1: stderr was not empty, see: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.x/checkout/lucene/build/core/test/temp/junit4-J1-20171030_122842_3971334464257233793117.syserr
   [junit4] >>> JVM J1 emitted unexpected output (verbatim) 
   [junit4] Java HotSpot(TM) 64-Bit Server VM warning: INFO: 
os::commit_memory(0xfd90, 35651584, 0) failed; error='Cannot 
allocate memory' (errno=12)
   [junit4] <<< JVM J1: EOF 

[...truncated 36 lines...]
   [junit4] JVM J2: stdout was not empty, see: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.x/checkout/lucene/build/core/test/temp/junit4-J2-20171030_122842_3973079934125306107000.sysout
   [junit4] >>> JVM J2 emitted unexpected output (verbatim) 
   [junit4] #
   [junit4] # There is insufficient memory for the Java Runtime Environment to 
continue.
   [junit4] # Native memory allocation (mmap) failed to map 116916224 bytes for 
committing reserved memory.
   [junit4] # An error report file with more information is saved as:
   [junit4] # 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.x/checkout/lucene/build/core/test/J2/hs_err_pid12667.log
   [junit4] <<< JVM J2: EOF 

   [junit4] JVM J2: stderr was not empty, see: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.x/checkout/lucene/build/core/test/temp/junit4-J2-20171030_122842_3978570545433655420607.syserr
   [junit4] >>> JVM J2 emitted unexpected output (verbatim) 
   [junit4] Java HotSpot(TM) 64-Bit Server VM warning: INFO: 
os::commit_memory(0xee60, 116916224, 0) failed; error='Cannot 
allocate memory' (errno=12)
   [junit4] <<< JVM J2: EOF 

[...truncated 1038 lines...]
   [junit4] ERROR: JVM J1 ended with an exception, command line: 
/usr/local/asfpackages/java/jdk1.8.0_144/jre/bin/java 
-XX:+HeapDumpOnOutOfMemoryError 
-XX:HeapDumpPath=/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.x/checkout/heapdumps
 -ea -esa -Dtests.prefix=tests -Dtests.seed=63770348804E5E9C -Xmx512M 
-Dtests.iters= -Dtests.verbose=false -Dtests.infostream=false 
-Dtests.codec=random -Dtests.postingsformat=random 
-Dtests.docvaluesformat=random -Dtests.locale=random -Dtests.timezone=random 
-Dtests.directory=random 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.x/test-data/enwiki.random.lines.txt
 -Dtests.luceneMatchVersion=7.2.0 -Dtests.cleanthreads=perMethod 
-Djava.util.logging.config.file=/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.x/checkout/lucene/tools/junit4/logging.properties
 -Dtests.nightly=true -Dtests.weekly=false -Dtests.monster=false 
-Dtests.slow=true -Dtests.asserts=true -Dtests.multiplier=2 -DtempDir=./temp 
-Djava.io.tmpdir=./temp 
-Djunit4.tempDir=/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.x/checkout/lucene/build/core/test/temp
 
-Dcommon.dir=/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.x/checkout/lucene
 
-Dclover.db.dir=/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.x/checkout/lucene/build/clover/db
 
-Djava.security.policy=/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.x/checkout/lucene/tools/junit4/tests.policy
 -Dtests.LUCENE_VERSION=7.2.0 -Djetty.testMode=1 -Djetty.insecurerandom=1 
-Dsolr.directoryFactory=org.apache.solr.core.MockDirectoryFactory 
-Djava.awt.headless=true -Djdk.map.althashing.threshold=0 
-Dtests.src.home=/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.x/checkout
 -Djava.security.egd=file:/dev/./urandom 
-Djunit4.childvm.cwd=/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.x/checkout/lucene/build/core/test/J1
 -Djunit4.childvm.id=1 -Djunit4.childvm.count=3 -Dtests.leaveTemporary=false 
-Dtests.filterstacks=true 
-Djava.security.manager=org.apache.lucene.util.TestSecurityManager 
-Dfile.encoding=US-ASCII -classpath 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.x/checkout/lucene/build/codecs/classes/java:/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.x/checkout/lucene/build/test-framework/classes/java:/x1/jenkins/jenkins-slave/workspace

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

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/20770/
Java: 64bit/jdk1.8.0_144 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC

14 tests failed.
FAILED:  
org.apache.solr.client.solrj.io.stream.StreamExpressionTest.testParallelDaemonUpdateStream

Error Message:
Error from server at https://127.0.0.1:46449/solr: Could not fully create 
collection: parallelDestinationCollection1

Stack Trace:
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at https://127.0.0.1:46449/solr: Could not fully create collection: 
parallelDestinationCollection1
at 
__randomizedtesting.SeedInfo.seed([624EA9ED454E4D46:12F188CDADA334FB]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:626)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:253)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:242)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:483)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:413)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1096)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:875)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:808)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:178)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:195)
at 
org.apache.solr.client.solrj.io.stream.StreamExpressionTest.testParallelDaemonUpdateStream(StreamExpressionTest.java:4151)
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.randomizedtes

[GitHub] lucene-solr issue #268: Fix some spell check issues

[iorixxx]

Github user iorixxx commented on the issue:

https://github.com/apache/lucene-solr/pull/268
  
*TokenizerImpl.java files have corresponding *.jflex files in the source 
tree. Do you mind fixing typos in *.jflex files? I think the ant target `ant 
jflex` in `lucene/analysis/common/` is used to generate *.java files from 
*.jflex files.


---

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

[jira] [Commented] (SOLR-11003) Enabling bi-directional CDCR on cluster for better failover

[Amrit Sarkar (JIRA)]

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

Amrit Sarkar commented on SOLR-11003:
-

[~varunthacker]

Yes it applies smoothly. Do you need any changes in the current patch? 

The above two you mentioned, 
* 2 shards instead of 1? The only problem / caveat is the test will become 
heavier with two separate clusters running already, I hope it don't introduce 
unnecessary zk-timeouts or such. 
* Also removing CdcrQueue status (it causes no harm though).

Let me know.

> Enabling bi-directional CDCR on cluster for better failover
> ---
>
> Key: SOLR-11003
> URL: https://issues.apache.org/jira/browse/SOLR-11003
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: CDCR
>Reporter: Amrit Sarkar
>Assignee: Varun Thacker
> Attachments: SOLR-11003-tlogutils.patch, SOLR-11003.patch, 
> SOLR-11003.patch, SOLR-11003.patch, SOLR-11003.patch, SOLR-11003.patch, 
> SOLR-11003.patch, SOLR-11003.patch, SOLR-11003.patch, SOLR-11003.patch, 
> SOLR-11003.patch, sample-configs.zip
>
>
> The latest version of Solr CDCR across collections / clusters is in 
> active-passive format, where we can index into source collection and the 
> updates gets forwarded to the passive one and vice-versa is not supported.
> https://lucene.apache.org/solr/guide/6_6/cross-data-center-replication-cdcr.html
> https://issues.apache.org/jira/browse/SOLR-6273
> We are try to get a  design ready to index in both collections and the 
> updates gets reflected across the collections in real-time (given the backlog 
> of replicating updates to other data center). ClusterACollectionA => 
> ClusterBCollectionB | ClusterBCollectionB => ClusterACollectionA.
> The STRONG RECOMMENDED way to keep indexing in ClusterACollectionA which 
> forwards the updates to ClusterBCollectionB. If ClusterACollectionA gets 
> down, we point the indexer and searcher application to ClusterBCollectionB. 
> Once ClusterACollectionA is up, depending on updates count, they will be 
> bootstrapped or forwarded to ClusterACollectionA from ClusterBCollectionB and 
> keep indexing on the ClusterBCollectionB.



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

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

[jira] [Updated] (SOLR-11003) Enabling bi-directional CDCR on cluster for better failover

[Varun Thacker (JIRA)]

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

Varun Thacker updated SOLR-11003:
-
Attachment: SOLR-11003.patch

Does this patch apply cleanly for you ?

> Enabling bi-directional CDCR on cluster for better failover
> ---
>
> Key: SOLR-11003
> URL: https://issues.apache.org/jira/browse/SOLR-11003
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: CDCR
>Reporter: Amrit Sarkar
>Assignee: Varun Thacker
> Attachments: SOLR-11003-tlogutils.patch, SOLR-11003.patch, 
> SOLR-11003.patch, SOLR-11003.patch, SOLR-11003.patch, SOLR-11003.patch, 
> SOLR-11003.patch, SOLR-11003.patch, SOLR-11003.patch, SOLR-11003.patch, 
> SOLR-11003.patch, sample-configs.zip
>
>
> The latest version of Solr CDCR across collections / clusters is in 
> active-passive format, where we can index into source collection and the 
> updates gets forwarded to the passive one and vice-versa is not supported.
> https://lucene.apache.org/solr/guide/6_6/cross-data-center-replication-cdcr.html
> https://issues.apache.org/jira/browse/SOLR-6273
> We are try to get a  design ready to index in both collections and the 
> updates gets reflected across the collections in real-time (given the backlog 
> of replicating updates to other data center). ClusterACollectionA => 
> ClusterBCollectionB | ClusterBCollectionB => ClusterACollectionA.
> The STRONG RECOMMENDED way to keep indexing in ClusterACollectionA which 
> forwards the updates to ClusterBCollectionB. If ClusterACollectionA gets 
> down, we point the indexer and searcher application to ClusterBCollectionB. 
> Once ClusterACollectionA is up, depending on updates count, they will be 
> bootstrapped or forwarded to ClusterACollectionA from ClusterBCollectionB and 
> keep indexing on the ClusterBCollectionB.



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

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

[jira] [Updated] (SOLR-11578) Solr 7 Admin UI (Cloud > Graph) should reflect the Replica type to give a more accurate representation of the cluster

[Rohit (JIRA)]

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

Rohit updated SOLR-11578:
-
Attachment: SOLR-11578.patch
Updated Graph.png
Updated Legend.png
Updated Radial Graph.png

Adding first draft of the patch with with following features:

1. Indicate the replica type for Solr Admin UI --> Cloud --> Graph/Graph Radial 
mode
Format: IP:PORT (X)
Where X is the replica type as indicated in the Legend
N: NRT
P: PULL
T: TLOG

Example:
192.168.1.3:8983 (N)
192.168.1.3:8984 (T)
192.168.1.3:8983 (T)
192.168.1.3:7574 (P)

2. Updated the legend to reflect the names for the respective replica type.

> Solr 7 Admin UI (Cloud > Graph) should reflect the Replica type to give a 
> more accurate representation of the cluster
> -
>
> Key: SOLR-11578
> URL: https://issues.apache.org/jira/browse/SOLR-11578
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Admin UI
>Affects Versions: 7.0, 7.1
>Reporter: Rohit
>Priority: Minor
> Attachments: SOLR-11578.patch, Updated Graph.png, Updated Legend.png, 
> Updated Radial Graph.png
>
>
> New replica types were introduced in Solr 7.
> 1. The Solr Admin UI --> Cloud --> Graph mode should be updated to reflect 
> the new replica types (NRT, TLOG, PULL)
> 2. It will give a better overview of the cluster as well as help in 
> troubleshooting and diagnosing issues.



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

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