[JENKINS] Lucene-Solr-8.x-Linux (64bit/jdk1.8.0_172) - Build # 198 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-8.x-Linux/198/
Java: 64bit/jdk1.8.0_172 -XX:+UseCompressedOops -XX:+UseSerialGC

6 tests failed.
FAILED:  junit.framework.TestSuite.org.apache.solr.core.TestSolrDeletionPolicy1

Error Message:
1 thread leaked from SUITE scope at 
org.apache.solr.core.TestSolrDeletionPolicy1: 1) Thread[id=31, 
name=Log4j2-TF-2-AsyncLoggerConfig--2, state=TIMED_WAITING, 
group=TGRP-TestSolrDeletionPolicy1] at sun.misc.Unsafe.park(Native 
Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) 
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
 at 
com.lmax.disruptor.TimeoutBlockingWaitStrategy.waitFor(TimeoutBlockingWaitStrategy.java:38)
 at 
com.lmax.disruptor.ProcessingSequenceBarrier.waitFor(ProcessingSequenceBarrier.java:56)
 at 
com.lmax.disruptor.BatchEventProcessor.run(BatchEventProcessor.java:128)
 at java.lang.Thread.run(Thread.java:748)

Stack Trace:
com.carrotsearch.randomizedtesting.ThreadLeakError: 1 thread leaked from SUITE 
scope at org.apache.solr.core.TestSolrDeletionPolicy1: 
   1) Thread[id=31, name=Log4j2-TF-2-AsyncLoggerConfig--2, state=TIMED_WAITING, 
group=TGRP-TestSolrDeletionPolicy1]
at sun.misc.Unsafe.park(Native Method)
at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
at 
com.lmax.disruptor.TimeoutBlockingWaitStrategy.waitFor(TimeoutBlockingWaitStrategy.java:38)
at 
com.lmax.disruptor.ProcessingSequenceBarrier.waitFor(ProcessingSequenceBarrier.java:56)
at 
com.lmax.disruptor.BatchEventProcessor.run(BatchEventProcessor.java:128)
at java.lang.Thread.run(Thread.java:748)
at __randomizedtesting.SeedInfo.seed([625C7F08970F2375]:0)


FAILED:  junit.framework.TestSuite.org.apache.solr.core.TestSolrDeletionPolicy1

Error Message:
There are still zombie threads that couldn't be terminated:1) Thread[id=31, 
name=Log4j2-TF-2-AsyncLoggerConfig--2, state=TIMED_WAITING, 
group=TGRP-TestSolrDeletionPolicy1] at sun.misc.Unsafe.park(Native 
Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) 
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
 at 
com.lmax.disruptor.TimeoutBlockingWaitStrategy.waitFor(TimeoutBlockingWaitStrategy.java:38)
 at 
com.lmax.disruptor.ProcessingSequenceBarrier.waitFor(ProcessingSequenceBarrier.java:56)
 at 
com.lmax.disruptor.BatchEventProcessor.run(BatchEventProcessor.java:128)
 at java.lang.Thread.run(Thread.java:748)

Stack Trace:
com.carrotsearch.randomizedtesting.ThreadLeakError: There are still zombie 
threads that couldn't be terminated:
   1) Thread[id=31, name=Log4j2-TF-2-AsyncLoggerConfig--2, state=TIMED_WAITING, 
group=TGRP-TestSolrDeletionPolicy1]
at sun.misc.Unsafe.park(Native Method)
at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
at 
com.lmax.disruptor.TimeoutBlockingWaitStrategy.waitFor(TimeoutBlockingWaitStrategy.java:38)
at 
com.lmax.disruptor.ProcessingSequenceBarrier.waitFor(ProcessingSequenceBarrier.java:56)
at 
com.lmax.disruptor.BatchEventProcessor.run(BatchEventProcessor.java:128)
at java.lang.Thread.run(Thread.java:748)
at __randomizedtesting.SeedInfo.seed([625C7F08970F2375]:0)


FAILED:  junit.framework.TestSuite.org.apache.solr.core.TestSolrDeletionPolicy1

Error Message:
1 thread leaked from SUITE scope at 
org.apache.solr.core.TestSolrDeletionPolicy1: 1) Thread[id=31, 
name=Log4j2-TF-2-AsyncLoggerConfig--2, state=TIMED_WAITING, 
group=TGRP-TestSolrDeletionPolicy1] at sun.misc.Unsafe.park(Native 
Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) 
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
 at 
com.lmax.disruptor.TimeoutBlockingWaitStrategy.waitFor(TimeoutBlockingWaitStrategy.java:38)
 at 
com.lmax.disruptor.ProcessingSequenceBarrier.waitFor(ProcessingSequenceBarrier.java:56)
 at 
com.lmax.disruptor.BatchEventProcessor.run(BatchEventProcessor.java:128)
 at java.lang.Thread.run(Thread.java:748)

Stack Trace:
com.carrotsearch.randomizedtesting.ThreadLeakError: 1 thread leaked from SUITE 
scope at org.apache.solr.core.TestSolrDeletionPolicy1: 
   1) Thread[id=31, name=Log4j2-TF-2-AsyncLoggerConfig--2, state=TIMED_WAITING, 
group=TGRP-TestSolrDeletionPolicy1]
at sun.misc.Unsafe.park(Native Method)
 

[JENKINS] Lucene-Solr-BadApples-Tests-8.x - Build # 31 - Unstable

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-BadApples-Tests-8.x/31/

2 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.handler.component.DistributedSuggestComponentTest

Error Message:
1 thread leaked from SUITE scope at 
org.apache.solr.handler.component.DistributedSuggestComponentTest: 1) 
Thread[id=340, name=Log4j2-TF-2-AsyncLoggerConfig--2, state=TIMED_WAITING, 
group=TGRP-DistributedSuggestComponentTest] at 
sun.misc.Unsafe.park(Native Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) 
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
 at 
com.lmax.disruptor.TimeoutBlockingWaitStrategy.waitFor(TimeoutBlockingWaitStrategy.java:38)
 at 
com.lmax.disruptor.ProcessingSequenceBarrier.waitFor(ProcessingSequenceBarrier.java:56)
 at 
com.lmax.disruptor.BatchEventProcessor.run(BatchEventProcessor.java:128)
 at java.lang.Thread.run(Thread.java:748)

Stack Trace:
com.carrotsearch.randomizedtesting.ThreadLeakError: 1 thread leaked from SUITE 
scope at org.apache.solr.handler.component.DistributedSuggestComponentTest: 
   1) Thread[id=340, name=Log4j2-TF-2-AsyncLoggerConfig--2, 
state=TIMED_WAITING, group=TGRP-DistributedSuggestComponentTest]
at sun.misc.Unsafe.park(Native Method)
at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
at 
com.lmax.disruptor.TimeoutBlockingWaitStrategy.waitFor(TimeoutBlockingWaitStrategy.java:38)
at 
com.lmax.disruptor.ProcessingSequenceBarrier.waitFor(ProcessingSequenceBarrier.java:56)
at 
com.lmax.disruptor.BatchEventProcessor.run(BatchEventProcessor.java:128)
at java.lang.Thread.run(Thread.java:748)
at __randomizedtesting.SeedInfo.seed([8F941258DCD2167E]:0)


FAILED:  
junit.framework.TestSuite.org.apache.solr.handler.component.DistributedSuggestComponentTest

Error Message:
There are still zombie threads that couldn't be terminated:1) 
Thread[id=340, name=Log4j2-TF-2-AsyncLoggerConfig--2, state=TIMED_WAITING, 
group=TGRP-DistributedSuggestComponentTest] at 
sun.misc.Unsafe.park(Native Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) 
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
 at 
com.lmax.disruptor.TimeoutBlockingWaitStrategy.waitFor(TimeoutBlockingWaitStrategy.java:38)
 at 
com.lmax.disruptor.ProcessingSequenceBarrier.waitFor(ProcessingSequenceBarrier.java:56)
 at 
com.lmax.disruptor.BatchEventProcessor.run(BatchEventProcessor.java:128)
 at java.lang.Thread.run(Thread.java:748)

Stack Trace:
com.carrotsearch.randomizedtesting.ThreadLeakError: There are still zombie 
threads that couldn't be terminated:
   1) Thread[id=340, name=Log4j2-TF-2-AsyncLoggerConfig--2, 
state=TIMED_WAITING, group=TGRP-DistributedSuggestComponentTest]
at sun.misc.Unsafe.park(Native Method)
at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
at 
com.lmax.disruptor.TimeoutBlockingWaitStrategy.waitFor(TimeoutBlockingWaitStrategy.java:38)
at 
com.lmax.disruptor.ProcessingSequenceBarrier.waitFor(ProcessingSequenceBarrier.java:56)
at 
com.lmax.disruptor.BatchEventProcessor.run(BatchEventProcessor.java:128)
at java.lang.Thread.run(Thread.java:748)
at __randomizedtesting.SeedInfo.seed([8F941258DCD2167E]:0)




Build Log:
[...truncated 12655 lines...]
   [junit4] Suite: 
org.apache.solr.handler.component.DistributedSuggestComponentTest
   [junit4]   2> 4530 INFO  
(SUITE-DistributedSuggestComponentTest-seed#[8F941258DCD2167E]-worker) [] 
o.a.s.SolrTestCaseJ4 SecureRandom sanity checks: 
test.solr.allowed.securerandom=null & java.security.egd=file:/dev/./urandom
   [junit4]   2> Creating dataDir: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-BadApples-Tests-8.x/solr/build/solr-core/test/J1/temp/solr.handler.component.DistributedSuggestComponentTest_8F941258DCD2167E-001/init-core-data-001
   [junit4]   2> 4716 INFO  
(SUITE-DistributedSuggestComponentTest-seed#[8F941258DCD2167E]-worker) [] 
o.a.s.SolrTestCaseJ4 Using TrieFields (NUMERIC_POINTS_SYSPROP=false) 
w/NUMERIC_DOCVALUES_SYSPROP=false
   [junit4]   2> 4795 INFO  
(SUITE-DistributedSuggestComponentTest-seed#[8F941258DCD2167E]-worker) [] 
o.e.j.u.log Logging initialized @4843ms to org.eclipse.jetty.util.log.Slf4jLog
   [junit4]   2> 4806 INFO  
(SUITE-DistributedSuggestComponentTest-seed#[8F941258DCD2167E]-worker) [] 
o.a.s.SolrTestCaseJ4 Randomized ssl (false) and 

[JENKINS-EA] Lucene-Solr-8.0-Linux (64bit/jdk-12-ea+shipilev-fastdebug) - Build # 206 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-8.0-Linux/206/
Java: 64bit/jdk-12-ea+shipilev-fastdebug -XX:-UseCompressedOops -XX:+UseG1GC

2 tests failed.
FAILED:  
org.apache.solr.cloud.autoscaling.sim.TestSimLargeCluster.testSearchRate

Error Message:
The trigger did not fire at all

Stack Trace:
java.lang.AssertionError: The trigger did not fire at all
at 
__randomizedtesting.SeedInfo.seed([CB1BD21013E87B18:9653CC99DC2EDD57]:0)
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.assertTrue(Assert.java:41)
at 
org.apache.solr.cloud.autoscaling.sim.TestSimLargeCluster.testSearchRate(TestSimLargeCluster.java:682)
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:567)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988)
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:947)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894)
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:835)


FAILED:  
org.apache.solr.cloud.autoscaling.sim.TestSimTriggerIntegration.testSearchRate

Error Message:
The trigger did not start in time

Stack Trace:
java.lang.AssertionError: The trigger did not start in time
at 

Re: Welcome Jason Gerlowski to the PMC

[Koji Sekiguchi]

Welcome, Jason!

Koji

On 2019/02/23 0:21, Jan Høydahl wrote:

I am pleased to announce that Jason Gerlowski has accepted the PMC's invitation 
to join.

Welcome Jason!

--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com


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





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

[JENKINS] Lucene-Solr-NightlyTests-master - Build # 1777 - Unstable

[Apache Jenkins Server]

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

2 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.schema.SpatialRPTFieldTypeTest

Error Message:
1 thread leaked from SUITE scope at 
org.apache.solr.schema.SpatialRPTFieldTypeTest: 1) Thread[id=264, 
name=Log4j2-TF-2-AsyncLoggerConfig--2, state=TIMED_WAITING, 
group=TGRP-SpatialRPTFieldTypeTest] at sun.misc.Unsafe.park(Native 
Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) 
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
 at 
com.lmax.disruptor.TimeoutBlockingWaitStrategy.waitFor(TimeoutBlockingWaitStrategy.java:38)
 at 
com.lmax.disruptor.ProcessingSequenceBarrier.waitFor(ProcessingSequenceBarrier.java:56)
 at 
com.lmax.disruptor.BatchEventProcessor.run(BatchEventProcessor.java:128)
 at java.lang.Thread.run(Thread.java:748)

Stack Trace:
com.carrotsearch.randomizedtesting.ThreadLeakError: 1 thread leaked from SUITE 
scope at org.apache.solr.schema.SpatialRPTFieldTypeTest: 
   1) Thread[id=264, name=Log4j2-TF-2-AsyncLoggerConfig--2, 
state=TIMED_WAITING, group=TGRP-SpatialRPTFieldTypeTest]
at sun.misc.Unsafe.park(Native Method)
at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
at 
com.lmax.disruptor.TimeoutBlockingWaitStrategy.waitFor(TimeoutBlockingWaitStrategy.java:38)
at 
com.lmax.disruptor.ProcessingSequenceBarrier.waitFor(ProcessingSequenceBarrier.java:56)
at 
com.lmax.disruptor.BatchEventProcessor.run(BatchEventProcessor.java:128)
at java.lang.Thread.run(Thread.java:748)
at __randomizedtesting.SeedInfo.seed([5B7FCF2FB6B52446]:0)


FAILED:  
junit.framework.TestSuite.org.apache.solr.schema.SpatialRPTFieldTypeTest

Error Message:
There are still zombie threads that couldn't be terminated:1) 
Thread[id=264, name=Log4j2-TF-2-AsyncLoggerConfig--2, state=TIMED_WAITING, 
group=TGRP-SpatialRPTFieldTypeTest] at sun.misc.Unsafe.park(Native 
Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) 
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
 at 
com.lmax.disruptor.TimeoutBlockingWaitStrategy.waitFor(TimeoutBlockingWaitStrategy.java:38)
 at 
com.lmax.disruptor.ProcessingSequenceBarrier.waitFor(ProcessingSequenceBarrier.java:56)
 at 
com.lmax.disruptor.BatchEventProcessor.run(BatchEventProcessor.java:128)
 at java.lang.Thread.run(Thread.java:748)

Stack Trace:
com.carrotsearch.randomizedtesting.ThreadLeakError: There are still zombie 
threads that couldn't be terminated:
   1) Thread[id=264, name=Log4j2-TF-2-AsyncLoggerConfig--2, 
state=TIMED_WAITING, group=TGRP-SpatialRPTFieldTypeTest]
at sun.misc.Unsafe.park(Native Method)
at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
at 
com.lmax.disruptor.TimeoutBlockingWaitStrategy.waitFor(TimeoutBlockingWaitStrategy.java:38)
at 
com.lmax.disruptor.ProcessingSequenceBarrier.waitFor(ProcessingSequenceBarrier.java:56)
at 
com.lmax.disruptor.BatchEventProcessor.run(BatchEventProcessor.java:128)
at java.lang.Thread.run(Thread.java:748)
at __randomizedtesting.SeedInfo.seed([5B7FCF2FB6B52446]:0)




Build Log:
[...truncated 13102 lines...]
   [junit4] Suite: org.apache.solr.schema.SpatialRPTFieldTypeTest
   [junit4]   2> 4847 INFO  
(SUITE-SpatialRPTFieldTypeTest-seed#[5B7FCF2FB6B52446]-worker) [] 
o.a.s.SolrTestCaseJ4 SecureRandom sanity checks: 
test.solr.allowed.securerandom=null & java.security.egd=file:/dev/./urandom
   [junit4]   2> Creating dataDir: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-master/checkout/solr/build/solr-core/test/J0/temp/solr.schema.SpatialRPTFieldTypeTest_5B7FCF2FB6B52446-001/init-core-data-001
   [junit4]   2> 5096 INFO  
(SUITE-SpatialRPTFieldTypeTest-seed#[5B7FCF2FB6B52446]-worker) [] 
o.a.s.SolrTestCaseJ4 Using PointFields (NUMERIC_POINTS_SYSPROP=true) 
w/NUMERIC_DOCVALUES_SYSPROP=false
   [junit4]   2> 5194 INFO  
(SUITE-SpatialRPTFieldTypeTest-seed#[5B7FCF2FB6B52446]-worker) [] 
o.e.j.u.log Logging initialized @5246ms to org.eclipse.jetty.util.log.Slf4jLog
   [junit4]   2> 5210 INFO  
(SUITE-SpatialRPTFieldTypeTest-seed#[5B7FCF2FB6B52446]-worker) [] 
o.a.s.SolrTestCaseJ4 Randomized ssl (false) and clientAuth (true) via: 
@org.apache.solr.util.RandomizeSSL(reason=, value=NaN, ssl=NaN, clientAuth=NaN)
   [junit4]   2> 5333 INFO  

Re: Welcome Jason Gerlowski to the PMC

[Shai Erera]

Congratulations Jason!

On Fri, Feb 22, 2019, 23:20 Anshum Gupta  wrote:

> Congratulations and welcome Jason!
>
> *  *Anshum
>
>
> On Feb 22, 2019, at 7:21 AM, Jan Høydahl  wrote:
>
> I am pleased to announce that Jason Gerlowski has accepted the PMC's
> invitation to join.
>
> Welcome Jason!
>
> --
> Jan Høydahl, search solution architect
> Cominvent AS - www.cominvent.com
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> 
> For additional commands, e-mail: dev-h...@lucene.apache.org
> 
>
>
>

[JENKINS] Lucene-Solr-8.0-Windows (64bit/jdk-9.0.4) - Build # 45 - Failure!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-8.0-Windows/45/
Java: 64bit/jdk-9.0.4 -XX:-UseCompressedOops -XX:+UseParallelGC

All tests passed

Build Log:
[...truncated 14556 lines...]
   [junit4] JVM J0: stdout was not empty, see: 
C:\Users\jenkins\workspace\Lucene-Solr-8.0-Windows\solr\build\solr-core\test\temp\junit4-J0-20190223_020255_1849133589862645065774.sysout
   [junit4] >>> JVM J0 emitted unexpected output (verbatim) 
   [junit4] #
   [junit4] # A fatal error has been detected by the Java Runtime Environment:
   [junit4] #
   [junit4] #  EXCEPTION_ACCESS_VIOLATION (0xc005) at 
pc=0x51150b2f, pid=12080, tid=10268
   [junit4] #
   [junit4] # JRE version: OpenJDK Runtime Environment (9.0+11) (build 9.0.4+11)
   [junit4] # Java VM: OpenJDK 64-Bit Server VM (9.0.4+11, mixed mode, tiered, 
parallel gc, windows-amd64)
   [junit4] # Problematic frame:
   [junit4] # V  [jvm.dll+0x460b2f]
   [junit4] #
   [junit4] # No core dump will be written. Minidumps are not enabled by 
default on client versions of Windows
   [junit4] #
   [junit4] # An error report file with more information is saved as:
   [junit4] # 
C:\Users\jenkins\workspace\Lucene-Solr-8.0-Windows\solr\build\solr-core\test\J0\hs_err_pid12080.log
   [junit4] #
   [junit4] # Compiler replay data is saved as:
   [junit4] # 
C:\Users\jenkins\workspace\Lucene-Solr-8.0-Windows\solr\build\solr-core\test\J0\replay_pid12080.log
   [junit4] #
   [junit4] # If you would like to submit a bug report, please visit:
   [junit4] #   http://bugreport.java.com/bugreport/crash.jsp
   [junit4] #
   [junit4] <<< JVM J0: EOF 

[...truncated 1132 lines...]
   [junit4] ERROR: JVM J0 ended with an exception, command line: 
C:\Users\jenkins\tools\java\64bit\jdk-9.0.4\bin\java.exe -XX:-UseCompressedOops 
-XX:+UseParallelGC -XX:+HeapDumpOnOutOfMemoryError 
-XX:HeapDumpPath=C:\Users\jenkins\workspace\Lucene-Solr-8.0-Windows\heapdumps 
-ea -esa --illegal-access=deny -Dtests.prefix=tests 
-Dtests.seed=EC3F6E15D8ED3283 -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=perClass 
-Djava.util.logging.config.file=C:\Users\jenkins\workspace\Lucene-Solr-8.0-Windows\lucene\tools\junit4\logging.properties
 -Dtests.nightly=false -Dtests.weekly=false -Dtests.monster=false 
-Dtests.slow=true -Dtests.asserts=true -Dtests.multiplier=1 -DtempDir=./temp 
-Djava.io.tmpdir=./temp 
-Dcommon.dir=C:\Users\jenkins\workspace\Lucene-Solr-8.0-Windows\lucene 
-Dclover.db.dir=C:\Users\jenkins\workspace\Lucene-Solr-8.0-Windows\lucene\build\clover\db
 
-Djava.security.policy=C:\Users\jenkins\workspace\Lucene-Solr-8.0-Windows\lucene\tools\junit4\solr-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=C:\Users\jenkins\workspace\Lucene-Solr-8.0-Windows 
-Djava.security.egd=file:/dev/./urandom 
-Djunit4.childvm.cwd=C:\Users\jenkins\workspace\Lucene-Solr-8.0-Windows\solr\build\solr-core\test\J0
 
-Djunit4.tempDir=C:\Users\jenkins\workspace\Lucene-Solr-8.0-Windows\solr\build\solr-core\test\temp
 -Djunit4.childvm.id=0 -Djunit4.childvm.count=2 -Dfile.encoding=US-ASCII 
-Dtests.disableHdfs=true 
-Djava.security.manager=org.apache.lucene.util.TestSecurityManager 
-Dtests.filterstacks=true -Dtests.leaveTemporary=false -Dtests.badapples=false 
-classpath 

[JENKINS-EA] Lucene-Solr-7.x-Linux (64bit/jdk-13-ea+8) - Build # 3573 - Failure!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/3573/
Java: 64bit/jdk-13-ea+8 -XX:+UseCompressedOops -XX:+UseSerialGC

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

Error Message:
SOLR-11606: ByteBuddy used by Mockito is not working with this JVM version.

Stack Trace:
org.junit.AssumptionViolatedException: SOLR-11606: ByteBuddy used by Mockito is 
not working with this JVM version.
at __randomizedtesting.SeedInfo.seed([302C55A0BD689CA2]:0)
at 
com.carrotsearch.randomizedtesting.RandomizedTest.assumeNoException(RandomizedTest.java:742)
at 
org.apache.solr.SolrTestCaseJ4.assumeWorkingMockito(SolrTestCaseJ4.java:362)
at org.apache.solr.cloud.OverseerTest.beforeClass(OverseerTest.java:284)
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:567)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:878)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894)
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:835)
Caused by: java.lang.IllegalArgumentException: Unknown Java version: 13
at 
net.bytebuddy.ClassFileVersion.ofJavaVersion(ClassFileVersion.java:210)
at 
net.bytebuddy.ClassFileVersion$VersionLocator$ForJava9CapableVm.locate(ClassFileVersion.java:462)
at net.bytebuddy.ClassFileVersion.ofThisVm(ClassFileVersion.java:223)
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:567)
at 
org.apache.solr.SolrTestCaseJ4.assumeWorkingMockito(SolrTestCaseJ4.java:360)
... 24 more


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

Error Message:


Stack Trace:
java.lang.NullPointerException
at __randomizedtesting.SeedInfo.seed([302C55A0BD689CA2]:0)
at org.apache.solr.cloud.OverseerTest.afterClass(OverseerTest.java:307)
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:567)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:901)
at 

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

[Policeman Jenkins Server]

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

2 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.cloud.TestRandomRequestDistribution

Error Message:
1 thread leaked from SUITE scope at 
org.apache.solr.cloud.TestRandomRequestDistribution: 1) Thread[id=325, 
name=Log4j2-TF-2-AsyncLoggerConfig--2, state=TIMED_WAITING, 
group=TGRP-TestRandomRequestDistribution] at 
sun.misc.Unsafe.park(Native Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) 
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
 at 
com.lmax.disruptor.TimeoutBlockingWaitStrategy.waitFor(TimeoutBlockingWaitStrategy.java:38)
 at 
com.lmax.disruptor.ProcessingSequenceBarrier.waitFor(ProcessingSequenceBarrier.java:56)
 at 
com.lmax.disruptor.BatchEventProcessor.run(BatchEventProcessor.java:128)
 at java.lang.Thread.run(Thread.java:748)

Stack Trace:
com.carrotsearch.randomizedtesting.ThreadLeakError: 1 thread leaked from SUITE 
scope at org.apache.solr.cloud.TestRandomRequestDistribution: 
   1) Thread[id=325, name=Log4j2-TF-2-AsyncLoggerConfig--2, 
state=TIMED_WAITING, group=TGRP-TestRandomRequestDistribution]
at sun.misc.Unsafe.park(Native Method)
at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
at 
com.lmax.disruptor.TimeoutBlockingWaitStrategy.waitFor(TimeoutBlockingWaitStrategy.java:38)
at 
com.lmax.disruptor.ProcessingSequenceBarrier.waitFor(ProcessingSequenceBarrier.java:56)
at 
com.lmax.disruptor.BatchEventProcessor.run(BatchEventProcessor.java:128)
at java.lang.Thread.run(Thread.java:748)
at __randomizedtesting.SeedInfo.seed([9835C083AEE8B0F7]:0)


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

Error Message:
There are still zombie threads that couldn't be terminated:1) 
Thread[id=325, name=Log4j2-TF-2-AsyncLoggerConfig--2, state=TIMED_WAITING, 
group=TGRP-TestRandomRequestDistribution] at 
sun.misc.Unsafe.park(Native Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) 
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
 at 
com.lmax.disruptor.TimeoutBlockingWaitStrategy.waitFor(TimeoutBlockingWaitStrategy.java:38)
 at 
com.lmax.disruptor.ProcessingSequenceBarrier.waitFor(ProcessingSequenceBarrier.java:56)
 at 
com.lmax.disruptor.BatchEventProcessor.run(BatchEventProcessor.java:128)
 at java.lang.Thread.run(Thread.java:748)

Stack Trace:
com.carrotsearch.randomizedtesting.ThreadLeakError: There are still zombie 
threads that couldn't be terminated:
   1) Thread[id=325, name=Log4j2-TF-2-AsyncLoggerConfig--2, 
state=TIMED_WAITING, group=TGRP-TestRandomRequestDistribution]
at sun.misc.Unsafe.park(Native Method)
at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
at 
com.lmax.disruptor.TimeoutBlockingWaitStrategy.waitFor(TimeoutBlockingWaitStrategy.java:38)
at 
com.lmax.disruptor.ProcessingSequenceBarrier.waitFor(ProcessingSequenceBarrier.java:56)
at 
com.lmax.disruptor.BatchEventProcessor.run(BatchEventProcessor.java:128)
at java.lang.Thread.run(Thread.java:748)
at __randomizedtesting.SeedInfo.seed([9835C083AEE8B0F7]:0)




Build Log:
[...truncated 12628 lines...]
   [junit4] Suite: org.apache.solr.cloud.TestRandomRequestDistribution
   [junit4]   2> Creating dataDir: 
/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/build/solr-core/test/J2/temp/solr.cloud.TestRandomRequestDistribution_9835C083AEE8B0F7-001/init-core-data-001
   [junit4]   2> 2422 INFO  
(SUITE-TestRandomRequestDistribution-seed#[9835C083AEE8B0F7]-worker) [] 
o.a.s.SolrTestCaseJ4 Using PointFields (NUMERIC_POINTS_SYSPROP=true) 
w/NUMERIC_DOCVALUES_SYSPROP=false
   [junit4]   2> 2483 INFO  
(SUITE-TestRandomRequestDistribution-seed#[9835C083AEE8B0F7]-worker) [] 
o.e.j.u.log Logging initialized @2521ms to org.eclipse.jetty.util.log.Slf4jLog
   [junit4]   2> 2494 INFO  
(SUITE-TestRandomRequestDistribution-seed#[9835C083AEE8B0F7]-worker) [] 
o.a.s.SolrTestCaseJ4 Randomized ssl (false) and clientAuth (false) via: 
@org.apache.solr.SolrTestCaseJ4$SuppressSSL(bugUrl=None)
   [junit4]   2> 2519 INFO  
(SUITE-TestRandomRequestDistribution-seed#[9835C083AEE8B0F7]-worker) [] 
o.a.s.SolrTestCaseJ4 SecureRandom sanity checks: 
test.solr.allowed.securerandom=null & 

[jira] [Comment Edited] (SOLR-13268) Clean up any test failures resulting from SOLR-12055 (async logging)

[Kevin Risden (JIRA)]

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

Kevin Risden edited comment on SOLR-13268 at 2/23/19 1:40 AM:
--

Here is a failure from AdoptOpenJDK 11.0.2

*TestInitParams*
{code:java}
   [junit4]   2> NOTE: reproduce with: ant test  -Dtestcase=TestInitParams 
-Dtests.seed=466988C6E1830B46 -Dtests.slow=true -Dtests.badapples=true 
-Dtests.locale=yue-Hant -Dtests.timezone=America/Santo_Domingo 
-Dtests.asserts=true -Dtests.file.encoding=US-ASCII
   [junit4] ERROR   0.00s J0 | TestInitParams (suite) <<<
   [junit4]> Throwable #1: 
com.carrotsearch.randomizedtesting.ThreadLeakError: 1 thread leaked from SUITE 
scope at org.apache.solr.core.TestInitParams: 
   [junit4]>1) Thread[id=35, name=Log4j2-TF-2-AsyncLoggerConfig--2, 
state=TIMED_WAITING, group=TGRP-TestInitParams]
   [junit4]> at 
java.base@11.0.2/jdk.internal.misc.Unsafe.park(Native Method)
   [junit4]> at 
java.base@11.0.2/java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:234)
   [junit4]> at 
java.base@11.0.2/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2123)
   [junit4]> at 
app//com.lmax.disruptor.TimeoutBlockingWaitStrategy.waitFor(TimeoutBlockingWaitStrategy.java:38)
   [junit4]> at 
app//com.lmax.disruptor.ProcessingSequenceBarrier.waitFor(ProcessingSequenceBarrier.java:56)
   [junit4]> at 
app//com.lmax.disruptor.BatchEventProcessor.run(BatchEventProcessor.java:128)
   [junit4]> at 
java.base@11.0.2/java.lang.Thread.run(Thread.java:834)
   [junit4]>at 
__randomizedtesting.SeedInfo.seed([466988C6E1830B46]:0)Throwable #2: 
com.carrotsearch.randomizedtesting.ThreadLeakError: There are still zombie 
threads that couldn't be terminated:
   [junit4]>1) Thread[id=35, name=Log4j2-TF-2-AsyncLoggerConfig--2, 
state=TIMED_WAITING, group=TGRP-TestInitParams]
   [junit4]> at 
java.base@11.0.2/jdk.internal.misc.Unsafe.park(Native Method)
   [junit4]> at 
java.base@11.0.2/java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:234)
   [junit4]> at 
java.base@11.0.2/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2123)
   [junit4]> at 
app//com.lmax.disruptor.TimeoutBlockingWaitStrategy.waitFor(TimeoutBlockingWaitStrategy.java:38)
   [junit4]> at 
app//com.lmax.disruptor.ProcessingSequenceBarrier.waitFor(ProcessingSequenceBarrier.java:56)
   [junit4]> at 
app//com.lmax.disruptor.BatchEventProcessor.run(BatchEventProcessor.java:128)
   [junit4]> at 
java.base@11.0.2/java.lang.Thread.run(Thread.java:834)
   [junit4]>at 
__randomizedtesting.SeedInfo.seed([466988C6E1830B46]:0)
   [junit4] Completed [6/844 (1!)] on J0 in 21.23s, 7 tests, 2 errors <<< 
FAILURES!
{code}


was (Author: risdenk):
Here is a failure from AdoptOpenJDK 11.0.2

*TestInitParams*

 
{code:java}
   [junit4]   2> NOTE: reproduce with: ant test  -Dtestcase=TestInitParams 
-Dtests.seed=466988C6E1830B46 -Dtests.slow=true -Dtests.badapples=true 
-Dtests.locale=yue-Hant -Dtests.timezone=America/Santo_Domingo 
-Dtests.asserts=true -Dtests.file.encoding=US-ASCII
   [junit4] ERROR   0.00s J0 | TestInitParams (suite) <<<
   [junit4]> Throwable #1: 
com.carrotsearch.randomizedtesting.ThreadLeakError: 1 thread leaked from SUITE 
scope at org.apache.solr.core.TestInitParams: 
   [junit4]>1) Thread[id=35, name=Log4j2-TF-2-AsyncLoggerConfig--2, 
state=TIMED_WAITING, group=TGRP-TestInitParams]
   [junit4]> at 
java.base@11.0.2/jdk.internal.misc.Unsafe.park(Native Method)
   [junit4]> at 
java.base@11.0.2/java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:234)
   [junit4]> at 
java.base@11.0.2/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2123)
   [junit4]> at 
app//com.lmax.disruptor.TimeoutBlockingWaitStrategy.waitFor(TimeoutBlockingWaitStrategy.java:38)
   [junit4]> at 
app//com.lmax.disruptor.ProcessingSequenceBarrier.waitFor(ProcessingSequenceBarrier.java:56)
   [junit4]> at 
app//com.lmax.disruptor.BatchEventProcessor.run(BatchEventProcessor.java:128)
   [junit4]> at 
java.base@11.0.2/java.lang.Thread.run(Thread.java:834)
   [junit4]>at 
__randomizedtesting.SeedInfo.seed([466988C6E1830B46]:0)Throwable #2: 
com.carrotsearch.randomizedtesting.ThreadLeakError: There are still zombie 
threads that couldn't be terminated:
   [junit4]>1) Thread[id=35, name=Log4j2-TF-2-AsyncLoggerConfig--2, 
state=TIMED_WAITING, group=TGRP-TestInitParams]
   [junit4]> at 

[jira] [Commented] (SOLR-13268) Clean up any test failures resulting from SOLR-12055 (async logging)

[Kevin Risden (JIRA)]

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

Kevin Risden commented on SOLR-13268:
-

Here is a failure from AdoptOpenJDK 11.0.2

*TestInitParams*

 
{code:java}
   [junit4]   2> NOTE: reproduce with: ant test  -Dtestcase=TestInitParams 
-Dtests.seed=466988C6E1830B46 -Dtests.slow=true -Dtests.badapples=true 
-Dtests.locale=yue-Hant -Dtests.timezone=America/Santo_Domingo 
-Dtests.asserts=true -Dtests.file.encoding=US-ASCII
   [junit4] ERROR   0.00s J0 | TestInitParams (suite) <<<
   [junit4]> Throwable #1: 
com.carrotsearch.randomizedtesting.ThreadLeakError: 1 thread leaked from SUITE 
scope at org.apache.solr.core.TestInitParams: 
   [junit4]>1) Thread[id=35, name=Log4j2-TF-2-AsyncLoggerConfig--2, 
state=TIMED_WAITING, group=TGRP-TestInitParams]
   [junit4]> at 
java.base@11.0.2/jdk.internal.misc.Unsafe.park(Native Method)
   [junit4]> at 
java.base@11.0.2/java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:234)
   [junit4]> at 
java.base@11.0.2/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2123)
   [junit4]> at 
app//com.lmax.disruptor.TimeoutBlockingWaitStrategy.waitFor(TimeoutBlockingWaitStrategy.java:38)
   [junit4]> at 
app//com.lmax.disruptor.ProcessingSequenceBarrier.waitFor(ProcessingSequenceBarrier.java:56)
   [junit4]> at 
app//com.lmax.disruptor.BatchEventProcessor.run(BatchEventProcessor.java:128)
   [junit4]> at 
java.base@11.0.2/java.lang.Thread.run(Thread.java:834)
   [junit4]>at 
__randomizedtesting.SeedInfo.seed([466988C6E1830B46]:0)Throwable #2: 
com.carrotsearch.randomizedtesting.ThreadLeakError: There are still zombie 
threads that couldn't be terminated:
   [junit4]>1) Thread[id=35, name=Log4j2-TF-2-AsyncLoggerConfig--2, 
state=TIMED_WAITING, group=TGRP-TestInitParams]
   [junit4]> at 
java.base@11.0.2/jdk.internal.misc.Unsafe.park(Native Method)
   [junit4]> at 
java.base@11.0.2/java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:234)
   [junit4]> at 
java.base@11.0.2/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2123)
   [junit4]> at 
app//com.lmax.disruptor.TimeoutBlockingWaitStrategy.waitFor(TimeoutBlockingWaitStrategy.java:38)
   [junit4]> at 
app//com.lmax.disruptor.ProcessingSequenceBarrier.waitFor(ProcessingSequenceBarrier.java:56)
   [junit4]> at 
app//com.lmax.disruptor.BatchEventProcessor.run(BatchEventProcessor.java:128)
   [junit4]> at 
java.base@11.0.2/java.lang.Thread.run(Thread.java:834)
   [junit4]>at 
__randomizedtesting.SeedInfo.seed([466988C6E1830B46]:0)
   [junit4] Completed [6/844 (1!)] on J0 in 21.23s, 7 tests, 2 errors <<< 
FAILURES!
{code}
 

> Clean up any test failures resulting from SOLR-12055 (async logging)
> 
>
> Key: SOLR-13268
> URL: https://issues.apache.org/jira/browse/SOLR-13268
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Major
>
> This is a catch-all for test failures due to the async logging changes. So 
> far, the I see a couple failures on JDK13 only. I'll collect a "starter set" 
> here, these are likely systemic, once the root cause is found/fixed, then 
> others are likely fixed as well.
> JDK13:
> ant test  -Dtestcase=TestJmxIntegration -Dtests.seed=54B30AC62A2D71E 
> -Dtests.multiplier=3 -Dtests.slow=true -Dtests.locale=lv-LV 
> -Dtests.timezone=Asia/Riyadh -Dtests.asserts=true -Dtests.file.encoding=UTF-8
> ant test  -Dtestcase=TestDynamicURP -Dtests.seed=54B30AC62A2D71E 
> -Dtests.multiplier=3 -Dtests.slow=true -Dtests.locale=rwk 
> -Dtests.timezone=Australia/Brisbane -Dtests.asserts=true 
> -Dtests.file.encoding=UTF-8



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

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

[jira] [Commented] (SOLR-13268) Clean up any test failures resulting from SOLR-12055 (async logging)

[Kevin Risden (JIRA)]

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

Kevin Risden commented on SOLR-13268:
-

Some other info about log4j2 and LMAX releases.

We are on LMAX 3.4.0 and there is a 3.4.2 with changes related to 
`BatchEventProcessor` which was in the stack trace
 * 3.4.1 - Fix race between run() and halt() on BatchEventProcessor.
 * 3.4.2 - Fix for race condition on restart of BatchEventProcessor with 3 or 
more threads.
 * https://github.com/LMAX-Exchange/disruptor/releases

Upgrading LMAX disrupter to 3.4.2 was in the log4j 2.11.1 release notes. We 
could also upgrade log4j2 2.11.0 -> 2.11.2.

Not sure if these would help but probably wouldn't hurt either.

> Clean up any test failures resulting from SOLR-12055 (async logging)
> 
>
> Key: SOLR-13268
> URL: https://issues.apache.org/jira/browse/SOLR-13268
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Major
>
> This is a catch-all for test failures due to the async logging changes. So 
> far, the I see a couple failures on JDK13 only. I'll collect a "starter set" 
> here, these are likely systemic, once the root cause is found/fixed, then 
> others are likely fixed as well.
> JDK13:
> ant test  -Dtestcase=TestJmxIntegration -Dtests.seed=54B30AC62A2D71E 
> -Dtests.multiplier=3 -Dtests.slow=true -Dtests.locale=lv-LV 
> -Dtests.timezone=Asia/Riyadh -Dtests.asserts=true -Dtests.file.encoding=UTF-8
> ant test  -Dtestcase=TestDynamicURP -Dtests.seed=54B30AC62A2D71E 
> -Dtests.multiplier=3 -Dtests.slow=true -Dtests.locale=rwk 
> -Dtests.timezone=Australia/Brisbane -Dtests.asserts=true 
> -Dtests.file.encoding=UTF-8



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

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

[jira] [Commented] (SOLR-13268) Clean up any test failures resulting from SOLR-12055 (async logging)

[Kevin Risden (JIRA)]

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

Kevin Risden commented on SOLR-13268:
-

Shared on asf slack but adding here as well. I have a local Jenkins server that 
runs tests on JDK 8 (and 11). Here are 3 similar failures from AdoptOpenJdk 
1.8.0_202

*UpdateLogTest*
{code:java}
[junit4]   2> NOTE: reproduce with: ant test  -Dtestcase=UpdateLogTest 
-Dtests.seed=7E032A96C05E8363 -Dtests.slow=true -Dtests.badapples=true 
-Dtests.locale=ar -Dtests.timezone=America/Marigot -Dtests.asserts=true 
-Dtests.file.encoding=US-ASCII
   [junit4] ERROR   0.00s J0 | UpdateLogTest (suite) <<<
   [junit4]> Throwable #1: 
com.carrotsearch.randomizedtesting.ThreadLeakError: 1 thread leaked from SUITE 
scope at org.apache.solr.update.UpdateLogTest: 
   [junit4]>1) Thread[id=29, name=Log4j2-TF-2-AsyncLoggerConfig--2, 
state=TIMED_WAITING, group=TGRP-UpdateLogTest]
   [junit4]> at sun.misc.Unsafe.park(Native Method)
   [junit4]> at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
   [junit4]> at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
   [junit4]> at 
com.lmax.disruptor.TimeoutBlockingWaitStrategy.waitFor(TimeoutBlockingWaitStrategy.java:38)
   [junit4]> at 
com.lmax.disruptor.ProcessingSequenceBarrier.waitFor(ProcessingSequenceBarrier.java:56)
   [junit4]> at 
com.lmax.disruptor.BatchEventProcessor.run(BatchEventProcessor.java:128)
   [junit4]> at java.lang.Thread.run(Thread.java:748)
   [junit4]> at 
__randomizedtesting.SeedInfo.seed([7E032A96C05E8363]:0)Throwable #2: 
com.carrotsearch.randomizedtesting.ThreadLeakError: There are still zombie 
threads that couldn't be terminated:
   [junit4]>1) Thread[id=29, name=Log4j2-TF-2-AsyncLoggerConfig--2, 
state=TIMED_WAITING, group=TGRP-UpdateLogTest]
   [junit4]> at sun.misc.Unsafe.park(Native Method)
   [junit4]> at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
   [junit4]> at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
   [junit4]> at 
com.lmax.disruptor.TimeoutBlockingWaitStrategy.waitFor(TimeoutBlockingWaitStrategy.java:38)
   [junit4]> at 
com.lmax.disruptor.ProcessingSequenceBarrier.waitFor(ProcessingSequenceBarrier.java:56)
   [junit4]> at 
com.lmax.disruptor.BatchEventProcessor.run(BatchEventProcessor.java:128)
   [junit4]> at java.lang.Thread.run(Thread.java:748)
   [junit4]> at __randomizedtesting.SeedInfo.seed([7E032A96C05E8363]:0)
   [junit4] Completed [2/844 (1!)] on J0 in 32.30s, 4 tests, 2 errors <<< 
FAILURES
{code}
*VersionInfoTest*
{code:java}
   [junit4]   2> NOTE: reproduce with: ant test  -Dtestcase=VersionInfoTest 
-Dtests.seed=7E032A96C05E8363 -Dtests.slow=true -Dtests.badapples=true 
-Dtests.locale=et -Dtests.timezone=Indian/Mauritius -Dtests.asserts=true 
-Dtests.file.encoding=US-ASCII
   [junit4] ERROR   0.00s J2 | VersionInfoTest (suite) <<<
   [junit4]> Throwable #1: 
com.carrotsearch.randomizedtesting.ThreadLeakError: 1 thread leaked from SUITE 
scope at org.apache.solr.update.VersionInfoTest: 
   [junit4]>1) Thread[id=52, name=Log4j2-TF-2-AsyncLoggerConfig--2, 
state=TIMED_WAITING, group=TGRP-VersionInfoTest]
   [junit4]> at sun.misc.Unsafe.park(Native Method)
   [junit4]> at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
   [junit4]> at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
   [junit4]> at 
com.lmax.disruptor.TimeoutBlockingWaitStrategy.waitFor(TimeoutBlockingWaitStrategy.java:38)
   [junit4]> at 
com.lmax.disruptor.ProcessingSequenceBarrier.waitFor(ProcessingSequenceBarrier.java:56)
   [junit4]> at 
com.lmax.disruptor.BatchEventProcessor.run(BatchEventProcessor.java:128)
   [junit4]> at java.lang.Thread.run(Thread.java:748)
   [junit4]> at 
__randomizedtesting.SeedInfo.seed([7E032A96C05E8363]:0)Throwable #2: 
com.carrotsearch.randomizedtesting.ThreadLeakError: There are still zombie 
threads that couldn't be terminated:
   [junit4]>1) Thread[id=52, name=Log4j2-TF-2-AsyncLoggerConfig--2, 
state=TIMED_WAITING, group=TGRP-VersionInfoTest]
   [junit4]> at sun.misc.Unsafe.park(Native Method)
   [junit4]> at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
   [junit4]> at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
   [junit4]> at 

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

[Policeman Jenkins Server]

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

2 tests failed.
FAILED:  
org.apache.solr.client.solrj.impl.CloudSolrClientTest.testRetryUpdatesWhenClusterStateIsStale

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

Stack Trace:
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at http://127.0.0.1:50170/solr/stale_state_test_col: ClusterState 
says we are the leader 
(http://127.0.0.1:50170/solr/stale_state_test_col_shard1_replica_n3), but 
locally we don't think so. Request came from null
at 
__randomizedtesting.SeedInfo.seed([24E422FFABE59D98:90D5BA17480CEBB4]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:643)
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:484)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:414)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1110)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:884)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:997)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:817)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:194)
at 
org.apache.solr.client.solrj.request.UpdateRequest.commit(UpdateRequest.java:237)
at 
org.apache.solr.client.solrj.impl.CloudSolrClientTest.testRetryUpdatesWhenClusterStateIsStale(CloudSolrClientTest.java:835)
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:1750)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988)
at 
org.junit.rules.ExpectedException$ExpectedExceptionStatement.evaluate(ExpectedException.java:239)
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:947)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894)
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)
   

[jira] [Created] (SOLR-13268) Clean up any test failures resulting from SOLR-12055 (async logging)

[Erick Erickson (JIRA)]

Erick Erickson created SOLR-13268:
-

 Summary: Clean up any test failures resulting from SOLR-12055 
(async logging)
 Key: SOLR-13268
 URL: https://issues.apache.org/jira/browse/SOLR-13268
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Erick Erickson
Assignee: Erick Erickson


This is a catch-all for test failures due to the async logging changes. So far, 
the I see a couple failures on JDK13 only. I'll collect a "starter set" here, 
these are likely systemic, once the root cause is found/fixed, then others are 
likely fixed as well.

JDK13:

ant test  -Dtestcase=TestJmxIntegration -Dtests.seed=54B30AC62A2D71E 
-Dtests.multiplier=3 -Dtests.slow=true -Dtests.locale=lv-LV 
-Dtests.timezone=Asia/Riyadh -Dtests.asserts=true -Dtests.file.encoding=UTF-8

ant test  -Dtestcase=TestDynamicURP -Dtests.seed=54B30AC62A2D71E 
-Dtests.multiplier=3 -Dtests.slow=true -Dtests.locale=rwk 
-Dtests.timezone=Australia/Brisbane -Dtests.asserts=true 
-Dtests.file.encoding=UTF-8





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

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

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

[Apache Jenkins Server]

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

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

Error Message:
Failed while waiting for active collection Timeout waiting to see state for 
collection=collection1 :null Live Nodes: [127.0.0.1:39268_solr, 
127.0.0.1:39598_solr] Last available state: null

Stack Trace:
java.lang.RuntimeException: Failed while waiting for active collection
Timeout waiting to see state for collection=collection1 :null
Live Nodes: [127.0.0.1:39268_solr, 127.0.0.1:39598_solr]
Last available state: null
at 
__randomizedtesting.SeedInfo.seed([43EBEFE0B18681B5:CBBFD03A1F7AEC4D]:0)
at 
org.apache.solr.cloud.MiniSolrCloudCluster.waitForActiveCollection(MiniSolrCloudCluster.java:728)
at 
org.apache.solr.cloud.MiniSolrCloudCluster.waitForActiveCollection(MiniSolrCloudCluster.java:734)
at 
org.apache.solr.cloud.LeaderTragicEventTest.test(LeaderTragicEventTest.java:79)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988)
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:947)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 

[jira] [Commented] (SOLR-13234) Prometheus Metric Exporter Not Threadsafe

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar commented on SOLR-13234:
--

Thanks Danyal, great stuff!

A few comments:
# In SolrCloudScraper.pingAllCores and metricsForAllHosts methods, any 
exception thrown during the ping (inside the function passed to the 
sendRequestsInParallel method) will cause the http clients to leak. The call to 
closeAll should be in a try-finally clause.
# We should have some sane defaults for connection and read timeout on the 
HttpSolrClient that is created. Even better if we can set a value through the 
configuration.
# Related to the above, it'd be nice to create an HttpClient instance using 
values loaded from the configuration and use it across all the different 
CloudSolrClient and HttpSolrClient instances that are created. That way, the 
http connections can be re-used during ping and fetching metrics.

> Prometheus Metric Exporter Not Threadsafe
> -
>
> Key: SOLR-13234
> URL: https://issues.apache.org/jira/browse/SOLR-13234
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: metrics
>Affects Versions: 7.6, 8.0
>Reporter: Danyal Prout
>Assignee: Shalin Shekhar Mangar
>Priority: Minor
>  Labels: metric-collector
> Fix For: 8.x, master (9.0)
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> The Solr Prometheus Exporter collects metrics when it receives a HTTP request 
> from Prometheus. Prometheus sends this request, on its [scrape 
> interval|https://prometheus.io/docs/prometheus/latest/configuration/configuration/#scrape_config].
>  When the time taken to collect the Solr metrics is greater than the scrape 
> interval of the Prometheus server, this results in concurrent metric 
> collection occurring in this 
> [method|https://github.com/apache/lucene-solr/blob/master/solr/contrib/prometheus-exporter/src/java/org/apache/solr/prometheus/collector/SolrCollector.java#L86].
>  This method doesn’t appear to be thread safe, for instance you could have 
> concurrent modifications of a 
> [map|https://github.com/apache/lucene-solr/blob/master/solr/contrib/prometheus-exporter/src/java/org/apache/solr/prometheus/collector/SolrCollector.java#L119].
>  After a while the Solr Exporter processes becomes nondeterministic, we've 
> observed NPE and loss of metrics.
> To address this, I'm proposing the following fixes:
> 1. Read/parse the configuration at startup and make it immutable. 
>  2. Collect metrics from Solr on an interval which is controlled by the Solr 
> Exporter and cache the metric samples to return during Prometheus scraping. 
> Metric collection can be expensive, for example executing arbitrary Solr 
> searches, it's not ideal to allow for concurrent metric collection and on an 
> interval which is not defined by the Solr Exporter.
> There are also a few other performance improvements that we've made while 
> fixing this, for example using the ClusterStateProvider instead of sending 
> multiple HTTP requests to each Solr node to lookup all the cores.
> I'm currently finishing up these changes which I'll submit as a PR.



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

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

[JENKINS-EA] Lucene-Solr-8.x-Linux (64bit/jdk-13-ea+8) - Build # 197 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-8.x-Linux/197/
Java: 64bit/jdk-13-ea+8 -XX:+UseCompressedOops -XX:+UseParallelGC

4 tests failed.
FAILED:  junit.framework.TestSuite.org.apache.solr.core.TestDynamicURP

Error Message:
1 thread leaked from SUITE scope at org.apache.solr.core.TestDynamicURP: 1) 
Thread[id=269, name=Log4j2-TF-2-AsyncLoggerConfig--2, state=TIMED_WAITING, 
group=TGRP-TestDynamicURP] at 
java.base@13-ea/jdk.internal.misc.Unsafe.park(Native Method) at 
java.base@13-ea/java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:235)
 at 
java.base@13-ea/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2123)
 at 
app//com.lmax.disruptor.TimeoutBlockingWaitStrategy.waitFor(TimeoutBlockingWaitStrategy.java:38)
 at 
app//com.lmax.disruptor.ProcessingSequenceBarrier.waitFor(ProcessingSequenceBarrier.java:56)
 at 
app//com.lmax.disruptor.BatchEventProcessor.run(BatchEventProcessor.java:128)   
  at java.base@13-ea/java.lang.Thread.run(Thread.java:835)

Stack Trace:
com.carrotsearch.randomizedtesting.ThreadLeakError: 1 thread leaked from SUITE 
scope at org.apache.solr.core.TestDynamicURP: 
   1) Thread[id=269, name=Log4j2-TF-2-AsyncLoggerConfig--2, 
state=TIMED_WAITING, group=TGRP-TestDynamicURP]
at java.base@13-ea/jdk.internal.misc.Unsafe.park(Native Method)
at 
java.base@13-ea/java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:235)
at 
java.base@13-ea/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2123)
at 
app//com.lmax.disruptor.TimeoutBlockingWaitStrategy.waitFor(TimeoutBlockingWaitStrategy.java:38)
at 
app//com.lmax.disruptor.ProcessingSequenceBarrier.waitFor(ProcessingSequenceBarrier.java:56)
at 
app//com.lmax.disruptor.BatchEventProcessor.run(BatchEventProcessor.java:128)
at java.base@13-ea/java.lang.Thread.run(Thread.java:835)
at __randomizedtesting.SeedInfo.seed([54B30AC62A2D71E]:0)


FAILED:  junit.framework.TestSuite.org.apache.solr.core.TestDynamicURP

Error Message:
There are still zombie threads that couldn't be terminated:1) 
Thread[id=269, name=Log4j2-TF-2-AsyncLoggerConfig--2, state=TIMED_WAITING, 
group=TGRP-TestDynamicURP] at 
java.base@13-ea/jdk.internal.misc.Unsafe.park(Native Method) at 
java.base@13-ea/java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:235)
 at 
java.base@13-ea/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2123)
 at 
app//com.lmax.disruptor.TimeoutBlockingWaitStrategy.waitFor(TimeoutBlockingWaitStrategy.java:38)
 at 
app//com.lmax.disruptor.ProcessingSequenceBarrier.waitFor(ProcessingSequenceBarrier.java:56)
 at 
app//com.lmax.disruptor.BatchEventProcessor.run(BatchEventProcessor.java:128)   
  at java.base@13-ea/java.lang.Thread.run(Thread.java:835)

Stack Trace:
com.carrotsearch.randomizedtesting.ThreadLeakError: There are still zombie 
threads that couldn't be terminated:
   1) Thread[id=269, name=Log4j2-TF-2-AsyncLoggerConfig--2, 
state=TIMED_WAITING, group=TGRP-TestDynamicURP]
at java.base@13-ea/jdk.internal.misc.Unsafe.park(Native Method)
at 
java.base@13-ea/java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:235)
at 
java.base@13-ea/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2123)
at 
app//com.lmax.disruptor.TimeoutBlockingWaitStrategy.waitFor(TimeoutBlockingWaitStrategy.java:38)
at 
app//com.lmax.disruptor.ProcessingSequenceBarrier.waitFor(ProcessingSequenceBarrier.java:56)
at 
app//com.lmax.disruptor.BatchEventProcessor.run(BatchEventProcessor.java:128)
at java.base@13-ea/java.lang.Thread.run(Thread.java:835)
at __randomizedtesting.SeedInfo.seed([54B30AC62A2D71E]:0)


FAILED:  junit.framework.TestSuite.org.apache.solr.core.TestJmxIntegration

Error Message:
1 thread leaked from SUITE scope at org.apache.solr.core.TestJmxIntegration:
 1) Thread[id=35, name=Log4j2-TF-2-AsyncLoggerConfig--2, state=TIMED_WAITING, 
group=TGRP-TestJmxIntegration] at 
java.base@13-ea/jdk.internal.misc.Unsafe.park(Native Method) at 
java.base@13-ea/java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:235)
 at 
java.base@13-ea/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2123)
 at 
app//com.lmax.disruptor.TimeoutBlockingWaitStrategy.waitFor(TimeoutBlockingWaitStrategy.java:38)
 at 
app//com.lmax.disruptor.ProcessingSequenceBarrier.waitFor(ProcessingSequenceBarrier.java:56)
 at 
app//com.lmax.disruptor.BatchEventProcessor.run(BatchEventProcessor.java:128)   
  at 

[jira] [Commented] (LUCENE-8671) Add setting for moving FST offheap/onheap

[Ankit Jain (JIRA)]

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

Ankit Jain commented on LUCENE-8671:


bq. Ankit Jain We could maybe add a setter on BlockTreeTermsWriter?  And it'd 
write that setting into the index, and BlockTreeTermsReader would read that and 
then load FSTs on or off heap.

[~mikemccand] This sounds pretty good, except that setting is write time. Isn't 
there a way to make this read time setting? If not, isn't making this system 
property a better option?
Though, I'm happy to go with BlockTreeTermsWriter approach if nobody has better 
suggestion. Maybe [~jpountz] has any ideas.

> Add setting for moving FST offheap/onheap
> -
>
> Key: LUCENE-8671
> URL: https://issues.apache.org/jira/browse/LUCENE-8671
> Project: Lucene - Core
>  Issue Type: New Feature
>  Components: core/FSTs, core/store
>Reporter: Ankit Jain
>Priority: Minor
> Attachments: offheap_generic_settings.patch, offheap_settings.patch
>
>   Original Estimate: 24h
>  Remaining Estimate: 24h
>
> While LUCENE-8635, adds support for loading FST offheap using mmap, users do 
> not have the  flexibility to specify fields for which FST needs to be 
> offheap. This allows users to tune heap usage as per their workload.
> Ideal way will be to add an attribute to FieldInfo, where we have 
> put/getAttribute. Then FieldReader can inspect the FieldInfo and pass the 
> appropriate On/OffHeapStore when creating its FST. It can support special 
> keywords like ALL/NONE.



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

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

[JENKINS] Lucene-Solr-NightlyTests-8.x - Build # 28 - Still Unstable

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-8.x/28/

4 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.cloud.ChaosMonkeySafeLeaderWithPullReplicasTest

Error Message:
ObjectTracker found 3 object(s) that were not released!!! [InternalHttpClient, 
SolrCore, MMapDirectory] 
org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: 
org.apache.http.impl.client.InternalHttpClient  at 
org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42)
  at 
org.apache.solr.client.solrj.impl.HttpClientUtil.createClient(HttpClientUtil.java:321)
  at 
org.apache.solr.client.solrj.impl.HttpClientUtil.createClient(HttpClientUtil.java:330)
  at 
org.apache.solr.handler.IndexFetcher.createHttpClient(IndexFetcher.java:230)  
at org.apache.solr.handler.IndexFetcher.(IndexFetcher.java:272)  at 
org.apache.solr.handler.ReplicationHandler.doFetch(ReplicationHandler.java:420) 
 at org.apache.solr.cloud.RecoveryStrategy.replicate(RecoveryStrategy.java:237) 
 at 
org.apache.solr.cloud.RecoveryStrategy.doReplicateOnlyRecovery(RecoveryStrategy.java:382)
  at 
org.apache.solr.cloud.RecoveryStrategy.doRecovery(RecoveryStrategy.java:328)  
at org.apache.solr.cloud.RecoveryStrategy.run(RecoveryStrategy.java:307)  at 
com.codahale.metrics.InstrumentedExecutorService$InstrumentedRunnable.run(InstrumentedExecutorService.java:176)
  at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)  
at java.util.concurrent.FutureTask.run(FutureTask.java:266)  at 
org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:209)
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) 
 at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) 
 at java.lang.Thread.run(Thread.java:748)  
org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: 
org.apache.solr.core.SolrCore  at 
org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42)
  at org.apache.solr.core.SolrCore.(SolrCore.java:1062)  at 
org.apache.solr.core.SolrCore.(SolrCore.java:882)  at 
org.apache.solr.core.CoreContainer.createFromDescriptor(CoreContainer.java:1189)
  at org.apache.solr.core.CoreContainer.create(CoreContainer.java:1099)  at 
org.apache.solr.handler.admin.CoreAdminOperation.lambda$static$0(CoreAdminOperation.java:92)
  at 
org.apache.solr.handler.admin.CoreAdminOperation.execute(CoreAdminOperation.java:360)
  at 
org.apache.solr.handler.admin.CoreAdminHandler$CallInfo.call(CoreAdminHandler.java:396)
  at 
org.apache.solr.handler.admin.CoreAdminHandler.handleRequestBody(CoreAdminHandler.java:180)
  at 
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:199)
  at org.apache.solr.servlet.HttpSolrCall.handleAdmin(HttpSolrCall.java:736)  
at 
org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:717)  
at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:496)  at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:394)
  at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:340)
  at 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1610)
  at 
org.apache.solr.client.solrj.embedded.JettySolrRunner$DebugFilter.doFilter(JettySolrRunner.java:164)
  at 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1610)
  at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:540) 
 at 
org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255)
  at 
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1588)
  at 
org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255)
  at 
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1345)
  at 
org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:203)
  at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:480)  
at 
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1557)
  at 
org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:201)
  at 
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1247)
  at 
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:144)  
at 
org.eclipse.jetty.server.handler.gzip.GzipHandler.handle(GzipHandler.java:703)  
at 
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132) 
 at org.eclipse.jetty.server.Server.handle(Server.java:502)  at 
org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:364)  at 
org.eclipse.jetty.server.HttpChannel.run(HttpChannel.java:305)  at 
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:765)
  at 
org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:683) 
 at 

[jira] [Commented] (SOLR-12055) Enable async logging by default

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-12055:


Commit 4aa0645ea6216f556ffd8c3ad6fcb276a0cc796d in lucene-solr's branch 
refs/heads/branch_8x from erick
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=4aa0645 ]

SOLR-12055: SOLR-12753: Missed mentioning SOLR-12753 in 8.1 CHANGES.txt


> Enable async logging by default
> ---
>
> Key: SOLR-12055
> URL: https://issues.apache.org/jira/browse/SOLR-12055
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: logging
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Minor
> Attachments: SOLR-12055-rollback.patch, 
> SOLR-12055-slh-interim1.patch, SOLR-12055-slh-interim1.patch, 
> SOLR-12055.patch, SOLR-12055.patch, SOLR-12055.patch, SOLR-12055.patch, 
> SOLR-12055.patch
>
>
> When SOLR-7887 is done, switching to async logging will be a simple change to 
> the config files for log4j2. This will reduce contention and increase 
> throughput generally and logging in particular.
> There's a discussion of the pros/cons here: 
> https://logging.apache.org/log4j/2.0/manual/async.html
> An alternative is to put a note in the Ref Guide about how to enable async 
> logging.
> I guess even if we enable async by default the ref guide still needs a note 
> about how to _disable_ it.



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

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

[jira] [Commented] (SOLR-12753) Async logging ring buffer and OOM error

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-12753:


Commit 07cc2d98ef97b78a5161e451ef18ed899f5d7dd3 in lucene-solr's branch 
refs/heads/branch_8x from erick
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=07cc2d9 ]

SOLR-12055: Enable async logging by default SOLR-12753: Async logging ring 
buffer and OOM error

(cherry picked from commit 0de3905)


> Async logging ring buffer and OOM error
> ---
>
> Key: SOLR-12753
> URL: https://issues.apache.org/jira/browse/SOLR-12753
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: logging
>Affects Versions: 7.5
>Reporter: Andrzej Bialecki 
>Assignee: Erick Erickson
>Priority: Major
> Attachments: SOLR-12753.patch
>
>
> I’m using a simulated environment for autoscaling tests, which may create 
> some pretty degenerate cases (like collections with 50,000 replicas and 
> Policy calculations over these, times 500 nodes).
> I noticed that when I turned on debug logging I occasionally would get an OOM 
> error, and the heap dump showed that the biggest objects were a bunch of 
> extremely large strings in the async logger’s ring buffer. These strings were 
> admittedly extremely large (million chars or so) but the previously used sync 
> logging didn’t have any issue with them, because they were consumed one by 
> one.
> For sure, Solr should not attempt to be logging multi-megabyte data. But I 
> also feel like the framework could perhaps help here by enforcing large but 
> sane limits on maximum size of log messages.



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

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

[jira] [Resolved] (SOLR-9843) DocValuesNotIndexedTest failures indicating exepected documents aren't found

[Erick Erickson (JIRA)]

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

Erick Erickson resolved SOLR-9843.
--
   Resolution: Fixed
Fix Version/s: 8.1
   master (9.0)

This hasn't failed in the last 6 weeks, and I couldn't get it to fail in 1,000 
runs. So closing for now, I'll be monitoring build failures to see if it recurs.

> DocValuesNotIndexedTest failures indicating exepected documents aren't found
> 
>
> Key: SOLR-9843
> URL: https://issues.apache.org/jira/browse/SOLR-9843
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Major
> Fix For: master (9.0), 8.1
>
> Attachments: SOLR-9843.patch, SOLR-9843.patch, fail.txt, 
> shard3_replica1.txt, shard_3_searchers.txt
>
>
> I'll have to do a few iterations on the Jenkins builds since I can't get this 
> to fail locally. Marking as "blocker" since I'll probably have to put some 
> extra code in that I want to be sure is removed before we cut any new 
> releases.



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

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

Re: Welcome Jason Gerlowski to the PMC

[Anshum Gupta]

Congratulations and welcome Jason!

  Anshum


> On Feb 22, 2019, at 7:21 AM, Jan Høydahl  wrote:
> 
> I am pleased to announce that Jason Gerlowski has accepted the PMC's 
> invitation to join.
> 
> Welcome Jason!
> 
> --
> Jan Høydahl, search solution architect
> Cominvent AS - www.cominvent.com
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
> 

[jira] [Resolved] (SOLR-12732) TestLogWatcher failure on Jenkins

[Erick Erickson (JIRA)]

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

Erick Erickson resolved SOLR-12732.
---
Resolution: Fixed

As part of SOLR-12055, this has been pretty heavily rewritten, so I'll close it 
and monitor the build failures to see if it comes back.

> TestLogWatcher failure on Jenkins
> -
>
> Key: SOLR-12732
> URL: https://issues.apache.org/jira/browse/SOLR-12732
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: logging
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Minor
> Attachments: SOLR-12732.patch
>
>
> I'm 99% certain this is a test artifact, I think I see the problem. It'll 
> take me a lot of beasting to nail it though.
> Working hypothesis is that the when we test for whether the new searcher has 
> no messages, we can test for no messages being logged against the watcher 
> before the new one _really_ gets active.



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

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

[jira] [Resolved] (SOLR-12753) Async logging ring buffer and OOM error

[Erick Erickson (JIRA)]

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

Erick Erickson resolved SOLR-12753.
---
   Resolution: Fixed
Fix Version/s: 8.1
   master (9.0)

Fixed in SOLR-12055.

> Async logging ring buffer and OOM error
> ---
>
> Key: SOLR-12753
> URL: https://issues.apache.org/jira/browse/SOLR-12753
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: logging
>Affects Versions: 7.5
>Reporter: Andrzej Bialecki 
>Assignee: Erick Erickson
>Priority: Major
> Fix For: master (9.0), 8.1
>
> Attachments: SOLR-12753.patch
>
>
> I’m using a simulated environment for autoscaling tests, which may create 
> some pretty degenerate cases (like collections with 50,000 replicas and 
> Policy calculations over these, times 500 nodes).
> I noticed that when I turned on debug logging I occasionally would get an OOM 
> error, and the heap dump showed that the biggest objects were a bunch of 
> extremely large strings in the async logger’s ring buffer. These strings were 
> admittedly extremely large (million chars or so) but the previously used sync 
> logging didn’t have any issue with them, because they were consumed one by 
> one.
> For sure, Solr should not attempt to be logging multi-megabyte data. But I 
> also feel like the framework could perhaps help here by enforcing large but 
> sane limits on maximum size of log messages.



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

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

[jira] [Resolved] (SOLR-12055) Enable async logging by default

[Erick Erickson (JIRA)]

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

Erick Erickson resolved SOLR-12055.
---
   Resolution: Fixed
Fix Version/s: 8.1
   master (9.0)

Including fix for ring buffer OOM

> Enable async logging by default
> ---
>
> Key: SOLR-12055
> URL: https://issues.apache.org/jira/browse/SOLR-12055
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: logging
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Minor
> Fix For: master (9.0), 8.1
>
> Attachments: SOLR-12055-rollback.patch, 
> SOLR-12055-slh-interim1.patch, SOLR-12055-slh-interim1.patch, 
> SOLR-12055.patch, SOLR-12055.patch, SOLR-12055.patch, SOLR-12055.patch, 
> SOLR-12055.patch
>
>
> When SOLR-7887 is done, switching to async logging will be a simple change to 
> the config files for log4j2. This will reduce contention and increase 
> throughput generally and logging in particular.
> There's a discussion of the pros/cons here: 
> https://logging.apache.org/log4j/2.0/manual/async.html
> An alternative is to put a note in the Ref Guide about how to enable async 
> logging.
> I guess even if we enable async by default the ref guide still needs a note 
> about how to _disable_ it.



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

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

[jira] [Commented] (SOLR-12753) Async logging ring buffer and OOM error

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-12753:


Commit 4aa0645ea6216f556ffd8c3ad6fcb276a0cc796d in lucene-solr's branch 
refs/heads/branch_8x from erick
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=4aa0645 ]

SOLR-12055: SOLR-12753: Missed mentioning SOLR-12753 in 8.1 CHANGES.txt


> Async logging ring buffer and OOM error
> ---
>
> Key: SOLR-12753
> URL: https://issues.apache.org/jira/browse/SOLR-12753
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: logging
>Affects Versions: 7.5
>Reporter: Andrzej Bialecki 
>Assignee: Erick Erickson
>Priority: Major
> Attachments: SOLR-12753.patch
>
>
> I’m using a simulated environment for autoscaling tests, which may create 
> some pretty degenerate cases (like collections with 50,000 replicas and 
> Policy calculations over these, times 500 nodes).
> I noticed that when I turned on debug logging I occasionally would get an OOM 
> error, and the heap dump showed that the biggest objects were a bunch of 
> extremely large strings in the async logger’s ring buffer. These strings were 
> admittedly extremely large (million chars or so) but the previously used sync 
> logging didn’t have any issue with them, because they were consumed one by 
> one.
> For sure, Solr should not attempt to be logging multi-megabyte data. But I 
> also feel like the framework could perhaps help here by enforcing large but 
> sane limits on maximum size of log messages.



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

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

[jira] [Commented] (SOLR-12753) Async logging ring buffer and OOM error

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-12753:


Commit 4aa0645ea6216f556ffd8c3ad6fcb276a0cc796d in lucene-solr's branch 
refs/heads/branch_8x from erick
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=4aa0645 ]

SOLR-12055: SOLR-12753: Missed mentioning SOLR-12753 in 8.1 CHANGES.txt


> Async logging ring buffer and OOM error
> ---
>
> Key: SOLR-12753
> URL: https://issues.apache.org/jira/browse/SOLR-12753
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: logging
>Affects Versions: 7.5
>Reporter: Andrzej Bialecki 
>Assignee: Erick Erickson
>Priority: Major
> Attachments: SOLR-12753.patch
>
>
> I’m using a simulated environment for autoscaling tests, which may create 
> some pretty degenerate cases (like collections with 50,000 replicas and 
> Policy calculations over these, times 500 nodes).
> I noticed that when I turned on debug logging I occasionally would get an OOM 
> error, and the heap dump showed that the biggest objects were a bunch of 
> extremely large strings in the async logger’s ring buffer. These strings were 
> admittedly extremely large (million chars or so) but the previously used sync 
> logging didn’t have any issue with them, because they were consumed one by 
> one.
> For sure, Solr should not attempt to be logging multi-megabyte data. But I 
> also feel like the framework could perhaps help here by enforcing large but 
> sane limits on maximum size of log messages.



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

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

[jira] [Commented] (SOLR-12055) Enable async logging by default

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-12055:


Commit 4530c8041ff0c7b7bf68f2412ce14a3bca2de1db in lucene-solr's branch 
refs/heads/branch_8x from erick
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=4530c80 ]

SOLR-12055: Enable async logging by default SOLR-12753: Async logging ring 
buffer and OOM error


> Enable async logging by default
> ---
>
> Key: SOLR-12055
> URL: https://issues.apache.org/jira/browse/SOLR-12055
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: logging
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Minor
> Attachments: SOLR-12055-rollback.patch, 
> SOLR-12055-slh-interim1.patch, SOLR-12055-slh-interim1.patch, 
> SOLR-12055.patch, SOLR-12055.patch, SOLR-12055.patch, SOLR-12055.patch, 
> SOLR-12055.patch
>
>
> When SOLR-7887 is done, switching to async logging will be a simple change to 
> the config files for log4j2. This will reduce contention and increase 
> throughput generally and logging in particular.
> There's a discussion of the pros/cons here: 
> https://logging.apache.org/log4j/2.0/manual/async.html
> An alternative is to put a note in the Ref Guide about how to enable async 
> logging.
> I guess even if we enable async by default the ref guide still needs a note 
> about how to _disable_ it.



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

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

[jira] [Commented] (SOLR-12055) Enable async logging by default

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-12055:


Commit 07cc2d98ef97b78a5161e451ef18ed899f5d7dd3 in lucene-solr's branch 
refs/heads/branch_8x from erick
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=07cc2d9 ]

SOLR-12055: Enable async logging by default SOLR-12753: Async logging ring 
buffer and OOM error

(cherry picked from commit 0de3905)


> Enable async logging by default
> ---
>
> Key: SOLR-12055
> URL: https://issues.apache.org/jira/browse/SOLR-12055
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: logging
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Minor
> Attachments: SOLR-12055-rollback.patch, 
> SOLR-12055-slh-interim1.patch, SOLR-12055-slh-interim1.patch, 
> SOLR-12055.patch, SOLR-12055.patch, SOLR-12055.patch, SOLR-12055.patch, 
> SOLR-12055.patch
>
>
> When SOLR-7887 is done, switching to async logging will be a simple change to 
> the config files for log4j2. This will reduce contention and increase 
> throughput generally and logging in particular.
> There's a discussion of the pros/cons here: 
> https://logging.apache.org/log4j/2.0/manual/async.html
> An alternative is to put a note in the Ref Guide about how to enable async 
> logging.
> I guess even if we enable async by default the ref guide still needs a note 
> about how to _disable_ it.



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

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

[jira] [Commented] (SOLR-12753) Async logging ring buffer and OOM error

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-12753:


Commit 4530c8041ff0c7b7bf68f2412ce14a3bca2de1db in lucene-solr's branch 
refs/heads/branch_8x from erick
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=4530c80 ]

SOLR-12055: Enable async logging by default SOLR-12753: Async logging ring 
buffer and OOM error


> Async logging ring buffer and OOM error
> ---
>
> Key: SOLR-12753
> URL: https://issues.apache.org/jira/browse/SOLR-12753
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: logging
>Affects Versions: 7.5
>Reporter: Andrzej Bialecki 
>Assignee: Erick Erickson
>Priority: Major
> Attachments: SOLR-12753.patch
>
>
> I’m using a simulated environment for autoscaling tests, which may create 
> some pretty degenerate cases (like collections with 50,000 replicas and 
> Policy calculations over these, times 500 nodes).
> I noticed that when I turned on debug logging I occasionally would get an OOM 
> error, and the heap dump showed that the biggest objects were a bunch of 
> extremely large strings in the async logger’s ring buffer. These strings were 
> admittedly extremely large (million chars or so) but the previously used sync 
> logging didn’t have any issue with them, because they were consumed one by 
> one.
> For sure, Solr should not attempt to be logging multi-megabyte data. But I 
> also feel like the framework could perhaps help here by enforcing large but 
> sane limits on maximum size of log messages.



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

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

[jira] [Commented] (SOLR-12055) Enable async logging by default

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-12055:


Commit 0de3905ce71c53b91b28972fb327d35c6a604e6b in lucene-solr's branch 
refs/heads/master from Erick Erickson
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=0de3905 ]

SOLR-12055: Enable async logging by default SOLR-12753: Async logging ring 
buffer and OOM error


> Enable async logging by default
> ---
>
> Key: SOLR-12055
> URL: https://issues.apache.org/jira/browse/SOLR-12055
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: logging
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Minor
> Attachments: SOLR-12055-rollback.patch, 
> SOLR-12055-slh-interim1.patch, SOLR-12055-slh-interim1.patch, 
> SOLR-12055.patch, SOLR-12055.patch, SOLR-12055.patch, SOLR-12055.patch, 
> SOLR-12055.patch
>
>
> When SOLR-7887 is done, switching to async logging will be a simple change to 
> the config files for log4j2. This will reduce contention and increase 
> throughput generally and logging in particular.
> There's a discussion of the pros/cons here: 
> https://logging.apache.org/log4j/2.0/manual/async.html
> An alternative is to put a note in the Ref Guide about how to enable async 
> logging.
> I guess even if we enable async by default the ref guide still needs a note 
> about how to _disable_ it.



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

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

[jira] [Commented] (SOLR-12753) Async logging ring buffer and OOM error

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-12753:


Commit 0de3905ce71c53b91b28972fb327d35c6a604e6b in lucene-solr's branch 
refs/heads/master from Erick Erickson
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=0de3905 ]

SOLR-12055: Enable async logging by default SOLR-12753: Async logging ring 
buffer and OOM error


> Async logging ring buffer and OOM error
> ---
>
> Key: SOLR-12753
> URL: https://issues.apache.org/jira/browse/SOLR-12753
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: logging
>Affects Versions: 7.5
>Reporter: Andrzej Bialecki 
>Assignee: Erick Erickson
>Priority: Major
> Attachments: SOLR-12753.patch
>
>
> I’m using a simulated environment for autoscaling tests, which may create 
> some pretty degenerate cases (like collections with 50,000 replicas and 
> Policy calculations over these, times 500 nodes).
> I noticed that when I turned on debug logging I occasionally would get an OOM 
> error, and the heap dump showed that the biggest objects were a bunch of 
> extremely large strings in the async logger’s ring buffer. These strings were 
> admittedly extremely large (million chars or so) but the previously used sync 
> logging didn’t have any issue with them, because they were consumed one by 
> one.
> For sure, Solr should not attempt to be logging multi-megabyte data. But I 
> also feel like the framework could perhaps help here by enforcing large but 
> sane limits on maximum size of log messages.



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

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

[jira] [Commented] (SOLR-13264) unexpected autoscaling set-trigger response

[Christine Poerschke (JIRA)]

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

Christine Poerschke commented on SOLR-13264:


Attached revised patch which includes a 
{{IndexSizeTriggerTest.testValidProperties}} test. The test or the code change 
is currently incomplete i.e. it fails like this:
{code}
[junit4]> Throwable #1: java.lang.AssertionError: Invalid _PROP constants: 
[__bytes__, __docs__, violationType, aboveSize, belowSize]
{code}

[~ab] - would you perhaps have any thoughts on this ticket?

> unexpected autoscaling set-trigger response
> ---
>
> Key: SOLR-13264
> URL: https://issues.apache.org/jira/browse/SOLR-13264
> Project: Solr
>  Issue Type: Bug
>  Components: AutoScaling
>Reporter: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-13264.patch, SOLR-13264.patch
>
>
> Steps to reproduce:
> {code}
> ./bin/solr start -cloud -noprompt
> ./bin/solr create -c demo -d _default -shards 1 -replicationFactor 1
> curl "http://localhost:8983/solr/admin/autoscaling; -d'
> {
>   "set-trigger" : {
> "name" : "index_size_trigger",
> "event" : "indexSize",
> "aboveDocs" : 12345,
> "aboveOp" : "SPLITSHARD",
> "enabled" : true,
> "actions" : [
>   {
> "name" : "compute_plan",
> "class": "solr.ComputePlanAction"
>   }
> ]
>   }
> }
> '
> ./bin/solr stop -all
> {code}
> The {{aboveOp}} is documented on 
> https://lucene.apache.org/solr/guide/7_6/solrcloud-autoscaling-triggers.html#index-size-trigger
>  and logically should be accepted (even though it is actually the default) 
> but unexpectedly an error message is returned {{"Error validating trigger 
> config index_size_trigger: 
> TriggerValidationException\{name=index_size_trigger, 
> details='\{aboveOp=unknown property\}'\}"}}.
> From a quick look it seems that in the {{IndexSizeTrigger}} constructor 
> additional values need to be passed to the {{TriggerUtils.validProperties}} 
> method i.e. aboveOp, belowOp and maybe others too i.e. 
> aboveSize/belowSize/etc. Illustrative patch to follow. Thank you.



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

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

[jira] [Updated] (SOLR-13264) unexpected autoscaling set-trigger response

[Christine Poerschke (JIRA)]

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

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

> unexpected autoscaling set-trigger response
> ---
>
> Key: SOLR-13264
> URL: https://issues.apache.org/jira/browse/SOLR-13264
> Project: Solr
>  Issue Type: Bug
>  Components: AutoScaling
>Reporter: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-13264.patch, SOLR-13264.patch
>
>
> Steps to reproduce:
> {code}
> ./bin/solr start -cloud -noprompt
> ./bin/solr create -c demo -d _default -shards 1 -replicationFactor 1
> curl "http://localhost:8983/solr/admin/autoscaling; -d'
> {
>   "set-trigger" : {
> "name" : "index_size_trigger",
> "event" : "indexSize",
> "aboveDocs" : 12345,
> "aboveOp" : "SPLITSHARD",
> "enabled" : true,
> "actions" : [
>   {
> "name" : "compute_plan",
> "class": "solr.ComputePlanAction"
>   }
> ]
>   }
> }
> '
> ./bin/solr stop -all
> {code}
> The {{aboveOp}} is documented on 
> https://lucene.apache.org/solr/guide/7_6/solrcloud-autoscaling-triggers.html#index-size-trigger
>  and logically should be accepted (even though it is actually the default) 
> but unexpectedly an error message is returned {{"Error validating trigger 
> config index_size_trigger: 
> TriggerValidationException\{name=index_size_trigger, 
> details='\{aboveOp=unknown property\}'\}"}}.
> From a quick look it seems that in the {{IndexSizeTrigger}} constructor 
> additional values need to be passed to the {{TriggerUtils.validProperties}} 
> method i.e. aboveOp, belowOp and maybe others too i.e. 
> aboveSize/belowSize/etc. Illustrative patch to follow. Thank you.



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

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

Re:Welcome Jason Gerlowski to the PMC

[Christine Poerschke (BLOOMBERG/ LONDON)]

Welcome Jason!

From: dev@lucene.apache.org At: 02/22/19 15:22:06To:  dev@lucene.apache.org
Subject: Welcome Jason Gerlowski to the PMC 

I am pleased to announce that Jason Gerlowski has accepted the PMC's invitation 
to join.

Welcome Jason!

--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com


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

Re: Welcome Jason Gerlowski to the PMC

[Shalin Shekhar Mangar]

Congratulations and welcome Jason!

On Fri, Feb 22, 2019 at 7:21 AM Jan Høydahl  wrote:

> I am pleased to announce that Jason Gerlowski has accepted the PMC's
> invitation to join.
>
> Welcome Jason!
>
> --
> Jan Høydahl, search solution architect
> Cominvent AS - www.cominvent.com
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

-- 
Regards,
Shalin Shekhar Mangar.

Re: Welcome Jason Gerlowski to the PMC

[Dawid Weiss]

Welcome Jason!

On Fri, Feb 22, 2019 at 6:51 PM Noble Paul  wrote:
>
> Welcome Jason
>
> On Sat, Feb 23, 2019 at 4:39 AM Tomás Fernández Löbbe
>  wrote:
> >
> > Welcome Jason!
> >
> > On Fri, Feb 22, 2019 at 8:57 AM Alan Woodward  wrote:
> >>
> >> Welcome Jason!
> >>
> >> > On 22 Feb 2019, at 15:21, Jan Høydahl  wrote:
> >> >
> >> > I am pleased to announce that Jason Gerlowski has accepted the PMC's 
> >> > invitation to join.
> >> >
> >> > Welcome Jason!
> >> >
> >> > --
> >> > Jan Høydahl, search solution architect
> >> > Cominvent AS - www.cominvent.com
> >> >
> >> >
> >> > -
> >> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> >> > For additional commands, e-mail: dev-h...@lucene.apache.org
> >> >
> >>
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> >> For additional commands, e-mail: dev-h...@lucene.apache.org
> >>
>
>
> --
> -
> Noble Paul
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>

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

[GitHub] danmuzi opened a new pull request #585: LUCENE-8698: Fix replaceIgnoreCase method bug in EscapeQuerySyntaxImpl

[GitBox]

danmuzi opened a new pull request #585: LUCENE-8698: Fix replaceIgnoreCase 
method bug in EscapeQuerySyntaxImpl
URL: https://github.com/apache/lucene-solr/pull/585
 
 
   This PR is about a bug fix for the replaceIgnoreCase method in the 
EscapeQuerySyntaxImpl class.
   Current latest code can occur **StringIndexOutOfBoundsException**.
   
   Please refer to the following JIRA link:
   [LUCENE-8698](https://issues.apache.org/jira/browse/LUCENE-8698)
   
   Signed-off-by: Namgyu Kim 


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

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

[jira] [Commented] (SOLR-13261) Make SortableTextField work with export/streaming

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-13261:


Commit cf1e3c46032cdd0a96e8f982893930ac1e1319ac in lucene-solr's branch 
refs/heads/branch_8x from Erick Erickson
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=cf1e3c4 ]

SOLR-13261: Make SortableTextField work with export/streaming

(cherry picked from commit 6b4e90617ddb5a9897070bc60e2c6e78d8488f12)


> Make SortableTextField work with export/streaming
> -
>
> Key: SOLR-13261
> URL: https://issues.apache.org/jira/browse/SOLR-13261
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 7.7, 8.0, master (9.0)
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Major
> Attachments: SOLR-13261.patch, SOLR-13261.patch
>
>
> ExportWriter (and perhaps other places) explicitly tests for certain field 
> types and error out with "Export fields must either be one of the following 
> types: int,float,long,double,string,date,boolean"
> It seems perfectly legal to export SortableTextField as well as it's a DV 
> field. How desirable that would be is an open question.



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

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

[jira] [Resolved] (SOLR-13261) Make SortableTextField work with export/streaming

[Erick Erickson (JIRA)]

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

Erick Erickson resolved SOLR-13261.
---
   Resolution: Fixed
Fix Version/s: master (9.0)
   8.1

> Make SortableTextField work with export/streaming
> -
>
> Key: SOLR-13261
> URL: https://issues.apache.org/jira/browse/SOLR-13261
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 7.7, 8.0, master (9.0)
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Major
> Fix For: 8.1, master (9.0)
>
> Attachments: SOLR-13261.patch, SOLR-13261.patch
>
>
> ExportWriter (and perhaps other places) explicitly tests for certain field 
> types and error out with "Export fields must either be one of the following 
> types: int,float,long,double,string,date,boolean"
> It seems perfectly legal to export SortableTextField as well as it's a DV 
> field. How desirable that would be is an open question.



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

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

[jira] [Commented] (SOLR-13261) Make SortableTextField work with export/streaming

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-13261:


Commit 6b4e90617ddb5a9897070bc60e2c6e78d8488f12 in lucene-solr's branch 
refs/heads/master from Erick Erickson
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=6b4e906 ]

SOLR-13261: Make SortableTextField work with export/streaming


> Make SortableTextField work with export/streaming
> -
>
> Key: SOLR-13261
> URL: https://issues.apache.org/jira/browse/SOLR-13261
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 7.7, 8.0, master (9.0)
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Major
> Attachments: SOLR-13261.patch, SOLR-13261.patch
>
>
> ExportWriter (and perhaps other places) explicitly tests for certain field 
> types and error out with "Export fields must either be one of the following 
> types: int,float,long,double,string,date,boolean"
> It seems perfectly legal to export SortableTextField as well as it's a DV 
> field. How desirable that would be is an open question.



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

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

[jira] [Updated] (SOLR-13261) Make SortableTextField work with export/streaming

[Erick Erickson (JIRA)]

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

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

> Make SortableTextField work with export/streaming
> -
>
> Key: SOLR-13261
> URL: https://issues.apache.org/jira/browse/SOLR-13261
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 7.7, 8.0, master (9.0)
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Major
> Attachments: SOLR-13261.patch, SOLR-13261.patch
>
>
> ExportWriter (and perhaps other places) explicitly tests for certain field 
> types and error out with "Export fields must either be one of the following 
> types: int,float,long,double,string,date,boolean"
> It seems perfectly legal to export SortableTextField as well as it's a DV 
> field. How desirable that would be is an open question.



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

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

[jira] [Updated] (SOLR-13261) Make SortableTextField work with export/streaming

[Erick Erickson (JIRA)]

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

Erick Erickson updated SOLR-13261:
--
Summary: Make SortableTextField work with export/streaming  (was: Should 
SortableTextField be allowed in export?)

> Make SortableTextField work with export/streaming
> -
>
> Key: SOLR-13261
> URL: https://issues.apache.org/jira/browse/SOLR-13261
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 7.7, 8.0, master (9.0)
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Major
> Attachments: SOLR-13261.patch
>
>
> ExportWriter (and perhaps other places) explicitly tests for certain field 
> types and error out with "Export fields must either be one of the following 
> types: int,float,long,double,string,date,boolean"
> It seems perfectly legal to export SortableTextField as well as it's a DV 
> field. How desirable that would be is an open question.



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

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

[JENKINS-EA] Lucene-Solr-master-Linux (64bit/jdk-12-ea+shipilev-fastdebug) - Build # 23711 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/23711/
Java: 64bit/jdk-12-ea+shipilev-fastdebug -XX:-UseCompressedOops 
-XX:+UseConcMarkSweepGC

3 tests failed.
FAILED:  org.apache.solr.client.solrj.TestLBHttp2SolrClient.testSimple

Error Message:
Timeout occured while waiting response from server at: 
http://127.0.0.1:46433/solr/collection1/select?q=*%3A*=javabin=2

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: Timeout occured while waiting 
response from server at: 
http://127.0.0.1:46433/solr/collection1/select?q=*%3A*=javabin=2
at 
__randomizedtesting.SeedInfo.seed([170AC7859A5A254:39C388867E567685]:0)
at 
org.apache.solr.client.solrj.impl.Http2SolrClient.request(Http2SolrClient.java:400)
at 
org.apache.solr.client.solrj.impl.Http2SolrClient.request(Http2SolrClient.java:732)
at 
org.apache.solr.client.solrj.impl.LBSolrClient.request(LBSolrClient.java:605)
at 
org.apache.solr.client.solrj.impl.LBSolrClient.request(LBSolrClient.java:581)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:207)
at org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:987)
at org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:1002)
at 
org.apache.solr.client.solrj.TestLBHttp2SolrClient.testSimple(TestLBHttp2SolrClient.java:143)
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:567)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988)
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:947)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894)
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 

[jira] [Commented] (SOLR-13261) Make SortableTextField work with export/streaming

[Erick Erickson (JIRA)]

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

Erick Erickson commented on SOLR-13261:
---

Final patch with CHANGES.txt. No code changes from the patch before.

> Make SortableTextField work with export/streaming
> -
>
> Key: SOLR-13261
> URL: https://issues.apache.org/jira/browse/SOLR-13261
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 7.7, 8.0, master (9.0)
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Major
> Attachments: SOLR-13261.patch, SOLR-13261.patch
>
>
> ExportWriter (and perhaps other places) explicitly tests for certain field 
> types and error out with "Export fields must either be one of the following 
> types: int,float,long,double,string,date,boolean"
> It seems perfectly legal to export SortableTextField as well as it's a DV 
> field. How desirable that would be is an open question.



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

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

[jira] [Updated] (SOLR-9882) exceeding timeAllowed causes ClassCastException: BasicResultContext cannot be cast to SolrDocumentList

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev updated SOLR-9882:
---
Attachment: SOLR-9882.patch

> exceeding timeAllowed causes ClassCastException: BasicResultContext cannot be 
> cast to SolrDocumentList
> --
>
> Key: SOLR-9882
> URL: https://issues.apache.org/jira/browse/SOLR-9882
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 6.3
>Reporter: Yago Riveiro
>Assignee: Mikhail Khludnev
>Priority: Major
> Attachments: SOLR-9882-7987.patch, SOLR-9882.patch, SOLR-9882.patch, 
> SOLR-9882.patch, SOLR-9882.patch, SOLR-9882.patch, SOLR-9882.patch, 
> SOLR-9882.patch, SOLR-9882.patch, SOLR-9882.patch, SOLR-9882.patch, 
> SOLR-9882.patch
>
>
> After talk with [~yo...@apache.org] in the mailing list I open this Jira 
> ticket
> I'm hitting this bug in Solr 6.3.0.
> null:java.lang.ClassCastException:
> org.apache.solr.response.BasicResultContext cannot be cast to
> org.apache.solr.common.SolrDocumentList
> at
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:315)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:153)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:2213)
> at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:654)
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:460)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:303)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:254)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1668)
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:581)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:226)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1160)
> at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:511)
> at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1092)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:213)
> at
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:119)
> at
> org.eclipse.jetty.server.handler.StatisticsHandler.handle(StatisticsHandler.java:169)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)
> at org.eclipse.jetty.server.Server.handle(Server.java:518)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:308)
> at
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:244)
> at
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:273)
> at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:95)
> at
> org.eclipse.jetty.io.SelectChannelEndPoint$2.run(SelectChannelEndPoint.java:93)
> at
> org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.produceAndRun(ExecuteProduceConsume.java:246)
> at
> org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.run(ExecuteProduceConsume.java:156)
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:654)
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:572)
> at java.lang.Thread.run(Thread.java:745)



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

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

[JENKINS] Lucene-Solr-Tests-master - Build # 3185 - Unstable

[Apache Jenkins Server]

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

1 tests failed.
FAILED:  
org.apache.solr.client.solrj.io.stream.MathExpressionTest.testGammaDistribution

Error Message:
0.8017221673680053 0.8080404171036486

Stack Trace:
java.lang.AssertionError: 0.8017221673680053 0.8080404171036486
at 
__randomizedtesting.SeedInfo.seed([CD2379F16C1782C5:F059525F4F6F28D2]:0)
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.assertTrue(Assert.java:41)
at 
org.apache.solr.client.solrj.io.stream.MathExpressionTest.testGammaDistribution(MathExpressionTest.java:4528)
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:1750)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988)
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:947)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894)
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 16392 lines...]
   [junit4] Suite: org.apache.solr.client.solrj.io.stream.MathExpressionTest
   [junit4]   2> Creating dataDir: 

[jira] [Commented] (SOLR-12708) Async collection actions should not hide failures

[JIRA]

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

Tomás Fernández Löbbe commented on SOLR-12708:
--

This didn't make it to 7.7.1 (I didn't know it was so imminent). I'll merge to 
7_7 anyway in case there is a 7.7.2 at some point

> Async collection actions should not hide failures
> -
>
> Key: SOLR-12708
> URL: https://issues.apache.org/jira/browse/SOLR-12708
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Admin UI, Backup/Restore
>Affects Versions: 7.4
>Reporter: Mano Kovacs
>Assignee: Tomás Fernández Löbbe
>Priority: Major
> Fix For: 8.x, master (9.0)
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> Async collection API may hide failures compared to sync version. 
> [OverseerCollectionMessageHandler::processResponses|https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/cloud/api/collections/OverseerCollectionMessageHandler.java#L744]
>  structures errors differently in the response, that hides failures from most 
> evaluators. RestoreCmd did not receive, nor handle async addReplica issues.
> Sample create collection sync and async result with invalid solrconfig.xml:
> {noformat}
> {
> "responseHeader":{
> "status":0,
> "QTime":32104},
> "failure":{
> "localhost:8983_solr":"org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException:Error
>  from server at http://localhost:8983/solr: Error CREATEing SolrCore 
> 'name4_shard1_replica_n1': Unable to create core [name4_shard1_replica_n1] 
> Caused by: The content of elements must consist of well-formed character data 
> or markup.",
> "localhost:8983_solr":"org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException:Error
>  from server at http://localhost:8983/solr: Error CREATEing SolrCore 
> 'name4_shard2_replica_n2': Unable to create core [name4_shard2_replica_n2] 
> Caused by: The content of elements must consist of well-formed character data 
> or markup.",
> "localhost:8983_solr":"org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException:Error
>  from server at http://localhost:8983/solr: Error CREATEing SolrCore 
> 'name4_shard1_replica_n2': Unable to create core [name4_shard1_replica_n2] 
> Caused by: The content of elements must consist of well-formed character data 
> or markup.",
> "localhost:8983_solr":"org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException:Error
>  from server at http://localhost:8983/solr: Error CREATEing SolrCore 
> 'name4_shard2_replica_n1': Unable to create core [name4_shard2_replica_n1] 
> Caused by: The content of elements must consist of well-formed character data 
> or markup."}
> }
> {noformat}
> vs async:
> {noformat}
> {
> "responseHeader":{
> "status":0,
> "QTime":3},
> "success":{
> "localhost:8983_solr":{
> "responseHeader":{
> "status":0,
> "QTime":12}},
> "localhost:8983_solr":{
> "responseHeader":{
> "status":0,
> "QTime":3}},
> "localhost:8983_solr":{
> "responseHeader":{
> "status":0,
> "QTime":11}},
> "localhost:8983_solr":{
> "responseHeader":{
> "status":0,
> "QTime":12}}},
> "myTaskId2709146382836":{
> "responseHeader":{
> "status":0,
> "QTime":1},
> "STATUS":"failed",
> "Response":"Error CREATEing SolrCore 'name_shard2_replica_n2': Unable to 
> create core [name_shard2_replica_n2] Caused by: The content of elements must 
> consist of well-formed character data or markup."},
> "status":{
> "state":"completed",
> "msg":"found [myTaskId] in completed tasks"}}
> {noformat}
> Proposing adding failure node to the results, keeping backward compatible but 
> correct result.



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

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

[jira] [Updated] (SOLR-12708) Async collection actions should not hide failures

[JIRA]

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

Tomás Fernández Löbbe updated SOLR-12708:
-
Fix Version/s: (was: 7.7.1)

> Async collection actions should not hide failures
> -
>
> Key: SOLR-12708
> URL: https://issues.apache.org/jira/browse/SOLR-12708
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Admin UI, Backup/Restore
>Affects Versions: 7.4
>Reporter: Mano Kovacs
>Assignee: Tomás Fernández Löbbe
>Priority: Major
> Fix For: 8.x, master (9.0)
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> Async collection API may hide failures compared to sync version. 
> [OverseerCollectionMessageHandler::processResponses|https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/cloud/api/collections/OverseerCollectionMessageHandler.java#L744]
>  structures errors differently in the response, that hides failures from most 
> evaluators. RestoreCmd did not receive, nor handle async addReplica issues.
> Sample create collection sync and async result with invalid solrconfig.xml:
> {noformat}
> {
> "responseHeader":{
> "status":0,
> "QTime":32104},
> "failure":{
> "localhost:8983_solr":"org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException:Error
>  from server at http://localhost:8983/solr: Error CREATEing SolrCore 
> 'name4_shard1_replica_n1': Unable to create core [name4_shard1_replica_n1] 
> Caused by: The content of elements must consist of well-formed character data 
> or markup.",
> "localhost:8983_solr":"org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException:Error
>  from server at http://localhost:8983/solr: Error CREATEing SolrCore 
> 'name4_shard2_replica_n2': Unable to create core [name4_shard2_replica_n2] 
> Caused by: The content of elements must consist of well-formed character data 
> or markup.",
> "localhost:8983_solr":"org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException:Error
>  from server at http://localhost:8983/solr: Error CREATEing SolrCore 
> 'name4_shard1_replica_n2': Unable to create core [name4_shard1_replica_n2] 
> Caused by: The content of elements must consist of well-formed character data 
> or markup.",
> "localhost:8983_solr":"org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException:Error
>  from server at http://localhost:8983/solr: Error CREATEing SolrCore 
> 'name4_shard2_replica_n1': Unable to create core [name4_shard2_replica_n1] 
> Caused by: The content of elements must consist of well-formed character data 
> or markup."}
> }
> {noformat}
> vs async:
> {noformat}
> {
> "responseHeader":{
> "status":0,
> "QTime":3},
> "success":{
> "localhost:8983_solr":{
> "responseHeader":{
> "status":0,
> "QTime":12}},
> "localhost:8983_solr":{
> "responseHeader":{
> "status":0,
> "QTime":3}},
> "localhost:8983_solr":{
> "responseHeader":{
> "status":0,
> "QTime":11}},
> "localhost:8983_solr":{
> "responseHeader":{
> "status":0,
> "QTime":12}}},
> "myTaskId2709146382836":{
> "responseHeader":{
> "status":0,
> "QTime":1},
> "STATUS":"failed",
> "Response":"Error CREATEing SolrCore 'name_shard2_replica_n2': Unable to 
> create core [name_shard2_replica_n2] Caused by: The content of elements must 
> consist of well-formed character data or markup."},
> "status":{
> "state":"completed",
> "msg":"found [myTaskId] in completed tasks"}}
> {noformat}
> Proposing adding failure node to the results, keeping backward compatible but 
> correct result.



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

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

Re: Welcome Jason Gerlowski to the PMC

[Noble Paul]

Welcome Jason

On Sat, Feb 23, 2019 at 4:39 AM Tomás Fernández Löbbe
 wrote:
>
> Welcome Jason!
>
> On Fri, Feb 22, 2019 at 8:57 AM Alan Woodward  wrote:
>>
>> Welcome Jason!
>>
>> > On 22 Feb 2019, at 15:21, Jan Høydahl  wrote:
>> >
>> > I am pleased to announce that Jason Gerlowski has accepted the PMC's 
>> > invitation to join.
>> >
>> > Welcome Jason!
>> >
>> > --
>> > Jan Høydahl, search solution architect
>> > Cominvent AS - www.cominvent.com
>> >
>> >
>> > -
>> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> > For additional commands, e-mail: dev-h...@lucene.apache.org
>> >
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>


-- 
-
Noble Paul

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

[jira] [Comment Edited] (SOLR-13261) Should SortableTextField be allowed in export?

[Erick Erickson (JIRA)]

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

Erick Erickson edited comment on SOLR-13261 at 2/22/19 5:44 PM:


I'll be pushing this later today.

I cannot get the "AwaitsFix"-annotated test here to fail after beasting 1,000 
runs. I'm going to un-annotate it and then make a JIRA if it comes back that 
I'll assign to myself. I'm going to try to spend some serious time 
understanding several test failures that I've assigned to myself, if they're 
still current that is...


was (Author: erickerickson):
I'll be pushing this later today.

I cannot get the "AwaitsFix"-annotated test here to fail after beasting 1,000 
runs. I'm going to un-annotate it and then make a JIRA to watch it that I'll 
assign to myself. I'm going to try to spend some serious time understanding 
several test failures that I've assigned to myself, if they're still current 
that is...

> Should SortableTextField be allowed in export?
> --
>
> Key: SOLR-13261
> URL: https://issues.apache.org/jira/browse/SOLR-13261
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 7.7, 8.0, master (9.0)
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Major
> Attachments: SOLR-13261.patch
>
>
> ExportWriter (and perhaps other places) explicitly tests for certain field 
> types and error out with "Export fields must either be one of the following 
> types: int,float,long,double,string,date,boolean"
> It seems perfectly legal to export SortableTextField as well as it's a DV 
> field. How desirable that would be is an open question.



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

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

Re: Welcome Jason Gerlowski to the PMC

[Tomás Fernández Löbbe]

Welcome Jason!

On Fri, Feb 22, 2019 at 8:57 AM Alan Woodward  wrote:

> Welcome Jason!
>
> > On 22 Feb 2019, at 15:21, Jan Høydahl  wrote:
> >
> > I am pleased to announce that Jason Gerlowski has accepted the PMC's
> invitation to join.
> >
> > Welcome Jason!
> >
> > --
> > Jan Høydahl, search solution architect
> > Cominvent AS - www.cominvent.com
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> > For additional commands, e-mail: dev-h...@lucene.apache.org
> >
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

Re: Welcome Jason Gerlowski to the PMC

[Alan Woodward]

Welcome Jason!

> On 22 Feb 2019, at 15:21, Jan Høydahl  wrote:
> 
> I am pleased to announce that Jason Gerlowski has accepted the PMC's 
> invitation to join.
> 
> Welcome Jason!
> 
> --
> Jan Høydahl, search solution architect
> Cominvent AS - www.cominvent.com
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
> 


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

[jira] [Commented] (SOLR-13261) Should SortableTextField be allowed in export?

[Erick Erickson (JIRA)]

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

Erick Erickson commented on SOLR-13261:
---

I'll be pushing this later today.

I cannot get the "AwaitsFix"-annotated test here to fail after beasting 1,000 
runs. I'm going to un-annotate it and then make a JIRA to watch it that I'll 
assign to myself. I'm going to try to spend some serious time understanding 
several test failures that I've assigned to myself, if they're still current 
that is...

> Should SortableTextField be allowed in export?
> --
>
> Key: SOLR-13261
> URL: https://issues.apache.org/jira/browse/SOLR-13261
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 7.7, 8.0, master (9.0)
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Major
> Attachments: SOLR-13261.patch
>
>
> ExportWriter (and perhaps other places) explicitly tests for certain field 
> types and error out with "Export fields must either be one of the following 
> types: int,float,long,double,string,date,boolean"
> It seems perfectly legal to export SortableTextField as well as it's a DV 
> field. How desirable that would be is an open question.



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

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

[jira] [Commented] (SOLR-9882) exceeding timeAllowed causes ClassCastException: BasicResultContext cannot be cast to SolrDocumentList

[Lucene/Solr QA (JIRA)]

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

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

| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green}  0m 
 0s{color} | {color:green} The patch appears to include 2 new or modified test 
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  1m 
48s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  1m 
42s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green}  1m 
42s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Release audit (RAT) {color} | 
{color:green}  1m 36s{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} Check forbidden APIs {color} | {color:red} 
 1m 30s{color} | {color:red} Check forbidden APIs check-forbidden-apis failed 
{color} |
| {color:red}-1{color} | {color:red} Validate source patterns {color} | 
{color:red}  1m 30s{color} | {color:red} Check forbidden APIs 
check-forbidden-apis failed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 43m 31s{color} 
| {color:red} core in the patch failed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green}  0m 
26s{color} | {color:green} test-framework in the patch passed. {color} |
| {color:black}{color} | {color:black} {color} | {color:black} 48m 20s{color} | 
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | solr.handler.component.DistributedDebugComponentTest |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | SOLR-9882 |
| JIRA Patch URL | 
https://issues.apache.org/jira/secure/attachment/12959796/SOLR-9882.patch |
| Optional Tests |  compile  javac  unit  ratsources  checkforbiddenapis  
validatesourcepatterns  |
| uname | Linux lucene1-us-west 4.4.0-137-generic #163~14.04.1-Ubuntu SMP Mon 
Sep 24 17:14:57 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | ant |
| Personality | 
/home/jenkins/jenkins-slave/workspace/PreCommit-SOLR-Build/sourcedir/dev-tools/test-patch/lucene-solr-yetus-personality.sh
 |
| git revision | master / 9b8a4a9 |
| ant | version: Apache Ant(TM) version 1.9.3 compiled on July 24 2018 |
| Default Java | 1.8.0_191 |
| Check forbidden APIs | 
https://builds.apache.org/job/PreCommit-SOLR-Build/311/artifact/out/patch-check-forbidden-apis-solr.txt
 |
| Validate source patterns | 
https://builds.apache.org/job/PreCommit-SOLR-Build/311/artifact/out/patch-check-forbidden-apis-solr.txt
 |
| unit | 
https://builds.apache.org/job/PreCommit-SOLR-Build/311/artifact/out/patch-unit-solr_core.txt
 |
|  Test Results | 
https://builds.apache.org/job/PreCommit-SOLR-Build/311/testReport/ |
| modules | C: solr solr/core solr/test-framework U: solr |
| Console output | 
https://builds.apache.org/job/PreCommit-SOLR-Build/311/console |
| Powered by | Apache Yetus 0.7.0   http://yetus.apache.org |


This message was automatically generated.



> exceeding timeAllowed causes ClassCastException: BasicResultContext cannot be 
> cast to SolrDocumentList
> --
>
> Key: SOLR-9882
> URL: https://issues.apache.org/jira/browse/SOLR-9882
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 6.3
>Reporter: Yago Riveiro
>Assignee: Mikhail Khludnev
>Priority: Major
> Attachments: SOLR-9882-7987.patch, SOLR-9882.patch, SOLR-9882.patch, 
> SOLR-9882.patch, SOLR-9882.patch, SOLR-9882.patch, SOLR-9882.patch, 
> SOLR-9882.patch, SOLR-9882.patch, SOLR-9882.patch, SOLR-9882.patch
>
>
> After talk with [~yo...@apache.org] in the mailing list I open this Jira 
> ticket
> I'm hitting this bug in Solr 6.3.0.
> null:java.lang.ClassCastException:
> org.apache.solr.response.BasicResultContext cannot be cast to
> org.apache.solr.common.SolrDocumentList
> at
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:315)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:153)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:2213)
> at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:654)
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:460)
> at
> 

Re: Welcome Jason Gerlowski to the PMC

[Martin Gainty]

Welcome Jason!

martin-

From: David Smiley 
Sent: Friday, February 22, 2019 11:09 AM
To: dev@lucene.apache.org
Subject: Re: Welcome Jason Gerlowski to the PMC

Welcome Jason!

On Fri, Feb 22, 2019 at 11:03 AM Erick Erickson 
mailto:erickerick...@gmail.com>> wrote:
Welcome!

> On Feb 22, 2019, at 7:39 AM, Kevin Risden 
> mailto:kris...@apache.org>> wrote:
>
> Congrats and welcome!
>
> Kevin Risden
>
>
> On Fri, Feb 22, 2019 at 10:31 AM Đạt Cao Mạnh 
> mailto:caomanhdat...@gmail.com>> wrote:
> Welcome, Jason!
>
> On Fri, 22 Feb 2019 at 15:28, Adrien Grand 
> mailto:jpou...@gmail.com>> wrote:
> Welcome, Jason!
>
> On Fri, Feb 22, 2019 at 4:21 PM Jan Høydahl 
> mailto:jan@cominvent.com>> wrote:
> >
> > I am pleased to announce that Jason Gerlowski has accepted the PMC's 
> > invitation to join.
> >
> > Welcome Jason!
> >
> > --
> > Jan Høydahl, search solution architect
> > Cominvent AS - www.cominvent.com
> >
> >
> > -
> > To unsubscribe, e-mail: 
> > dev-unsubscr...@lucene.apache.org
> > For additional commands, e-mail: 
> > dev-h...@lucene.apache.org
> >
>
>
> --
> Adrien
>
> -
> To unsubscribe, e-mail: 
> dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: 
> dev-h...@lucene.apache.org
>
> --
> Best regards,
> Cao Mạnh Đạt
> D.O.B : 31-07-1991
> Cell: (+84) 946.328.329
> E-mail: caomanhdat...@gmail.com


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

--
Lucene/Solr Search Committer (PMC), Developer, Author, Speaker
LinkedIn: http://linkedin.com/in/davidwsmiley | Book: 
http://www.solrenterprisesearchserver.com

[jira] [Commented] (SOLR-13267) complex {!graph query: NullPointerException

[Erick Erickson (JIRA)]

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

Erick Erickson commented on SOLR-13267:
---

Out of curiosity, what happens if you replace "AND NOT" with just "NOT"? 
Solr/Lucene do not implement pure boolean logic, so the "AND" is unnecessary. 
See: https://lucidworks.com/2011/12/28/why-not-and-or-and-not/

NOTE: "AND NOT" should work, but just "NOT" works that's both a work-around and 
a pointer where the problem is.

Oh, and please post the stack trace.

> complex {!graph query: NullPointerException
> ---
>
> Key: SOLR-13267
> URL: https://issues.apache.org/jira/browse/SOLR-13267
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 7.7
>Reporter: Jochen Barth
>Priority: Major
>
> this query leads to NullPointerException:
> (\{!graph from=id to=parent_ids}fulltext_ocr_txtlarge:phoron
> AND \{!graph from=id to=parent_ids}fulltext_ocr_txtlarge:terrae)
> AND NOT (\{!graph from=id to=parent_ids returnRoot=false}
> (\{!graph from=id to=parent_ids}fulltext_ocr_txtlarge:phoron AND
> {!graph from=id to=parent_ids}fulltext_ocr_txtlarge:terrae))
> It is essentially the query
> X = \{!graph from=id to=parent_ids}fulltext_ocr_txtlarge:phoron
> AND \{!graph from=id to=parent_ids}fulltext_ocr_txtlarge:terrae
> (X) AND NOT (\{!graph from=id to=parent_ids returnRoot=false}(X))
> parent_ids is a multiValued string docValue-Field; fulltext_ocr_txtlarge is 
> essentially like the *_txt field.
> Use case is: hierarchical solr-docs, think book, chapter, subchapter etc. 
> Each containing fulltext_ocr_txtlarge with the fulltext of this element only. 
> So higher level elements (e. g. book) does not contain the fulltext of lower 
> level elements (e. g. chapters).
> The query X delivers all chapters with both words, but of course higher level 
> elements, too, because the whole book has always more text than single 
> chapters.
> the »AND NOT ({!graph ... « part is to filter out the unecessary results, 
> like »book« if a chapter already matches.
>  
>  



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

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

Re: Welcome Jason Gerlowski to the PMC

[David Smiley]

Welcome Jason!

On Fri, Feb 22, 2019 at 11:03 AM Erick Erickson 
wrote:

> Welcome!
>
> > On Feb 22, 2019, at 7:39 AM, Kevin Risden  wrote:
> >
> > Congrats and welcome!
> >
> > Kevin Risden
> >
> >
> > On Fri, Feb 22, 2019 at 10:31 AM Đạt Cao Mạnh 
> wrote:
> > Welcome, Jason!
> >
> > On Fri, 22 Feb 2019 at 15:28, Adrien Grand  wrote:
> > Welcome, Jason!
> >
> > On Fri, Feb 22, 2019 at 4:21 PM Jan Høydahl 
> wrote:
> > >
> > > I am pleased to announce that Jason Gerlowski has accepted the PMC's
> invitation to join.
> > >
> > > Welcome Jason!
> > >
> > > --
> > > Jan Høydahl, search solution architect
> > > Cominvent AS - www.cominvent.com
> > >
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> > > For additional commands, e-mail: dev-h...@lucene.apache.org
> > >
> >
> >
> > --
> > Adrien
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> > For additional commands, e-mail: dev-h...@lucene.apache.org
> >
> > --
> > Best regards,
> > Cao Mạnh Đạt
> > D.O.B : 31-07-1991
> > Cell: (+84) 946.328.329 <+84%2094%20632%2083%2029>
> > E-mail: caomanhdat...@gmail.com
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
> --
Lucene/Solr Search Committer (PMC), Developer, Author, Speaker
LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
http://www.solrenterprisesearchserver.com

Re: Welcome Jason Gerlowski to the PMC

[Erick Erickson]

Welcome!

> On Feb 22, 2019, at 7:39 AM, Kevin Risden  wrote:
> 
> Congrats and welcome!
> 
> Kevin Risden
> 
> 
> On Fri, Feb 22, 2019 at 10:31 AM Đạt Cao Mạnh  wrote:
> Welcome, Jason!
> 
> On Fri, 22 Feb 2019 at 15:28, Adrien Grand  wrote:
> Welcome, Jason!
> 
> On Fri, Feb 22, 2019 at 4:21 PM Jan Høydahl  wrote:
> >
> > I am pleased to announce that Jason Gerlowski has accepted the PMC's 
> > invitation to join.
> >
> > Welcome Jason!
> >
> > --
> > Jan Høydahl, search solution architect
> > Cominvent AS - www.cominvent.com
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> > For additional commands, e-mail: dev-h...@lucene.apache.org
> >
> 
> 
> -- 
> Adrien
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
> 
> -- 
> Best regards,
> Cao Mạnh Đạt
> D.O.B : 31-07-1991
> Cell: (+84) 946.328.329
> E-mail: caomanhdat...@gmail.com


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

[JENKINS] Lucene-Solr-Tests-8.x - Build # 42 - Unstable

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Tests-8.x/42/

2 tests failed.
FAILED:  org.apache.solr.schema.TestCloudSchemaless.test

Error Message:
Timeout occurred while waiting response from server at: 
http://127.0.0.1:33212/_yse/d/collection1

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: Timeout occurred while 
waiting response from server at: http://127.0.0.1:33212/_yse/d/collection1
at 
__randomizedtesting.SeedInfo.seed([7D215737EBDB1593:F57568ED4527786B]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:661)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:256)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:245)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:207)
at org.apache.solr.client.solrj.SolrClient.commit(SolrClient.java:504)
at org.apache.solr.client.solrj.SolrClient.commit(SolrClient.java:479)
at 
org.apache.solr.schema.TestCloudSchemaless.test(TestCloudSchemaless.java:116)
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:1750)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:1082)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:1054)
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:947)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894)
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)
  

Re: Welcome Jason Gerlowski to the PMC

[Kevin Risden]

Congrats and welcome!

Kevin Risden


On Fri, Feb 22, 2019 at 10:31 AM Đạt Cao Mạnh 
wrote:

> Welcome, Jason!
>
> On Fri, 22 Feb 2019 at 15:28, Adrien Grand  wrote:
>
>> Welcome, Jason!
>>
>> On Fri, Feb 22, 2019 at 4:21 PM Jan Høydahl 
>> wrote:
>> >
>> > I am pleased to announce that Jason Gerlowski has accepted the PMC's
>> invitation to join.
>> >
>> > Welcome Jason!
>> >
>> > --
>> > Jan Høydahl, search solution architect
>> > Cominvent AS - www.cominvent.com
>> >
>> >
>> > -
>> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> > For additional commands, e-mail: dev-h...@lucene.apache.org
>> >
>>
>>
>> --
>> Adrien
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>> --
> *Best regards,*
> *Cao Mạnh Đạt*
>
>
> *D.O.B : 31-07-1991Cell: (+84) 946.328.329E-mail: caomanhdat...@gmail.com
> *
>

Re: Welcome Jason Gerlowski to the PMC

[Đạt Cao Mạnh]

Welcome, Jason!

On Fri, 22 Feb 2019 at 15:28, Adrien Grand  wrote:

> Welcome, Jason!
>
> On Fri, Feb 22, 2019 at 4:21 PM Jan Høydahl  wrote:
> >
> > I am pleased to announce that Jason Gerlowski has accepted the PMC's
> invitation to join.
> >
> > Welcome Jason!
> >
> > --
> > Jan Høydahl, search solution architect
> > Cominvent AS - www.cominvent.com
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> > For additional commands, e-mail: dev-h...@lucene.apache.org
> >
>
>
> --
> Adrien
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
> --
*Best regards,*
*Cao Mạnh Đạt*


*D.O.B : 31-07-1991Cell: (+84) 946.328.329E-mail: caomanhdat...@gmail.com
*

Re: Welcome Jason Gerlowski to the PMC

[Adrien Grand]

Welcome, Jason!

On Fri, Feb 22, 2019 at 4:21 PM Jan Høydahl  wrote:
>
> I am pleased to announce that Jason Gerlowski has accepted the PMC's 
> invitation to join.
>
> Welcome Jason!
>
> --
> Jan Høydahl, search solution architect
> Cominvent AS - www.cominvent.com
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>


-- 
Adrien

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

Welcome Jason Gerlowski to the PMC

[Jan Høydahl]

I am pleased to announce that Jason Gerlowski has accepted the PMC's invitation 
to join.

Welcome Jason!

--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com


-
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 # 2300 - Still unstable!

[Policeman Jenkins Server]

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

2 tests failed.
FAILED:  org.apache.solr.core.TestJmxIntegration.testJmxOnCoreReload

Error Message:
Number of registered MBeans is not the same as the number of core metrics: 442 
!= 443

Stack Trace:
java.lang.AssertionError: Number of registered MBeans is not the same as the 
number of core metrics: 442 != 443
at 
__randomizedtesting.SeedInfo.seed([CD244A7930E9EAEF:CF9D911543AA3622]:0)
at org.junit.Assert.fail(Assert.java:88)
at 
org.apache.solr.core.TestJmxIntegration.testJmxOnCoreReload(TestJmxIntegration.java:260)
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:1750)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988)
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:947)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894)
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.security.JWTAuthPluginIntegrationTest.testMetrics

Error Message:
Server returned HTTP response code: 401 for URL: 
http://127.0.0.1:62555/solr/jwtColl/query?q=*:*

Stack Trace:
java.io.IOException: Server returned 

[JENKINS-EA] Lucene-Solr-8.x-Linux (64bit/jdk-13-ea+8) - Build # 196 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-8.x-Linux/196/
Java: 64bit/jdk-13-ea+8 -XX:-UseCompressedOops -XX:+UseSerialGC

10 tests failed.
FAILED:  junit.framework.TestSuite.org.apache.solr.cloud.OverseerTest

Error Message:
SOLR-11606: ByteBuddy used by Mockito is not working with this JVM version.

Stack Trace:
org.junit.AssumptionViolatedException: SOLR-11606: ByteBuddy used by Mockito is 
not working with this JVM version.
at __randomizedtesting.SeedInfo.seed([B94F1516DE310DEF]:0)
at 
com.carrotsearch.randomizedtesting.RandomizedTest.assumeNoException(RandomizedTest.java:742)
at 
org.apache.solr.SolrTestCaseJ4.assumeWorkingMockito(SolrTestCaseJ4.java:365)
at org.apache.solr.cloud.OverseerTest.beforeClass(OverseerTest.java:284)
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:567)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:878)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894)
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:835)
Caused by: java.lang.IllegalArgumentException: Unknown Java version: 13
at 
net.bytebuddy.ClassFileVersion.ofJavaVersion(ClassFileVersion.java:210)
at 
net.bytebuddy.ClassFileVersion$VersionLocator$ForJava9CapableVm.locate(ClassFileVersion.java:462)
at net.bytebuddy.ClassFileVersion.ofThisVm(ClassFileVersion.java:223)
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:567)
at 
org.apache.solr.SolrTestCaseJ4.assumeWorkingMockito(SolrTestCaseJ4.java:363)
... 24 more


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

Error Message:


Stack Trace:
java.lang.NullPointerException
at __randomizedtesting.SeedInfo.seed([B94F1516DE310DEF]:0)
at org.apache.solr.cloud.OverseerTest.afterClass(OverseerTest.java:307)
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:567)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:901)
at 

[jira] [Commented] (SOLR-10860) in-place updates currently throw NumberFormatException instead of a Bad Request SolrException for bad input

[Munendra S N (JIRA)]

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

Munendra S N commented on SOLR-10860:
-

 [^SOLR-10860.patch] 
Attached patch handles NFE and throws SolrException with 400 status code

[~ichattopadhyaya] [~tomasflobbe]
* Using the methods added in SOLR-10833 to parse the values 
* handling inc operation on other fields
* return solrException instead of NPE when user passes null
* Currently, for some operation field name is not available during hence, error 
message doesn't contain field name. One way to include field name is to wrap

{code:java}
https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/update/processor/AtomicUpdateDocumentMerger.java#L101
{code}
in try-catch  block, let me know if this makes sense or just error with value 
is enough


> in-place updates currently throw NumberFormatException instead of a Bad 
> Request SolrException for bad input
> ---
>
> Key: SOLR-10860
> URL: https://issues.apache.org/jira/browse/SOLR-10860
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Tomás Fernández Löbbe
>Assignee: Ishan Chattopadhyaya
>Priority: Major
> Attachments: SOLR-10860.patch, SOLR-10860.patch
>
>




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

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

[jira] [Updated] (SOLR-10860) in-place updates currently throw NumberFormatException instead of a Bad Request SolrException for bad input

[Munendra S N (JIRA)]

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

Munendra S N updated SOLR-10860:

Attachment: SOLR-10860.patch

> in-place updates currently throw NumberFormatException instead of a Bad 
> Request SolrException for bad input
> ---
>
> Key: SOLR-10860
> URL: https://issues.apache.org/jira/browse/SOLR-10860
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Tomás Fernández Löbbe
>Assignee: Ishan Chattopadhyaya
>Priority: Major
> Attachments: SOLR-10860.patch, SOLR-10860.patch
>
>




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

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

[jira] [Updated] (SOLR-7414) CSVResponseWriter returns empty field when fl alias is combined with '*' selector

[Munendra S N (JIRA)]

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

Munendra S N updated SOLR-7414:
---
Attachment: SOLR-7414.patch

> CSVResponseWriter returns empty field when fl alias is combined with '*' 
> selector
> -
>
> Key: SOLR-7414
> URL: https://issues.apache.org/jira/browse/SOLR-7414
> Project: Solr
>  Issue Type: Bug
>  Components: Response Writers
>Reporter: Michael Lawrence
>Priority: Major
> Attachments: SOLR-7414-old.patch, SOLR-7414.patch, SOLR-7414.patch, 
> SOLR-7414.patch, SOLR-7414.patch, SOLR-7414.patch
>
>
> Attempting to retrieve all fields while renaming one, e.g., "inStock" to 
> "stocked" (URL below), results in CSV output that has a column for "inStock" 
> (should be "stocked"), and the column has no values. 
> steps to reproduce using 5.1...
> {noformat}
> $ bin/solr -e techproducts
> ...
> $ curl -X POST -H 'Content-Type: application/json' 
> 'http://localhost:8983/solr/techproducts/update?commit=true' --data-binary 
> '[{ "id" : "aaa", "bar_i" : 7, "inStock" : true }, { "id" : "bbb", "bar_i" : 
> 7, "inStock" : false }, { "id" : "ccc", "bar_i" : 7, "inStock" : true }]'
> {"responseHeader":{"status":0,"QTime":730}}
> $ curl 
> 'http://localhost:8983/solr/techproducts/query?q=bar_i:7=id,stocked:inStock=csv'
> id,stocked
> aaa,true
> bbb,false
> ccc,true
> $ curl 
> 'http://localhost:8983/solr/techproducts/query?q=bar_i:7=*,stocked:inStock=csv'
> bar_i,id,_version_,inStock
> 7,aaa,1498719888088236032,
> 7,bbb,1498719888090333184,
> 7,ccc,1498719888090333185,
> $ curl 
> 'http://localhost:8983/solr/techproducts/query?q=bar_i:7=stocked:inStock,*=csv'
> bar_i,id,_version_,inStock
> 7,aaa,1498719888088236032,
> 7,bbb,1498719888090333184,
> 7,ccc,1498719888090333185,
> {noformat}



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

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

[jira] [Commented] (SOLR-7414) CSVResponseWriter returns empty field when fl alias is combined with '*' selector

[Munendra S N (JIRA)]

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

Munendra S N commented on SOLR-7414:


As suggested I have refactored response writers
 [^SOLR-7414.patch] 
[~ichattopadhyaya] [~mkhludnev]
Please review the updated patch.

> CSVResponseWriter returns empty field when fl alias is combined with '*' 
> selector
> -
>
> Key: SOLR-7414
> URL: https://issues.apache.org/jira/browse/SOLR-7414
> Project: Solr
>  Issue Type: Bug
>  Components: Response Writers
>Reporter: Michael Lawrence
>Priority: Major
> Attachments: SOLR-7414-old.patch, SOLR-7414.patch, SOLR-7414.patch, 
> SOLR-7414.patch, SOLR-7414.patch, SOLR-7414.patch
>
>
> Attempting to retrieve all fields while renaming one, e.g., "inStock" to 
> "stocked" (URL below), results in CSV output that has a column for "inStock" 
> (should be "stocked"), and the column has no values. 
> steps to reproduce using 5.1...
> {noformat}
> $ bin/solr -e techproducts
> ...
> $ curl -X POST -H 'Content-Type: application/json' 
> 'http://localhost:8983/solr/techproducts/update?commit=true' --data-binary 
> '[{ "id" : "aaa", "bar_i" : 7, "inStock" : true }, { "id" : "bbb", "bar_i" : 
> 7, "inStock" : false }, { "id" : "ccc", "bar_i" : 7, "inStock" : true }]'
> {"responseHeader":{"status":0,"QTime":730}}
> $ curl 
> 'http://localhost:8983/solr/techproducts/query?q=bar_i:7=id,stocked:inStock=csv'
> id,stocked
> aaa,true
> bbb,false
> ccc,true
> $ curl 
> 'http://localhost:8983/solr/techproducts/query?q=bar_i:7=*,stocked:inStock=csv'
> bar_i,id,_version_,inStock
> 7,aaa,1498719888088236032,
> 7,bbb,1498719888090333184,
> 7,ccc,1498719888090333185,
> $ curl 
> 'http://localhost:8983/solr/techproducts/query?q=bar_i:7=stocked:inStock,*=csv'
> bar_i,id,_version_,inStock
> 7,aaa,1498719888088236032,
> 7,bbb,1498719888090333184,
> 7,ccc,1498719888090333185,
> {noformat}



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

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

[jira] [Updated] (SOLR-9882) exceeding timeAllowed causes ClassCastException: BasicResultContext cannot be cast to SolrDocumentList

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev updated SOLR-9882:
---
Attachment: SOLR-9882.patch

> exceeding timeAllowed causes ClassCastException: BasicResultContext cannot be 
> cast to SolrDocumentList
> --
>
> Key: SOLR-9882
> URL: https://issues.apache.org/jira/browse/SOLR-9882
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 6.3
>Reporter: Yago Riveiro
>Assignee: Mikhail Khludnev
>Priority: Major
> Attachments: SOLR-9882-7987.patch, SOLR-9882.patch, SOLR-9882.patch, 
> SOLR-9882.patch, SOLR-9882.patch, SOLR-9882.patch, SOLR-9882.patch, 
> SOLR-9882.patch, SOLR-9882.patch, SOLR-9882.patch, SOLR-9882.patch
>
>
> After talk with [~yo...@apache.org] in the mailing list I open this Jira 
> ticket
> I'm hitting this bug in Solr 6.3.0.
> null:java.lang.ClassCastException:
> org.apache.solr.response.BasicResultContext cannot be cast to
> org.apache.solr.common.SolrDocumentList
> at
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:315)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:153)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:2213)
> at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:654)
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:460)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:303)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:254)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1668)
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:581)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:226)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1160)
> at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:511)
> at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1092)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:213)
> at
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:119)
> at
> org.eclipse.jetty.server.handler.StatisticsHandler.handle(StatisticsHandler.java:169)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)
> at org.eclipse.jetty.server.Server.handle(Server.java:518)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:308)
> at
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:244)
> at
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:273)
> at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:95)
> at
> org.eclipse.jetty.io.SelectChannelEndPoint$2.run(SelectChannelEndPoint.java:93)
> at
> org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.produceAndRun(ExecuteProduceConsume.java:246)
> at
> org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.run(ExecuteProduceConsume.java:156)
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:654)
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:572)
> at java.lang.Thread.run(Thread.java:745)



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

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

[jira] [Commented] (LUCENE-8703) Build point writers only when needed on the BKD tree

[Michael McCandless (JIRA)]

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

Michael McCandless commented on LUCENE-8703:


It'd be nice to have a metric in our nightly points benchmarks measuring how 
much heap was required while building the index.

> Build point writers only when needed on the BKD tree
> 
>
> Key: LUCENE-8703
> URL: https://issues.apache.org/jira/browse/LUCENE-8703
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Ignacio Vera
>Priority: Major
> Attachments: LUCENE-8703.patch, LUCENE-8703.patch, LUCENE-8703.patch
>
>
> With the introduction of LUCENE-8699, I have realised the BKD tree uses quite 
> a lot of heap even when it is not needed, for example for 1D points. 
> In this issue I propose to create point writers only when needed. In addition 
> I propose to create PointWriters based on the estimated point count given in 
> the constructor. 



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

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

[jira] [Commented] (LUCENE-8671) Add setting for moving FST offheap/onheap

[Michael McCandless (JIRA)]

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

Michael McCandless commented on LUCENE-8671:


[~akjain] that's true, maybe we don't need per-field control and a single 
boolean option would work?  We could maybe add a setter on 
{{BlockTreeTermsWriter}}?  And it'd write that setting into the index, and 
{{BlockTreeTermsReader}} would read that and then load FSTs on or off heap.

> Add setting for moving FST offheap/onheap
> -
>
> Key: LUCENE-8671
> URL: https://issues.apache.org/jira/browse/LUCENE-8671
> Project: Lucene - Core
>  Issue Type: New Feature
>  Components: core/FSTs, core/store
>Reporter: Ankit Jain
>Priority: Minor
> Attachments: offheap_generic_settings.patch, offheap_settings.patch
>
>   Original Estimate: 24h
>  Remaining Estimate: 24h
>
> While LUCENE-8635, adds support for loading FST offheap using mmap, users do 
> not have the  flexibility to specify fields for which FST needs to be 
> offheap. This allows users to tune heap usage as per their workload.
> Ideal way will be to add an attribute to FieldInfo, where we have 
> put/getAttribute. Then FieldReader can inspect the FieldInfo and pass the 
> appropriate On/OffHeapStore when creating its FST. It can support special 
> keywords like ALL/NONE.



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

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

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

[Apache Jenkins Server]

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

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

[repro] Revision: a5113ac1b3859e40424b509737fc1a01467c14b6

[repro] Ant options: -Dtests.multiplier=2 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.x/test-data/enwiki.random.lines.txt
[repro] Repro line:  ant test  -Dtestcase=TestSimTriggerIntegration 
-Dtests.method=testSearchRate -Dtests.seed=D120A3872F2A6A7B 
-Dtests.multiplier=2 -Dtests.nightly=true -Dtests.slow=true 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.x/test-data/enwiki.random.lines.txt
 -Dtests.locale=ar-YE -Dtests.timezone=Pacific/Funafuti -Dtests.asserts=true 
-Dtests.file.encoding=UTF-8

[repro] Repro line:  ant test  -Dtestcase=ReplicationFactorTest 
-Dtests.method=test -Dtests.seed=D120A3872F2A6A7B -Dtests.multiplier=2 
-Dtests.nightly=true -Dtests.slow=true 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.x/test-data/enwiki.random.lines.txt
 -Dtests.locale=sr-Latn-BA -Dtests.timezone=America/Miquelon 
-Dtests.asserts=true -Dtests.file.encoding=UTF-8

[repro] Repro line:  ant test  -Dtestcase=LeaderTragicEventTest 
-Dtests.method=test -Dtests.seed=D120A3872F2A6A7B -Dtests.multiplier=2 
-Dtests.nightly=true -Dtests.slow=true 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.x/test-data/enwiki.random.lines.txt
 -Dtests.locale=fi -Dtests.timezone=Asia/Pyongyang -Dtests.asserts=true 
-Dtests.file.encoding=UTF-8

[repro] git rev-parse --abbrev-ref HEAD
[repro] git rev-parse HEAD
[repro] Initial local git branch/revision: 
9b8a4a9e6e4aa640faa6a9e35fab2f61b126dc07
[repro] git fetch
[repro] git checkout a5113ac1b3859e40424b509737fc1a01467c14b6

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

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

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

[...truncated 3583 lines...]
[repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=15 
-Dtests.class="*.LeaderTragicEventTest|*.ReplicationFactorTest|*.TestSimTriggerIntegration"
 -Dtests.showOutput=onerror -Dtests.multiplier=2 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.x/test-data/enwiki.random.lines.txt
 -Dtests.seed=D120A3872F2A6A7B -Dtests.multiplier=2 -Dtests.nightly=true 
-Dtests.slow=true 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.x/test-data/enwiki.random.lines.txt
 -Dtests.locale=fi -Dtests.timezone=Asia/Pyongyang -Dtests.asserts=true 
-Dtests.file.encoding=UTF-8

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

[repro] Failures:
[repro]   0/5 failed: org.apache.solr.cloud.ReplicationFactorTest
[repro]   0/5 failed: 
org.apache.solr.cloud.autoscaling.sim.TestSimTriggerIntegration
[repro]   1/5 failed: org.apache.solr.cloud.LeaderTragicEventTest
[repro] git checkout 9b8a4a9e6e4aa640faa6a9e35fab2f61b126dc07

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

[...truncated 6 lines...]

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

[JENKINS] Lucene-Solr-8.x-MacOSX (64bit/jdk-9) - Build # 49 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-8.x-MacOSX/49/
Java: 64bit/jdk-9 -XX:-UseCompressedOops -XX:+UseSerialGC

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

Error Message:
Failed while waiting for active collection Timeout waiting to see state for 
collection=collection1 :null Live Nodes: [127.0.0.1:58631_solr, 
127.0.0.1:58632_solr] Last available state: null

Stack Trace:
java.lang.RuntimeException: Failed while waiting for active collection
Timeout waiting to see state for collection=collection1 :null
Live Nodes: [127.0.0.1:58631_solr, 127.0.0.1:58632_solr]
Last available state: null
at 
__randomizedtesting.SeedInfo.seed([AF42B19D4B0CF624:27168E47E5F09BDC]:0)
at 
org.apache.solr.cloud.MiniSolrCloudCluster.waitForActiveCollection(MiniSolrCloudCluster.java:728)
at 
org.apache.solr.cloud.MiniSolrCloudCluster.waitForActiveCollection(MiniSolrCloudCluster.java:734)
at 
org.apache.solr.cloud.LeaderTragicEventTest.test(LeaderTragicEventTest.java:80)
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:1750)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988)
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:947)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 

[jira] [Commented] (SOLR-12860) MetricsHistoryHandler does not work with BasicAuth

[JIRA]

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

Jan Høydahl commented on SOLR-12860:


PKI should kick in automatically for inter-node, but I have a theory that the 
MetricsHistoryHandler uses a wrong ThreadPool which is not instrumented for 
this? Don't have time to debug now, patches welcome!

> MetricsHistoryHandler does not work with BasicAuth
> --
>
> Key: SOLR-12860
> URL: https://issues.apache.org/jira/browse/SOLR-12860
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Varun Thacker
>Priority: Major
>
> I setup a 2 node cluster ( bin/solr start -e cloud -noprompt ) and then 
> uploaded the default security.json from 
> [http://lucene.apache.org/solr/guide/7_5/basic-authentication-plugin.html] .
>  
> I'm seeing errors like these in the logs which would indicate that the 
> metrics history handler would not work with basic auth enabled?
> {code:java}
> 2018-10-12 22:06:43.496 WARN  (MetricsHistoryHandler-12-thread-1) [   ] 
> o.a.s.c.s.i.SolrClientNodeStateProvider could not get tags from node 
> 192.168.0.8:7574_solr
> org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
> from server at http://192.168.0.8:7574/solr: Expected mime type 
> application/octet-stream but got text/html. 
> 
> 
> Error 401 require authentication
> 
> HTTP ERROR 401
> Problem accessing /solr/admin/metrics. Reason:
>     require authentication
> 
> 
>     at 
> org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:607)
>  ~[solr-solrj-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df - 
> jimczi - 2018-09-18 13:07:58]
>     at 
> org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:255)
>  ~[solr-solrj-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df - 
> jimczi - 2018-09-18 13:07:58]
>     at 
> org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:244)
>  ~[solr-solrj-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df - 
> jimczi - 2018-09-18 13:07:58]
>     at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219) 
> ~[solr-solrj-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df - 
> jimczi - 2018-09-18 13:07:58]
>     at 
> org.apache.solr.client.solrj.impl.SolrClientNodeStateProvider$ClientSnitchCtx.invoke(SolrClientNodeStateProvider.java:342)
>  ~[solr-solrj-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df - 
> jimczi - 2018-09-18 13:07:58]
>     at 
> org.apache.solr.client.solrj.impl.SolrClientNodeStateProvider.fetchReplicaMetrics(SolrClientNodeStateProvider.java:195)
>  ~[solr-solrj-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df - 
> jimczi - 2018-09-18 13:07:58]
>     at 
> org.apache.solr.client.solrj.impl.SolrClientNodeStateProvider$AutoScalingSnitch.getRemoteInfo(SolrClientNodeStateProvider.java:241)
>  ~[solr-solrj-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df - 
> jimczi - 2018-09-18 13:07:58]
>     at 
> org.apache.solr.common.cloud.rule.ImplicitSnitch.getTags(ImplicitSnitch.java:76)
>  ~[solr-solrj-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df - 
> jimczi - 2018-09-18 13:07:58]
>     at 
> org.apache.solr.client.solrj.impl.SolrClientNodeStateProvider.fetchTagValues(SolrClientNodeStateProvider.java:139)
>  ~[solr-solrj-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df - 
> jimczi - 2018-09-18 13:07:58]
>     at 
> org.apache.solr.client.solrj.impl.SolrClientNodeStateProvider.getNodeValues(SolrClientNodeStateProvider.java:128)
>  ~[solr-solrj-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df - 
> jimczi - 2018-09-18 13:07:58]
>     at 
> org.apache.solr.handler.admin.MetricsHistoryHandler.collectGlobalMetrics(MetricsHistoryHandler.java:498)
>  ~[solr-core-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df - 
> jimczi - 2018-09-18 13:07:55]
>     at 
> org.apache.solr.handler.admin.MetricsHistoryHandler.collectMetrics(MetricsHistoryHandler.java:371)
>  ~[solr-core-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df - 
> jimczi - 2018-09-18 13:07:55]
>     at 
> org.apache.solr.handler.admin.MetricsHistoryHandler.lambda$new$0(MetricsHistoryHandler.java:231)
>  ~[solr-core-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df - 
> jimczi - 2018-09-18 13:07:55]
>     at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> [?:1.8.0_112]
>     at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) 
> [?:1.8.0_112]
>     at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
>  [?:1.8.0_112]
>     at 
> 

[jira] [Updated] (SOLR-12860) MetricsHistoryHandler does not work with BasicAuth

[JIRA]

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

Jan Høydahl updated SOLR-12860:
---
Priority: Critical  (was: Major)

> MetricsHistoryHandler does not work with BasicAuth
> --
>
> Key: SOLR-12860
> URL: https://issues.apache.org/jira/browse/SOLR-12860
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Varun Thacker
>Priority: Critical
>
> I setup a 2 node cluster ( bin/solr start -e cloud -noprompt ) and then 
> uploaded the default security.json from 
> [http://lucene.apache.org/solr/guide/7_5/basic-authentication-plugin.html] .
>  
> I'm seeing errors like these in the logs which would indicate that the 
> metrics history handler would not work with basic auth enabled?
> {code:java}
> 2018-10-12 22:06:43.496 WARN  (MetricsHistoryHandler-12-thread-1) [   ] 
> o.a.s.c.s.i.SolrClientNodeStateProvider could not get tags from node 
> 192.168.0.8:7574_solr
> org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
> from server at http://192.168.0.8:7574/solr: Expected mime type 
> application/octet-stream but got text/html. 
> 
> 
> Error 401 require authentication
> 
> HTTP ERROR 401
> Problem accessing /solr/admin/metrics. Reason:
>     require authentication
> 
> 
>     at 
> org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:607)
>  ~[solr-solrj-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df - 
> jimczi - 2018-09-18 13:07:58]
>     at 
> org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:255)
>  ~[solr-solrj-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df - 
> jimczi - 2018-09-18 13:07:58]
>     at 
> org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:244)
>  ~[solr-solrj-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df - 
> jimczi - 2018-09-18 13:07:58]
>     at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219) 
> ~[solr-solrj-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df - 
> jimczi - 2018-09-18 13:07:58]
>     at 
> org.apache.solr.client.solrj.impl.SolrClientNodeStateProvider$ClientSnitchCtx.invoke(SolrClientNodeStateProvider.java:342)
>  ~[solr-solrj-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df - 
> jimczi - 2018-09-18 13:07:58]
>     at 
> org.apache.solr.client.solrj.impl.SolrClientNodeStateProvider.fetchReplicaMetrics(SolrClientNodeStateProvider.java:195)
>  ~[solr-solrj-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df - 
> jimczi - 2018-09-18 13:07:58]
>     at 
> org.apache.solr.client.solrj.impl.SolrClientNodeStateProvider$AutoScalingSnitch.getRemoteInfo(SolrClientNodeStateProvider.java:241)
>  ~[solr-solrj-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df - 
> jimczi - 2018-09-18 13:07:58]
>     at 
> org.apache.solr.common.cloud.rule.ImplicitSnitch.getTags(ImplicitSnitch.java:76)
>  ~[solr-solrj-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df - 
> jimczi - 2018-09-18 13:07:58]
>     at 
> org.apache.solr.client.solrj.impl.SolrClientNodeStateProvider.fetchTagValues(SolrClientNodeStateProvider.java:139)
>  ~[solr-solrj-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df - 
> jimczi - 2018-09-18 13:07:58]
>     at 
> org.apache.solr.client.solrj.impl.SolrClientNodeStateProvider.getNodeValues(SolrClientNodeStateProvider.java:128)
>  ~[solr-solrj-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df - 
> jimczi - 2018-09-18 13:07:58]
>     at 
> org.apache.solr.handler.admin.MetricsHistoryHandler.collectGlobalMetrics(MetricsHistoryHandler.java:498)
>  ~[solr-core-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df - 
> jimczi - 2018-09-18 13:07:55]
>     at 
> org.apache.solr.handler.admin.MetricsHistoryHandler.collectMetrics(MetricsHistoryHandler.java:371)
>  ~[solr-core-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df - 
> jimczi - 2018-09-18 13:07:55]
>     at 
> org.apache.solr.handler.admin.MetricsHistoryHandler.lambda$new$0(MetricsHistoryHandler.java:231)
>  ~[solr-core-7.5.0.jar:7.5.0 b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df - 
> jimczi - 2018-09-18 13:07:55]
>     at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> [?:1.8.0_112]
>     at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) 
> [?:1.8.0_112]
>     at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
>  [?:1.8.0_112]
>     at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
>  [?:1.8.0_112]
>     at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>  [?:1.8.0_112]
>     at 
> 

[JENKINS] Lucene-Solr-SmokeRelease-master - Build # 1263 - Failure

[Apache Jenkins Server]

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

No tests ran.

Build Log:
[...truncated 23447 lines...]
[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.)
 [java] Processed 2477 links (2023 relative) to 3299 anchors in 249 files
 [echo] Validated Links & Anchors via: 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/solr/build/solr-ref-guide/bare-bones-html/

-dist-changes:
 [copy] Copying 4 files to 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/solr/package/changes

package:

-unpack-solr-tgz:

-ensure-solr-tgz-exists:
[mkdir] Created dir: 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/solr/build/solr.tgz.unpacked
[untar] Expanding: 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/solr/package/solr-9.0.0.tgz
 into 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/solr/build/solr.tgz.unpacked

generate-maven-artifacts:

resolve:

resolve:

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

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml

resolve:

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

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml

resolve:

resolve:

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

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml

resolve:

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

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml

resolve:

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

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml

resolve:

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

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml

resolve:

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

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml

resolve:

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

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml

resolve:

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

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml

resolve:

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

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml

resolve:

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

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml

resolve:

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

[JENKINS-EA] Lucene-Solr-7.x-Linux (64bit/jdk-13-ea+8) - Build # 3571 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/3571/
Java: 64bit/jdk-13-ea+8 -XX:+UseCompressedOops -XX:+UseSerialGC

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

Error Message:
SOLR-11606: ByteBuddy used by Mockito is not working with this JVM version.

Stack Trace:
org.junit.AssumptionViolatedException: SOLR-11606: ByteBuddy used by Mockito is 
not working with this JVM version.
at __randomizedtesting.SeedInfo.seed([282E4D9D9CFD27DC]:0)
at 
com.carrotsearch.randomizedtesting.RandomizedTest.assumeNoException(RandomizedTest.java:742)
at 
org.apache.solr.SolrTestCaseJ4.assumeWorkingMockito(SolrTestCaseJ4.java:362)
at org.apache.solr.cloud.OverseerTest.beforeClass(OverseerTest.java:284)
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:567)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:878)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894)
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:835)
Caused by: java.lang.IllegalArgumentException: Unknown Java version: 13
at 
net.bytebuddy.ClassFileVersion.ofJavaVersion(ClassFileVersion.java:210)
at 
net.bytebuddy.ClassFileVersion$VersionLocator$ForJava9CapableVm.locate(ClassFileVersion.java:462)
at net.bytebuddy.ClassFileVersion.ofThisVm(ClassFileVersion.java:223)
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:567)
at 
org.apache.solr.SolrTestCaseJ4.assumeWorkingMockito(SolrTestCaseJ4.java:360)
... 24 more


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

Error Message:


Stack Trace:
java.lang.NullPointerException
at __randomizedtesting.SeedInfo.seed([282E4D9D9CFD27DC]:0)
at org.apache.solr.cloud.OverseerTest.afterClass(OverseerTest.java:307)
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:567)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:901)
at 

[jira] [Created] (SOLR-13267) complex {!graph query: NullPointerException

[Jochen Barth (JIRA)]

Jochen Barth created SOLR-13267:
---

 Summary: complex {!graph query: NullPointerException
 Key: SOLR-13267
 URL: https://issues.apache.org/jira/browse/SOLR-13267
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
Affects Versions: 7.7
Reporter: Jochen Barth


this query leads to NullPointerException:

(\{!graph from=id to=parent_ids}fulltext_ocr_txtlarge:phoron
AND \{!graph from=id to=parent_ids}fulltext_ocr_txtlarge:terrae)
AND NOT (\{!graph from=id to=parent_ids returnRoot=false}
(\{!graph from=id to=parent_ids}fulltext_ocr_txtlarge:phoron AND
{!graph from=id to=parent_ids}fulltext_ocr_txtlarge:terrae))

It is essentially the query

X = \{!graph from=id to=parent_ids}fulltext_ocr_txtlarge:phoron
AND \{!graph from=id to=parent_ids}fulltext_ocr_txtlarge:terrae

(X) AND NOT (\{!graph from=id to=parent_ids returnRoot=false}(X))

parent_ids is a multiValued string docValue-Field; fulltext_ocr_txtlarge is 
essentially like the *_txt field.

Use case is: hierarchical solr-docs, think book, chapter, subchapter etc. Each 
containing fulltext_ocr_txtlarge with the fulltext of this element only. So 
higher level elements (e. g. book) does not contain the fulltext of lower level 
elements (e. g. chapters).

The query X delivers all chapters with both words, but of course higher level 
elements, too, because the whole book has always more text than single chapters.

the »AND NOT ({!graph ... « part is to filter out the unecessary results, like 
»book« if a chapter already matches.

 

 



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

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

[jira] [Comment Edited] (SOLR-7005) facet.heatmap for spatial heatmap faceting on RPT

[Bar Rotstein (JIRA)]

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

Bar Rotstein edited comment on SOLR-7005 at 2/22/19 11:47 AM:
--

I've been looking forward to using the facet heatmap feature in Solr, but have 
sadly noticed it does not currently support the GeoJSON format.
 I filed a new ticket documenting this bug:
 [Solr-13263|https://issues.apache.org/jira/browse/SOLR-13263].


was (Author: brot):
I've been looking forward to using the facet heatmap feature in Solr, but have 
sadly noticed it does not currently support the GeoJSON format.
 I filed a new ticket documenting this bug:
 Solr-13263.

> facet.heatmap for spatial heatmap faceting on RPT
> -
>
> Key: SOLR-7005
> URL: https://issues.apache.org/jira/browse/SOLR-7005
> Project: Solr
>  Issue Type: New Feature
>  Components: spatial
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Major
> Fix For: 5.1
>
> Attachments: SOLR-7005_heatmap.patch, SOLR-7005_heatmap.patch, 
> SOLR-7005_heatmap.patch, SOLR-7005_heatmap.patch, heatmap_512x256.png, 
> heatmap_64x32.png
>
>
> This is a new feature that uses the new spatial Heatmap / 2D PrefixTree cell 
> counter in Lucene spatial LUCENE-6191.  This is a form of faceting, and 
> as-such I think it should live in the "facet" parameter namespace.  Here's 
> what the parameters are:
> * facet=true
> * facet.heatmap=fieldname
> * facet.heatmap.geom=\["-180 -90" TO "180 90"]
> * facet.heatmap.gridLevel=6
> * facet.heatmap.distErrPct=0.15
> * facet.heatmap.format=ints2D | png
> (Officially see FacetParams where options are documented)
> Like other faceting features, the fieldName can have local-params to exclude 
> filter queries or specify an output key.  This could be quite useful in doing 
> difference faceting on the same spatial data to identify relative change 
> against a baseline.
> The {{geom}} is optional; you get the whole world or you can specify a box or 
> WKT.
> Ultimately, this feature needs to know the grid level, which together with 
> the input shape will yield a certain number of cells.  You can specify 
> gridLevel exactly, or don't and instead provide distErrPct which is computed 
> like it is for the RPT field type as seen in the schema.  0.10 yielded ~4k 
> cells but it'll vary.  There's also a facet.heatmap.maxCells safety net 
> defaulting to 100k.  Exceed this and you get an error.
> The output is (JSON):
> {noformat}
> {gridLevel=6,columns=64,rows=64,minX=-180.0,maxX=180.0,minY=-90.0,maxY=90.0,counts_ints2D=[[0,
>  0, 2, 1, ],[1, 1, 3, 2, ...],...]}
> {noformat}
> counts_ints2D is null if all would be 0.  individual row arrays should 
> likewise be null... I welcome feedback.
> If you set the output to 'png' then you get a 4-byte per pixel/cell PNG, or 
> null if all counts are 0.  The high byte (alpha channel) is inverted so that 
> counts need to exceed 2^24 before the image will start to fade out if you try 
> and view it.
> This supports sharded / distributed queries.



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

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

[jira] [Commented] (SOLR-7005) facet.heatmap for spatial heatmap faceting on RPT

[Bar Rotstein (JIRA)]

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

Bar Rotstein commented on SOLR-7005:


I've been looking forward to using the facet heatmap feature in Solr, but have 
sadly noticed it does not currently support the GeoJSON format.
 I filed a new ticket documenting this bug:
 Solr-13263.

> facet.heatmap for spatial heatmap faceting on RPT
> -
>
> Key: SOLR-7005
> URL: https://issues.apache.org/jira/browse/SOLR-7005
> Project: Solr
>  Issue Type: New Feature
>  Components: spatial
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Major
> Fix For: 5.1
>
> Attachments: SOLR-7005_heatmap.patch, SOLR-7005_heatmap.patch, 
> SOLR-7005_heatmap.patch, SOLR-7005_heatmap.patch, heatmap_512x256.png, 
> heatmap_64x32.png
>
>
> This is a new feature that uses the new spatial Heatmap / 2D PrefixTree cell 
> counter in Lucene spatial LUCENE-6191.  This is a form of faceting, and 
> as-such I think it should live in the "facet" parameter namespace.  Here's 
> what the parameters are:
> * facet=true
> * facet.heatmap=fieldname
> * facet.heatmap.geom=\["-180 -90" TO "180 90"]
> * facet.heatmap.gridLevel=6
> * facet.heatmap.distErrPct=0.15
> * facet.heatmap.format=ints2D | png
> (Officially see FacetParams where options are documented)
> Like other faceting features, the fieldName can have local-params to exclude 
> filter queries or specify an output key.  This could be quite useful in doing 
> difference faceting on the same spatial data to identify relative change 
> against a baseline.
> The {{geom}} is optional; you get the whole world or you can specify a box or 
> WKT.
> Ultimately, this feature needs to know the grid level, which together with 
> the input shape will yield a certain number of cells.  You can specify 
> gridLevel exactly, or don't and instead provide distErrPct which is computed 
> like it is for the RPT field type as seen in the schema.  0.10 yielded ~4k 
> cells but it'll vary.  There's also a facet.heatmap.maxCells safety net 
> defaulting to 100k.  Exceed this and you get an error.
> The output is (JSON):
> {noformat}
> {gridLevel=6,columns=64,rows=64,minX=-180.0,maxX=180.0,minY=-90.0,maxY=90.0,counts_ints2D=[[0,
>  0, 2, 1, ],[1, 1, 3, 2, ...],...]}
> {noformat}
> counts_ints2D is null if all would be 0.  individual row arrays should 
> likewise be null... I welcome feedback.
> If you set the output to 'png' then you get a 4-byte per pixel/cell PNG, or 
> null if all counts are 0.  The high byte (alpha channel) is inverted so that 
> counts need to exceed 2^24 before the image will start to fade out if you try 
> and view it.
> This supports sharded / distributed queries.



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

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

[jira] [Updated] (SOLR-13263) Facet Heat Map should support GeoJSON

[Bar Rotstein (JIRA)]

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

Bar Rotstein updated SOLR-13263:

Labels: Facets Geolocation facet faceting geo  (was: Facets facet faceting)

> Facet Heat Map should support GeoJSON
> -
>
> Key: SOLR-13263
> URL: https://issues.apache.org/jira/browse/SOLR-13263
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Facet Module, faceting
>Affects Versions: 8.0, 8.x, master (9.0)
>Reporter: Bar Rotstein
>Priority: Major
>  Labels: Facets, Geolocation, facet, faceting, geo
> Attachments: SOLR-13263-nocommit.patch
>
>
> Currently Facet Heatmap(Geographical facets) do not support any other 
> subjects other than WKT or '[ ]'. This seems to be caused since 
> FacetHeatmap.Parser#parse uses SpatialUtils#parseGeomSolrException, which in 
> turn uses a deprecated JTS method (SpatialContext#readShapeFromWkt) to parse 
> the string input.
> The newer method of parsing a String to a Shape object should be used, makes 
> the code a lot cleaner and should support more formats (including GeoJSON).



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

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

[jira] [Updated] (SOLR-13263) Facet Heat Map should support GeoJSON

[Bar Rotstein (JIRA)]

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

Bar Rotstein updated SOLR-13263:

Component/s: faceting
 Facet Module

> Facet Heat Map should support GeoJSON
> -
>
> Key: SOLR-13263
> URL: https://issues.apache.org/jira/browse/SOLR-13263
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Facet Module, faceting
>Affects Versions: 8.0, 8.x, master (9.0)
>Reporter: Bar Rotstein
>Priority: Major
>  Labels: Facets, facet, faceting
> Attachments: SOLR-13263-nocommit.patch
>
>
> Currently Facet Heatmap(Geographical facets) do not support any other 
> subjects other than WKT or '[ ]'. This seems to be caused since 
> FacetHeatmap.Parser#parse uses SpatialUtils#parseGeomSolrException, which in 
> turn uses a deprecated JTS method (SpatialContext#readShapeFromWkt) to parse 
> the string input.
> The newer method of parsing a String to a Shape object should be used, makes 
> the code a lot cleaner and should support more formats (including GeoJSON).



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

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

[jira] [Updated] (SOLR-13263) Facet Heat Map should support GeoJSON

[Bar Rotstein (JIRA)]

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

Bar Rotstein updated SOLR-13263:

Labels: Facets facet faceting  (was: )

> Facet Heat Map should support GeoJSON
> -
>
> Key: SOLR-13263
> URL: https://issues.apache.org/jira/browse/SOLR-13263
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 8.0, 8.x, master (9.0)
>Reporter: Bar Rotstein
>Priority: Major
>  Labels: Facets, facet, faceting
> Attachments: SOLR-13263-nocommit.patch
>
>
> Currently Facet Heatmap(Geographical facets) do not support any other 
> subjects other than WKT or '[ ]'. This seems to be caused since 
> FacetHeatmap.Parser#parse uses SpatialUtils#parseGeomSolrException, which in 
> turn uses a deprecated JTS method (SpatialContext#readShapeFromWkt) to parse 
> the string input.
> The newer method of parsing a String to a Shape object should be used, makes 
> the code a lot cleaner and should support more formats (including GeoJSON).



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

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

[jira] [Commented] (LUCENE-8696) TestGeo3DPoint.testGeo3DRelations failure

[Karl Wright (JIRA)]

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

Karl Wright commented on LUCENE-8696:
-

The path in the test retraces its steps, but that should not be a problem for 
membership testing.  I'll look into it starting this evening.


> TestGeo3DPoint.testGeo3DRelations failure
> -
>
> Key: LUCENE-8696
> URL: https://issues.apache.org/jira/browse/LUCENE-8696
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/spatial3d
>Reporter: Ignacio Vera
>Assignee: Karl Wright
>Priority: Major
> Attachments: LUCENE-8696.patch
>
>
> Reproduce with:
> {code:java}
> ant test  -Dtestcase=TestGeo3DPoint -Dtests.method=testGeo3DRelations 
> -Dtests.seed=721195D0198A8470 -Dtests.slow=true -Dtests.badapples=true 
> -Dtests.locale=sr-RS -Dtests.timezone=Europe/Istanbul -Dtests.asserts=true 
> -Dtests.file.encoding=ISO-8859-1{code}
> Error:
> {code:java}
>    [junit4] FAILURE 1.16s | TestGeo3DPoint.testGeo3DRelations <<<
>    [junit4]    > Throwable #1: java.lang.AssertionError: invalid hits for 
> shape=GeoStandardPath: {planetmodel=PlanetModel.WGS84, 
> width=1.3439035240356338(77.01), 
> points={[[lat=2.4457272005608357E-47, 
> lon=0.017453291479645996([X=1.0009663787601641, Y=0.017471932090601616, 
> Z=2.448463612203698E-47])], [lat=2.4457272005608357E-47, 
> lon=0.8952476719156919([X=0.6260252093310985, Y=0.7812370940381473, 
> Z=2.448463612203698E-47])], [lat=2.4457272005608357E-47, 
> lon=0.6491968536639036([X=0.7974608400583222, Y=0.6052232384770843, 
> Z=2.448463612203698E-47])], [lat=-0.7718789008737459, 
> lon=0.9236607495528212([X=0.43181767034308555, Y=0.5714183775701452, 
> Z=-0.6971214014446648])]]}}{code}



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

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

[JENKINS] Lucene-Solr-7.x-MacOSX (64bit/jdk-9) - Build # 1065 - Failure!

[Policeman Jenkins Server]

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

All tests passed

Build Log:
[...truncated 13381 lines...]
   [junit4] JVM J0: stdout was not empty, see: 
/Users/jenkins/workspace/Lucene-Solr-7.x-MacOSX/solr/build/solr-core/test/temp/junit4-J0-20190222_100651_57911434861510512854792.sysout
   [junit4] >>> JVM J0 emitted unexpected output (verbatim) 
   [junit4] #
   [junit4] # A fatal error has been detected by the Java Runtime Environment:
   [junit4] #
   [junit4] #  Internal Error (sharedRuntime.cpp:931), pid=58963, tid=127843
   [junit4] #  guarantee(cm != NULL) failed: must have containing compiled 
method for implicit division-by-zero exceptions
   [junit4] #
   [junit4] # JRE version: Java(TM) SE Runtime Environment (9.0+181) (build 
9+181)
   [junit4] # Java VM: Java HotSpot(TM) 64-Bit Server VM (9+181, mixed mode, 
tiered, compressed oops, parallel gc, bsd-amd64)
   [junit4] # No core dump will be written. Core dumps have been disabled. To 
enable core dumping, try "ulimit -c unlimited" before starting Java again
   [junit4] #
   [junit4] # An error report file with more information is saved as:
   [junit4] # 
/Users/jenkins/workspace/Lucene-Solr-7.x-MacOSX/solr/build/solr-core/test/J0/hs_err_pid58963.log
   [junit4] #
   [junit4] # If you would like to submit a bug report, please visit:
   [junit4] #   http://bugreport.java.com/bugreport/crash.jsp
   [junit4] #
   [junit4] <<< JVM J0: EOF 

[...truncated 1665 lines...]
   [junit4] ERROR: JVM J0 ended with an exception, command line: 
/Library/Java/JavaVirtualMachines/jdk-9.jdk/Contents/Home/bin/java 
-XX:+UseCompressedOops -XX:+UseParallelGC -XX:+HeapDumpOnOutOfMemoryError 
-XX:HeapDumpPath=/Users/jenkins/workspace/Lucene-Solr-7.x-MacOSX/heapdumps -ea 
-esa --illegal-access=deny -Dtests.prefix=tests -Dtests.seed=3A8A09233E86BB10 
-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=7.8.0 -Dtests.cleanthreads=perClass 
-Djava.util.logging.config.file=/Users/jenkins/workspace/Lucene-Solr-7.x-MacOSX/lucene/tools/junit4/logging.properties
 -Dtests.nightly=false -Dtests.weekly=false -Dtests.monster=false 
-Dtests.slow=true -Dtests.asserts=true -Dtests.multiplier=1 -DtempDir=./temp 
-Djava.io.tmpdir=./temp 
-Dcommon.dir=/Users/jenkins/workspace/Lucene-Solr-7.x-MacOSX/lucene 
-Dclover.db.dir=/Users/jenkins/workspace/Lucene-Solr-7.x-MacOSX/lucene/build/clover/db
 
-Djava.security.policy=/Users/jenkins/workspace/Lucene-Solr-7.x-MacOSX/lucene/tools/junit4/solr-tests.policy
 -Dtests.LUCENE_VERSION=7.8.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=/Users/jenkins/workspace/Lucene-Solr-7.x-MacOSX 
-Djava.security.egd=file:/dev/./urandom 
-Djunit4.childvm.cwd=/Users/jenkins/workspace/Lucene-Solr-7.x-MacOSX/solr/build/solr-core/test/J0
 
-Djunit4.tempDir=/Users/jenkins/workspace/Lucene-Solr-7.x-MacOSX/solr/build/solr-core/test/temp
 -Djunit4.childvm.id=0 -Djunit4.childvm.count=2 -Dtests.disableHdfs=true 
-Djava.security.manager=org.apache.lucene.util.TestSecurityManager 
-Dtests.filterstacks=true -Dtests.leaveTemporary=false -Dtests.badapples=false 
-classpath 

[jira] [Commented] (SOLR-10751) Master/Slave IndexVersion conflict

[Cao Manh Dat (JIRA)]

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

Cao Manh Dat commented on SOLR-10751:
-

tl;dr: I'm good with going with #2.

> Master/Slave IndexVersion conflict
> --
>
> Key: SOLR-10751
> URL: https://issues.apache.org/jira/browse/SOLR-10751
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 7.0
>Reporter: Tomás Fernández Löbbe
>Assignee: Tomás Fernández Löbbe
>Priority: Major
> Attachments: SOLR-10751.patch
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> I’ve been looking at some failures in the replica types tests. One strange 
> failure I noticed is, master and slave share the same version, but have 
> different generation. The IndexFetcher code does more or less this:
> {code}
> masterVersion = fetchMasterVersion()
> masterGeneration = fetchMasterGeneration()
> if (masterVersion == 0 && slaveGeneration != 0 && forceReplication) {
>delete my index
>commit locally
>return
> } 
> if (masterVersion != slaveVersion) {
>   fetchIndexFromMaster(masterGeneration)
> } else {
>   //do nothing, master and slave are in sync.
> }
> {code}
> The problem I see happens with this sequence of events:
> delete index in master (not a DBQ=\*:\*, I mean a complete removal of the 
> index files and reload of the core)
> replication happens in slave (sees a version 0, deletes local index and 
> commit)
> add document in master and commit
> if the commit in master and in the slave happen at the same millisecond*, 
> they both end up with the same version, but different indices. 
> I think that in addition of checking for the same version, we should validate 
> that slave and master have the same generation and If not, consider them not 
> in sync, and proceed to the replication.
> True, this is a situation that's difficult to happen in a real prod 
> environment and it's more likely to affect tests, but I think the change 
> makes sense. 



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

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

[jira] [Commented] (SOLR-10751) Master/Slave IndexVersion conflict

[Cao Manh Dat (JIRA)]

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

Cao Manh Dat commented on SOLR-10751:
-

Hi [~tomasflobbe], here are some of my analysis at this case (when we go along 
with #2 for TLOG replica)
Case 1: The wipe out is done by a DBQ, then it will present replica's tlog, in 
any cases latter, the leader continue serving or get down, we are guaranteed 
that. The replica will have enough data to continue. I think #2 is great 
solution in this case, we can avoid of cases where both leader and replica 
index is empty, but they have different things in tlog. The only downside here 
is {{DBQ *:*}} will makes tlog replicas out-of-sync with the leader until the 
next commit happen in leader, this change in behaviour should be noted to users.

Case 2: The wipe out is done without a DBQ and leader is healthy until the next 
commit. We still fine here since commit version is generated incremental, so 
only updates after the next commit are copied over.

Case 3: The wipe out is done without a DBQ and leader get down before finish 
the next commit. The index of the shard is unpredictable now. 

> Master/Slave IndexVersion conflict
> --
>
> Key: SOLR-10751
> URL: https://issues.apache.org/jira/browse/SOLR-10751
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 7.0
>Reporter: Tomás Fernández Löbbe
>Assignee: Tomás Fernández Löbbe
>Priority: Major
> Attachments: SOLR-10751.patch
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> I’ve been looking at some failures in the replica types tests. One strange 
> failure I noticed is, master and slave share the same version, but have 
> different generation. The IndexFetcher code does more or less this:
> {code}
> masterVersion = fetchMasterVersion()
> masterGeneration = fetchMasterGeneration()
> if (masterVersion == 0 && slaveGeneration != 0 && forceReplication) {
>delete my index
>commit locally
>return
> } 
> if (masterVersion != slaveVersion) {
>   fetchIndexFromMaster(masterGeneration)
> } else {
>   //do nothing, master and slave are in sync.
> }
> {code}
> The problem I see happens with this sequence of events:
> delete index in master (not a DBQ=\*:\*, I mean a complete removal of the 
> index files and reload of the core)
> replication happens in slave (sees a version 0, deletes local index and 
> commit)
> add document in master and commit
> if the commit in master and in the slave happen at the same millisecond*, 
> they both end up with the same version, but different indices. 
> I think that in addition of checking for the same version, we should validate 
> that slave and master have the same generation and If not, consider them not 
> in sync, and proceed to the replication.
> True, this is a situation that's difficult to happen in a real prod 
> environment and it's more likely to affect tests, but I think the change 
> makes sense. 



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

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

[jira] [Commented] (LUCENE-8699) Use fixed byte array in HeapPointWriter

[ASF subversion and git services (JIRA)]

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

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

Commit 1dfc766afa63f246ef10ff2ab325db8ddec0cf9d in lucene-solr's branch 
refs/heads/branch_8x from Ignacio Vera
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=1dfc766 ]

LUCENE-8699: Add lucene internal tag to PointValue interface
and fix some typos


> Use fixed byte array in HeapPointWriter
> ---
>
> Key: LUCENE-8699
> URL: https://issues.apache.org/jira/browse/LUCENE-8699
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Ignacio Vera
>Assignee: Ignacio Vera
>Priority: Major
> Fix For: 8.x, master (9.0)
>
>  Time Spent: 2h
>  Remaining Estimate: 0h
>
>  
> {heapPointWriter} is always created with the same init size and max size. It 
> might make sense to change the implementation to use a byte array instead of 
> a growable structure as it has now. This seems to improve performance:
>  
> ||Approach||Index time (sec): Dev||Index Time (sec): Base||Index Time: 
> Diff||Force merge time (sec): Dev||Force Merge time (sec): Base||Force Merge 
> Time: Diff||Index size (GB): Dev||Index size (GB): Base||Index Size: 
> Diff||Reader heap (MB): Dev||Reader heap (MB): Base||Reader heap: Diff||
> |points|122.1s|147.0s|-17%|51.9s|70.5s|-26%|0.55|0.55|0%|1.57|1.57|0%|
> |shapes|211.1s|244.6s|-14%|121.1s|135.0s|-10%|1.29|1.29|0%|1.61|1.61|0%|
> |geo3d|154.2s|186.6s|-17%|63.4s|82.8s|-23%|0.75|0.75|0%|1.58|1.58|0%|



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

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

[jira] [Commented] (LUCENE-8699) Use fixed byte array in HeapPointWriter

[ASF subversion and git services (JIRA)]

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

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

Commit 9b8a4a9e6e4aa640faa6a9e35fab2f61b126dc07 in lucene-solr's branch 
refs/heads/master from Ignacio Vera
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=9b8a4a9 ]

LUCENE-8699: Add lucene internal tag to PointValue interface
and fix some typos


> Use fixed byte array in HeapPointWriter
> ---
>
> Key: LUCENE-8699
> URL: https://issues.apache.org/jira/browse/LUCENE-8699
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Ignacio Vera
>Assignee: Ignacio Vera
>Priority: Major
> Fix For: 8.x, master (9.0)
>
>  Time Spent: 2h
>  Remaining Estimate: 0h
>
>  
> {heapPointWriter} is always created with the same init size and max size. It 
> might make sense to change the implementation to use a byte array instead of 
> a growable structure as it has now. This seems to improve performance:
>  
> ||Approach||Index time (sec): Dev||Index Time (sec): Base||Index Time: 
> Diff||Force merge time (sec): Dev||Force Merge time (sec): Base||Force Merge 
> Time: Diff||Index size (GB): Dev||Index size (GB): Base||Index Size: 
> Diff||Reader heap (MB): Dev||Reader heap (MB): Base||Reader heap: Diff||
> |points|122.1s|147.0s|-17%|51.9s|70.5s|-26%|0.55|0.55|0%|1.57|1.57|0%|
> |shapes|211.1s|244.6s|-14%|121.1s|135.0s|-10%|1.29|1.29|0%|1.61|1.61|0%|
> |geo3d|154.2s|186.6s|-17%|63.4s|82.8s|-23%|0.75|0.75|0%|1.58|1.58|0%|



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

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

[jira] [Updated] (LUCENE-8705) Compress BKD trees by encoding the difference between two dimensions

[Ignacio Vera (JIRA)]

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

Ignacio Vera updated LUCENE-8705:
-
Issue Type: Improvement  (was: Bug)

> Compress BKD trees by encoding the difference between two dimensions
> 
>
> Key: LUCENE-8705
> URL: https://issues.apache.org/jira/browse/LUCENE-8705
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Adrien Grand
>Priority: Minor
>
> When serializing BKD trees to disk, for each block we look at the common 
> prefix for each dimension in isolation and only encode those common prefixes 
> once for the entire block. Now that we have range fields and shapes so that 
> several dimensions are storing related data, we might occasionally have 
> longer common prefixes when comparing with values in other dimensions. For 
> instance when indexing narrow ranges in a range field, we might get better 
> compression on the second dimension by encoding suffixes that differ with the 
> first dimension. This is also an obvious win if we are indexing lines or 
> points as shapes, since we have dimensions that record exactly the same 
> values in that case.



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

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

[jira] [Commented] (LUCENE-8703) Build point writers only when needed on the BKD tree

[Lucene/Solr QA (JIRA)]

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

Lucene/Solr QA commented on LUCENE-8703:


| (/) *{color:green}+1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green}  0m 
 0s{color} | {color:green} The patch appears to include 1 new or modified test 
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  0m 
41s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  0m 
39s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green}  0m 
38s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Release audit (RAT) {color} | 
{color:green}  0m 24s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Check forbidden APIs {color} | 
{color:green}  0m 20s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Validate source patterns {color} | 
{color:green}  0m 20s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green}  3m 
55s{color} | {color:green} codecs in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 14m 
58s{color} | {color:green} core in the patch passed. {color} |
| {color:black}{color} | {color:black} {color} | {color:black} 22m 29s{color} | 
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | LUCENE-8703 |
| JIRA Patch URL | 
https://issues.apache.org/jira/secure/attachment/12959605/LUCENE-8703.patch |
| Optional Tests |  compile  javac  unit  ratsources  checkforbiddenapis  
validatesourcepatterns  |
| uname | Linux lucene1-us-west 4.4.0-137-generic #163~14.04.1-Ubuntu SMP Mon 
Sep 24 17:14:57 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | ant |
| Personality | 
/home/jenkins/jenkins-slave/workspace/PreCommit-LUCENE-Build/sourcedir/dev-tools/test-patch/lucene-solr-yetus-personality.sh
 |
| git revision | master / 906a088 |
| ant | version: Apache Ant(TM) version 1.9.3 compiled on July 24 2018 |
| Default Java | 1.8.0_191 |
|  Test Results | 
https://builds.apache.org/job/PreCommit-LUCENE-Build/166/testReport/ |
| modules | C: lucene/codecs lucene/core U: lucene |
| Console output | 
https://builds.apache.org/job/PreCommit-LUCENE-Build/166/console |
| Powered by | Apache Yetus 0.7.0   http://yetus.apache.org |


This message was automatically generated.



> Build point writers only when needed on the BKD tree
> 
>
> Key: LUCENE-8703
> URL: https://issues.apache.org/jira/browse/LUCENE-8703
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Ignacio Vera
>Priority: Major
> Attachments: LUCENE-8703.patch, LUCENE-8703.patch
>
>
> With the introduction of LUCENE-8699, I have realised the BKD tree uses quite 
> a lot of heap even when it is not needed, for example for 1D points. 
> In this issue I propose to create point writers only when needed. In addition 
> I propose to create PointWriters based on the estimated point count given in 
> the constructor. 



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

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

[jira] [Comment Edited] (SOLR-13263) Facet Heat Map should support GeoJSON

[Bar Rotstein (JIRA)]

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

Bar Rotstein edited comment on SOLR-13263 at 2/22/19 9:00 AM:
--

Uploaded a no-commit patch, showcasing the non deprecated parsing function.
SpatialUtils#parseGeomSolrException:45
{code:java}  /**
   * Parses a 'geom' parameter (might also be used to parse shapes for 
indexing). {@code geomStr} can either be WKT or
   * a rectangle-range syntax (see {@link #parseRectangle(String, 
org.locationtech.spatial4j.context.SpatialContext)}.
   */
  public static Shape parseGeomSolrException(String geomStr, SpatialContext 
ctx) {
if (geomStr.length() == 0) {
  throw new IllegalArgumentException("0-length geometry string");
}
char c = geomStr.charAt(0);
if (c == '[' || c == '{') {
  return parseRectangeSolrException(geomStr, ctx);
}
//TODO parse a raw point?
try {
  return ctx.getFormats().read(geomStr);
  // return ctx.readShapeFromWkt(geomStr);
} catch (InvalidShapeException e) {
  throw new SolrException(SolrException.ErrorCode.BAD_REQUEST,
  "Could not parse string into a shape': " + e, e);
}

  }{code}
Ran all non bad apple Solr tests, which all passed successfully.
One minor gripe is that Spatial4J does not support parsing GeoJSON polygons, 
and throws an exception, asking to use JTS instead.
I'll try and set up a new test suite for this.
This makes me wonder though, how does Solr currently deal with error caused 
since Spatial4J is not as feature rich as JTS?
I have not found a Solr test suite that includes JTS, only a Lucene oriented 
one.
Is anyone aware of a test suite which includes JTS in its Solr Core instance?


was (Author: brot):
Uploaded a no-commit patch, showcasing the non deprecated parsing function.
SpatialUtils#parseGeomSolrException:45
{code:java}  /**
   * Parses a 'geom' parameter (might also be used to parse shapes for 
indexing). {@code geomStr} can either be WKT or
   * a rectangle-range syntax (see {@link #parseRectangle(String, 
org.locationtech.spatial4j.context.SpatialContext)}.
   */
  public static Shape parseGeomSolrException(String geomStr, SpatialContext 
ctx) {
if (geomStr.length() == 0) {
  throw new IllegalArgumentException("0-length geometry string");
}
char c = geomStr.charAt(0);
if (c == '[' || c == '{') {
  return parseRectangeSolrException(geomStr, ctx);
}
//TODO parse a raw point?
try {
  return ctx.getFormats().read(geomStr);
  // return ctx.readShapeFromWkt(geomStr);
} catch (InvalidShapeException e) {
  throw new SolrException(SolrException.ErrorCode.BAD_REQUEST,
  "Could not parse string into a shape': " + e, e);
}

  }{code}
Ran all non bad apple Solr tests, which all passed successfully.
One minor gripe is that Spatial4J does not support parsing GeoJSON polygons, 
and throws an exception, asking to use JTS instead.
I'll try and set up a new test suite for this.
This makes me wonder though, how does Solr currently deal with error caused 
since Spatial4J is not as feature rich as JTS?

> Facet Heat Map should support GeoJSON
> -
>
> Key: SOLR-13263
> URL: https://issues.apache.org/jira/browse/SOLR-13263
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 8.0, 8.x, master (9.0)
>Reporter: Bar Rotstein
>Priority: Major
> Attachments: SOLR-13263-nocommit.patch
>
>
> Currently Facet Heatmap(Geographical facets) do not support any other 
> subjects other than WKT or '[ ]'. This seems to be caused since 
> FacetHeatmap.Parser#parse uses SpatialUtils#parseGeomSolrException, which in 
> turn uses a deprecated JTS method (SpatialContext#readShapeFromWkt) to parse 
> the string input.
> The newer method of parsing a String to a Shape object should be used, makes 
> the code a lot cleaner and should support more formats (including GeoJSON).



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

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

[jira] [Commented] (SOLR-13263) Facet Heat Map should support GeoJSON

[Bar Rotstein (JIRA)]

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

Bar Rotstein commented on SOLR-13263:
-

Uploaded a no-commit patch, showcasing the non deprecated parsing function.
SpatialUtils#parseGeomSolrException:45
{code:java}  /**
   * Parses a 'geom' parameter (might also be used to parse shapes for 
indexing). {@code geomStr} can either be WKT or
   * a rectangle-range syntax (see {@link #parseRectangle(String, 
org.locationtech.spatial4j.context.SpatialContext)}.
   */
  public static Shape parseGeomSolrException(String geomStr, SpatialContext 
ctx) {
if (geomStr.length() == 0) {
  throw new IllegalArgumentException("0-length geometry string");
}
char c = geomStr.charAt(0);
if (c == '[' || c == '{') {
  return parseRectangeSolrException(geomStr, ctx);
}
//TODO parse a raw point?
try {
  return ctx.getFormats().read(geomStr);
  // return ctx.readShapeFromWkt(geomStr);
} catch (InvalidShapeException e) {
  throw new SolrException(SolrException.ErrorCode.BAD_REQUEST,
  "Could not parse string into a shape': " + e, e);
}

  }{code}
Ran all non bad apple Solr tests, which all passed successfully.
One minor gripe is that Spatial4J does not support parsing GeoJSON polygons, 
and throws an exception, asking to use JTS instead.
I'll try and set up a new test suite for this.
This makes me wonder though, how does Solr currently deal with error caused 
since Spatial4J is not as feature rich as JTS?

> Facet Heat Map should support GeoJSON
> -
>
> Key: SOLR-13263
> URL: https://issues.apache.org/jira/browse/SOLR-13263
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 8.0, 8.x, master (9.0)
>Reporter: Bar Rotstein
>Priority: Major
> Attachments: SOLR-13263-nocommit.patch
>
>
> Currently Facet Heatmap(Geographical facets) do not support any other 
> subjects other than WKT or '[ ]'. This seems to be caused since 
> FacetHeatmap.Parser#parse uses SpatialUtils#parseGeomSolrException, which in 
> turn uses a deprecated JTS method (SpatialContext#readShapeFromWkt) to parse 
> the string input.
> The newer method of parsing a String to a Shape object should be used, makes 
> the code a lot cleaner and should support more formats (including GeoJSON).



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

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

[jira] [Updated] (SOLR-13263) Facet Heat Map should support GeoJSON

[Bar Rotstein (JIRA)]

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

Bar Rotstein updated SOLR-13263:

Attachment: SOLR-13263-nocommit.patch

> Facet Heat Map should support GeoJSON
> -
>
> Key: SOLR-13263
> URL: https://issues.apache.org/jira/browse/SOLR-13263
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 8.0, 8.x, master (9.0)
>Reporter: Bar Rotstein
>Priority: Major
> Attachments: SOLR-13263-nocommit.patch
>
>
> Currently Facet Heatmap(Geographical facets) do not support any other 
> subjects other than WKT or '[ ]'. This seems to be caused since 
> FacetHeatmap.Parser#parse uses SpatialUtils#parseGeomSolrException, which in 
> turn uses a deprecated JTS method (SpatialContext#readShapeFromWkt) to parse 
> the string input.
> The newer method of parsing a String to a Shape object should be used, makes 
> the code a lot cleaner and should support more formats (including GeoJSON).



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

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

Re: Lucene and Solr 7.7.1

[Ishan Chattopadhyaya]

Sorry for the delay in getting this out; I was stuck with GPG issues and
also after building it fully, realized that branch_7_7 didn't have the
7.7.0's backward index. Rebuilding it again, hoping to have it out in
another 5-6 hours.

On Thu, Feb 21, 2019 at 2:20 PM Ishan Chattopadhyaya <
ichattopadhy...@gmail.com> wrote:

> Resolved this ^ Continuing with the release process.
>
> On Thu, Feb 21, 2019 at 12:49 PM Ishan Chattopadhyaya <
> ichattopadhy...@gmail.com> wrote:
>
>> I've run into a test failure while attempting to backport SOLR-13248.
>> Help would be appreciated; I've left a comment to that effect in the
>> comments for SOLR-13248.
>>
>> On Wed, Feb 20, 2019 at 2:55 PM Ishan Chattopadhyaya <
>> ichattopadhy...@gmail.com> wrote:
>>
>>> Based on discussions on the "Lucene/Solr 8.0" thread, I'm volunteering
>>> to release a 7.7.1 version as soon as the two blockers, SOLR-13248 and
>>> SOLR-13255 are committed.
>>>
>>

[JENKINS] Lucene-Solr-NightlyTests-8.0 - Build # 4 - Failure

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-8.0/4/

3 tests failed.
FAILED:  
org.apache.lucene.index.TestIndexWriterThreadsToSegments.testSegmentCountOnFlushRandom

Error Message:
Captured an uncaught exception in thread: Thread[id=8388, name=Thread-7626, 
state=RUNNABLE, group=TGRP-TestIndexWriterThreadsToSegments]

Stack Trace:
com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught 
exception in thread: Thread[id=8388, name=Thread-7626, state=RUNNABLE, 
group=TGRP-TestIndexWriterThreadsToSegments]
Caused by: java.lang.OutOfMemoryError: GC overhead limit exceeded
at __randomizedtesting.SeedInfo.seed([7F91AFF28FF13171]:0)
at java.util.HashSet.(HashSet.java:119)
at 
org.apache.lucene.index.SegmentCommitInfo.files(SegmentCommitInfo.java:228)
at org.apache.lucene.index.SegmentInfos.files(SegmentInfos.java:781)
at 
org.apache.lucene.index.IndexFileDeleter.incRef(IndexFileDeleter.java:550)
at 
org.apache.lucene.index.IndexWriter.incRefDeleter(IndexWriter.java:5090)
at 
org.apache.lucene.index.StandardDirectoryReader.open(StandardDirectoryReader.java:120)
at org.apache.lucene.index.IndexWriter.getReader(IndexWriter.java:526)
at 
org.apache.lucene.index.StandardDirectoryReader.doOpenFromWriter(StandardDirectoryReader.java:294)
at 
org.apache.lucene.index.StandardDirectoryReader.doOpenIfChanged(StandardDirectoryReader.java:269)
at 
org.apache.lucene.index.StandardDirectoryReader.doOpenIfChanged(StandardDirectoryReader.java:259)
at 
org.apache.lucene.index.DirectoryReader.openIfChanged(DirectoryReader.java:140)
at 
org.apache.lucene.index.TestIndexWriterThreadsToSegments$CheckSegmentCount.run(TestIndexWriterThreadsToSegments.java:131)
at java.util.concurrent.CyclicBarrier.dowait(CyclicBarrier.java:220)
at java.util.concurrent.CyclicBarrier.await(CyclicBarrier.java:362)
at 
org.apache.lucene.index.TestIndexWriterThreadsToSegments$2.run(TestIndexWriterThreadsToSegments.java:216)


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

Error Message:
The test or suite printed 9123 bytes to stdout and stderr, even though the 
limit was set to 8192 bytes. Increase the limit with @Limit, ignore it 
completely with @SuppressSysoutChecks or run with -Dtests.verbose=true

Stack Trace:
java.lang.AssertionError: The test or suite printed 9123 bytes to stdout and 
stderr, even though the limit was set to 8192 bytes. Increase the limit with 
@Limit, ignore it completely with @SuppressSysoutChecks or run with 
-Dtests.verbose=true
at __randomizedtesting.SeedInfo.seed([7F91AFF28FF13171]:0)
at 
org.apache.lucene.util.TestRuleLimitSysouts.afterIfSuccessful(TestRuleLimitSysouts.java:282)
at 
com.carrotsearch.randomizedtesting.rules.TestRuleAdapter$1.afterIfSuccessful(TestRuleAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:37)
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.TestStressCloudBlindAtomicUpdates.test_dv_stored

Error Message:
Some docs had errors -- check logs expected:<0> but was:<2>

Stack Trace:
java.lang.AssertionError: Some docs had errors -- check logs expected:<0> but 
was:<2>
at 
__randomizedtesting.SeedInfo.seed([89CD3C746DA87FC9:1BF15DF0D1EF4211]:0)
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.failNotEquals(Assert.java:834)
at org.junit.Assert.assertEquals(Assert.java:645)
at 
org.apache.solr.cloud.TestStressCloudBlindAtomicUpdates.checkField(TestStressCloudBlindAtomicUpdates.java:352)
at 
org.apache.solr.cloud.TestStressCloudBlindAtomicUpdates.test_dv_stored(TestStressCloudBlindAtomicUpdates.java:219)
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:1750)
at