[JENKINS] Lucene-Solr-NightlyTests-master - Build # 1842 - Still Failing

[Apache Jenkins Server]

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

1 tests failed.
FAILED:  
org.apache.solr.uninverting.TestDocTermOrdsUninvertLimit.testTriggerUnInvertLimit

Error Message:
this IndexWriter is closed

Stack Trace:
org.apache.lucene.store.AlreadyClosedException: this IndexWriter is closed
at org.apache.lucene.index.IndexWriter.ensureOpen(IndexWriter.java:681)
at org.apache.lucene.index.IndexWriter.getConfig(IndexWriter.java:1007)
at 
org.apache.lucene.index.IndexWriter.processEvents(IndexWriter.java:5119)
at 
org.apache.lucene.index.IndexWriter.updateDocument(IndexWriter.java:1597)
at 
org.apache.lucene.index.IndexWriter.addDocument(IndexWriter.java:1213)
at 
org.apache.lucene.index.RandomIndexWriter.addDocument(RandomIndexWriter.java:191)
at 
org.apache.solr.uninverting.TestDocTermOrdsUninvertLimit.testTriggerUnInvertLimit(TestDocTermOrdsUninvertLimit.java:65)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
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.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 
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:834)
Caused by: java.lang.OutOfMemoryError: Java heap space
at 
org.apache.lucene.codecs.memory.DirectPostingsFormat$DirectField.(DirectPostingsFormat.java:419)
at 
org.apache.lucene.codecs.memory.DirectPostingsFormat$DirectFields.(DirectPostingsFormat.java:132)
at 

[jira] [Commented] (SOLR-13439) Make collection properties easier and safer to use in code

[JIRA]

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

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

I don’t really like the idea of the time-based cache expire. In my mind, it’s 
better if whatever component sets up the watcher is responsible of removing it 
instead of adding a dependency on time. I won’t oppose if you still want to go 
this route.

Some comments on the patch:
{noformat}
-  private final ConcurrentHashMap 
watchedCollectionProps = new ConcurrentHashMap<>();
+  private final ConditionalExpiringCache 
watchedCollectionProps =
+  new ConditionalExpiringCache<>(new Predicate>() {
+@Override
+public boolean test(Entry entry) {
+  return collectionWatches.containsKey(entry.getKey());
+}
+  }, CACHE_COLLECTION_PROPS_REAPER_INTERVAL, 
CACHE_COLLECTION_PROPS_FOR_NANOS);
{noformat}
By using only {{collectionWatches}}, the issue I mentioned in SOLR-13420 will 
happen. If something is watching collection properties without watching the 
collection, the cache will expire the key and, and the next time the watch 
fires it will be dropped.

{noformat}
+properties = fetchCollectionProperties(collection, null).props;
+// regularly requested in updates so start caching, note that this 
method registers it's parent object
+// automatically.
+new PropsWatcher(collection).refreshAndWatch(false);
+  }
{noformat}
{{new PropsWatcher(collection).refreshAndWatch(false)}} should set the 
properties, you seem to be fetching twice here.

It would be nice to have tests for {{ConditionalExpiringCache}}

> Make collection properties easier and safer to use in code
> --
>
> Key: SOLR-13439
> URL: https://issues.apache.org/jira/browse/SOLR-13439
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Affects Versions: master (9.0)
>Reporter: Gus Heck
>Assignee: Gus Heck
>Priority: Major
> Attachments: SOLR-13439.patch
>
>
> (breaking this out from SOLR-13420, please read there for further background)
> Before this patch the api is quite confusing (IMHO):
>  # any code that wanted to know what the properties for a collection are 
> could call zkStateReader.getCollectionProperties(collection) but this was a 
> dangerous and trappy API because that was a query to zookeeper every time. If 
> a naive user auto-completed that in their IDE without investigating, heavy 
> use of zookeeper would ensue.
>  # To "do it right" for any code that might get called on a per-doc or per 
> request basis one had to cause caching by registering a watcher. At which 
> point the getCollectionProperties(collection) magically becomes safe to use, 
> but the watcher pattern probably looks famillar induces a user who hasn't 
> read the solr code closely to create their own cache and update it when their 
> watcher is notified. If the caching side effect of watches isn't understood 
> this will lead to many in-memory copies of collection properties maintained 
> in user code.
>  # This also creates a task to be scheduled on a thread (PropsNotification) 
> and induces an extra thread-scheduling lag before the changes can be observed 
> by user code.
>  # The code that cares about collection properties needs to have a lifecycle 
> tied to either a collection or something other object with an even more 
> ephemeral life cycle such as an URP. The user now also has to remember to 
> ensure the watch is unregistered, or there is a leak.
> After this patch
>  # Calls to getCollectionProperties(collection) are always safe to use in any 
> code anywhere. Caching and cleanup are automatic.
>  # Code that really actually wants to know if a collection property changes 
> so it can wake up and do something (autoscaling?) still has the option of 
> registering a watcher that will asynchronously send them a notification.
>  # Updates can be observed sooner via getCollectionProperties with no need to 
> wait for a thread to run. (vs a cache held in user code)



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

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

[jira] [Updated] (SOLR-13320) add a param failOnVersionConflicts=false to updates not fail when there is a version conflict

[Noble Paul (JIRA)]

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

Noble Paul updated SOLR-13320:
--
Summary: add a param failOnVersionConflicts=false to updates not fail when 
there is a version conflict  (was: add a param ignoreVersionConflicts=true to 
updates to not overwrite existing docs)

> add a param failOnVersionConflicts=false to updates not fail when there is a 
> version conflict
> -
>
> Key: SOLR-13320
> URL: https://issues.apache.org/jira/browse/SOLR-13320
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
> Attachments: SOLR-13320.patch, SOLR-13320.patch, SOLR-13320.patch
>
>
> Updates should have an option to ignore duplicate documents and drop them if 
> an option  {{ignoreDuplicates=true}} is specified



--
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.1-Windows (64bit/jdk-13-ea+18) - Build # 92 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-8.1-Windows/92/
Java: 64bit/jdk-13-ea+18 -XX:+UseCompressedOops -XX:+UseG1GC

12 tests failed.
FAILED:  
org.apache.solr.prometheus.exporter.SolrExporterIntegrationTest.jvmMetrics

Error Message:
expected:<36> but was:<48>

Stack Trace:
java.lang.AssertionError: expected:<36> but was:<48>
at 
__randomizedtesting.SeedInfo.seed([31FA467CC1B24098:E24E7B93D45C8C0C]: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.junit.Assert.assertEquals(Assert.java:631)
at 
org.apache.solr.prometheus.exporter.SolrExporterIntegrationTest.jvmMetrics(SolrExporterIntegrationTest.java:71)
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:  
junit.framework.TestSuite.org.apache.solr.update.processor.DistributedUpdateProcessorTest

Error Message:
SOLR-11606: ByteBuddy used by Mockito is not working with 

[jira] [Commented] (SOLR-13420) Allow Routed Aliases to use Collection Properties instead of core properties

[JIRA]

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

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

I left some comments regarding the patch in SOLR-13439, but just to respond 
some of the comments here:
{quote}I haven't changed anything with collection watches 
(CollectionStateWatcher, etc)? My changes only relate to CollectionProperties 
and their associated watches (PropsWatch for zk and CollectionPropsWatch for 
user notifications). Where do you see a change to or bundling with collection 
watches?
{quote}
I believe the cache predicate is bundling them. Left a comment in SOLR-13439.
{quote}If I register the watcher in, or accessible by the static 
RoutedAliasUpdateProcessor.wrap() method … how does it ever get unregistered 
when the collection is deleted or moved?
{quote}
In normal URP, you can, in the factory, register close hooks in the SolrCore, 
since the URPF is tied to the core, it makes sense to be there.
{quote}Yes, this is normal in Zk…
{quote}
I initially misunderstood this line in the patch:
{noformat}+ if (!watchedCollectionProps.containsKey(coll)) {noformat}, I 
thought you were validating against {{collectionWatches}}.

> Allow Routed Aliases to use Collection Properties instead of core properties
> 
>
> Key: SOLR-13420
> URL: https://issues.apache.org/jira/browse/SOLR-13420
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Affects Versions: master (9.0)
>Reporter: Gus Heck
>Assignee: Gus Heck
>Priority: Major
> Attachments: SOLR-13420.patch, SOLR-13420.patch, SOLR-13420.patch, 
> SOLR-13420.patch
>
>
> The current routed alias code is relying on a core property named 
> routedAliasName to detect when the Routed Alias wrapper URP should be applied 
> to Distributed Update Request Processor. 
> {code:java}
> #Written by CorePropertiesLocator
> #Sun Mar 03 06:21:14 UTC 2019
> routedAliasName=testalias21
> numShards=2
> collection.configName=_default
> ... etc...
> {code}
> Core properties are not changeable after the core is created, and they are 
> written to the file system for every core. To support a unit test for 
> SOLR-13419 I need to create some legacy formatted collection names, and 
> arrange them into a TRA, but this is impossible due to the fact that I can't 
> change the core property from the test. There's a TODO dating back to the 
> original TRA implementation in the routed alias code to switch to collection 
> properties instead, so this ticket will address that TOD to support the test 
> required for SOLR-13419.
> Back compatibility with legacy core based TRA's and CRA's will of course be 
> maintained. I also expect that this will facilitate some more nimble handling 
> or routed aliases with future auto-scaling capabilities such as possibly 
> detaching and archiving collections to cheaper, slower machines rather than 
> deleting them. (presently such a collection would still attempt to use the 
> routed alias if it received an update even if it were no longer in the list 
> of collections for the alias)



--
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+18) - Build # 524 - Unstable!

[Policeman Jenkins Server]

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

10 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.update.processor.DistributedUpdateProcessorTest

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([D079048DA5CF7594]:0)
at 
com.carrotsearch.randomizedtesting.RandomizedTest.assumeNoException(RandomizedTest.java:742)
at 
org.apache.solr.SolrTestCaseJ4.assumeWorkingMockito(SolrTestCaseJ4.java:374)
at 
org.apache.solr.update.processor.DistributedUpdateProcessorTest.beforeClass(DistributedUpdateProcessorTest.java:60)
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:372)
... 24 more


FAILED:  
junit.framework.TestSuite.org.apache.solr.update.processor.DistributedUpdateProcessorTest

Error Message:


Stack Trace:
java.lang.NullPointerException
at __randomizedtesting.SeedInfo.seed([D079048DA5CF7594]:0)
at 
org.apache.solr.update.processor.DistributedUpdateProcessorTest.AfterClass(DistributedUpdateProcessorTest.java:68)
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 

[JENKINS-MAVEN] Lucene-Solr-Maven-master #2557: POMs out of sync

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Maven-master/2557/

No tests ran.

Build Log:
[...truncated 18104 lines...]
BUILD FAILED
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-master/build.xml:673: The 
following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-master/build.xml:209: The 
following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-master/lucene/build.xml:408:
 The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-master/lucene/common-build.xml:1648:
 The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-master/lucene/common-build.xml:581:
 Error deploying artifact 'org.apache.lucene:lucene-test-framework:jar': Error 
installing artifact's metadata: Error while deploying metadata: Error 
transferring file

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

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

[jira] [Commented] (SOLR-13320) add a param failOnVersionConflicts=false to updates not fail when there is a version conflict

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-13320:


Commit 8cde22ba01d8bdeaefd5e3af197ef61404ec9406 in lucene-solr's branch 
refs/heads/branch_8x from Noble Paul
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=8cde22b ]

SOLR-13320 : add an update param failOnVersionConflicts=false to updates not 
fail when there is a version conflict


> add a param failOnVersionConflicts=false to updates not fail when there is a 
> version conflict
> -
>
> Key: SOLR-13320
> URL: https://issues.apache.org/jira/browse/SOLR-13320
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
> Attachments: SOLR-13320.patch, SOLR-13320.patch, SOLR-13320.patch
>
>
> Updates should have an option to ignore duplicate documents and drop them if 
> an option  {{ignoreDuplicates=true}} is specified



--
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: Call for help: moving from ant build to gradle

[Mark Miller]

I finally got a go ahead from Uwe on Twitter, so looks like we can start in
earnest.

Give me a day or two to get my experimentación branch in order and I’ll
share.

Like I said, I grabbed Dat’s buildSrc module which has the forbidden apis
and project checkout checks.

Then I integrated in a way that you don’t have to move src or test resource
files - ideal in general, but also critical for keeping things up to date
during dev.

I also grabbed Palantirs versión consistency plugin that ensures consistent
version resolution across modules and has better version locking than
Gradle, with a root dependency/version lock file with one dependency per
line that gets written out.

I’m also almost done moving version specifications to a root properties
file as that plugin expects.

I’ve also disabled transitive dependencies and found a way to easily make
modules transitive in the face of that (fingers crossed)

I’ve also started adding some of the regenerate stuff, automata and what
not, still have to do jflex and do some testing.

Currently everything is building and tests are passing, but there is a bit
around dependencies and versioning I want to clean up before sharing for
collaboration.

Mark


-- 
- Mark

http://about.me/markrmiller

[jira] [Commented] (SOLR-13320) add a param failOnVersionConflicts=false to updates not fail when there is a version conflict

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-13320:


Commit 733b071564ac310b537166f15f74dde19f29a488 in lucene-solr's branch 
refs/heads/master from Noble Paul
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=733b071 ]

SOLR-13320 : add an update param failOnVersionConflicts=false to updates not 
fail when there is a version conflict


> add a param failOnVersionConflicts=false to updates not fail when there is a 
> version conflict
> -
>
> Key: SOLR-13320
> URL: https://issues.apache.org/jira/browse/SOLR-13320
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
> Attachments: SOLR-13320.patch, SOLR-13320.patch, SOLR-13320.patch
>
>
> Updates should have an option to ignore duplicate documents and drop them if 
> an option  {{ignoreDuplicates=true}} is specified



--
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-13410) Designated overseer not able to become overseer quickly

[Ishan Chattopadhyaya (JIRA)]

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

Ishan Chattopadhyaya edited comment on SOLR-13410 at 5/6/19 7:30 PM:
-

bq. We can also try using a separate cluster for this or including huge wait 
time before each test can also help.

Making this change helped stability during beasting. Hopefully this stays happy 
now.


was (Author: ichattopadhyaya):
bq. We can also try using a separate cluster for this or including huge wait 
time before each test can also help.

Making a change helped stability during beasting. Hopefully this stays happy 
now.

> Designated overseer not able to become overseer quickly 
> 
>
> Key: SOLR-13410
> URL: https://issues.apache.org/jira/browse/SOLR-13410
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Affects Versions: master (9.0)
>Reporter: Kesharee Nandan Vishwakarma
>Assignee: Ishan Chattopadhyaya
>Priority: Major
> Fix For: 8.1
>
> Attachments: SOLR-13410.patch, SOLR-13410.patch, SOLR-13410.patch, 
> SOLR-13410.patch, overseerElection.log
>
>
> Whenever a designated overseer node is restarted and overseer role is added 
> back if a designated node is not overseer leader following tasks take place:
>  1. one by one nodes from electionNodes list become leader and ask designated 
> node `to come join election at head`
>  2. current overseer node Fires Quit command and exits from Overseer Loop
>  3. Next node from `Overseer Loop` becomes leader repeats steps 1,2 until 
> designated overseer node becomes the leader
>  Problem with above flow: OverseerNodePrioritizer is not able to add 
> `designated node` at the head of electionNodes list
> Steps to reproduce:
>  # Setup solrcloud with 5 nodes, including one designated overseer
>  # Restart overseer container
> Attached relevant logs



--
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-13410) Designated overseer not able to become overseer quickly

[Ishan Chattopadhyaya (JIRA)]

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

Ishan Chattopadhyaya commented on SOLR-13410:
-

bq. We can also try using a separate cluster for this or including huge wait 
time before each test can also help.

Making a change helped stability during beasting. Hopefully this stays happy 
now.

> Designated overseer not able to become overseer quickly 
> 
>
> Key: SOLR-13410
> URL: https://issues.apache.org/jira/browse/SOLR-13410
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Affects Versions: master (9.0)
>Reporter: Kesharee Nandan Vishwakarma
>Assignee: Ishan Chattopadhyaya
>Priority: Major
> Fix For: 8.1
>
> Attachments: SOLR-13410.patch, SOLR-13410.patch, SOLR-13410.patch, 
> SOLR-13410.patch, overseerElection.log
>
>
> Whenever a designated overseer node is restarted and overseer role is added 
> back if a designated node is not overseer leader following tasks take place:
>  1. one by one nodes from electionNodes list become leader and ask designated 
> node `to come join election at head`
>  2. current overseer node Fires Quit command and exits from Overseer Loop
>  3. Next node from `Overseer Loop` becomes leader repeats steps 1,2 until 
> designated overseer node becomes the leader
>  Problem with above flow: OverseerNodePrioritizer is not able to add 
> `designated node` at the head of electionNodes list
> Steps to reproduce:
>  # Setup solrcloud with 5 nodes, including one designated overseer
>  # Restart overseer container
> Attached relevant logs



--
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-13410) Designated overseer not able to become overseer quickly

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-13410:


Commit 47886225187c0442e3d6bb93475eafacfccab6ff in lucene-solr's branch 
refs/heads/branch_8_1 from Ishan Chattopadhyaya
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=4788622 ]

SOLR-13410: Making the test more resilient


> Designated overseer not able to become overseer quickly 
> 
>
> Key: SOLR-13410
> URL: https://issues.apache.org/jira/browse/SOLR-13410
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Affects Versions: master (9.0)
>Reporter: Kesharee Nandan Vishwakarma
>Assignee: Ishan Chattopadhyaya
>Priority: Major
> Fix For: 8.1
>
> Attachments: SOLR-13410.patch, SOLR-13410.patch, SOLR-13410.patch, 
> SOLR-13410.patch, overseerElection.log
>
>
> Whenever a designated overseer node is restarted and overseer role is added 
> back if a designated node is not overseer leader following tasks take place:
>  1. one by one nodes from electionNodes list become leader and ask designated 
> node `to come join election at head`
>  2. current overseer node Fires Quit command and exits from Overseer Loop
>  3. Next node from `Overseer Loop` becomes leader repeats steps 1,2 until 
> designated overseer node becomes the leader
>  Problem with above flow: OverseerNodePrioritizer is not able to add 
> `designated node` at the head of electionNodes list
> Steps to reproduce:
>  # Setup solrcloud with 5 nodes, including one designated overseer
>  # Restart overseer container
> Attached relevant logs



--
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-13410) Designated overseer not able to become overseer quickly

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-13410:


Commit ca29340d8ba3700d8632025b73102ca88d8cb426 in lucene-solr's branch 
refs/heads/master from Ishan Chattopadhyaya
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=ca29340 ]

SOLR-13410: Making the test more resilient


> Designated overseer not able to become overseer quickly 
> 
>
> Key: SOLR-13410
> URL: https://issues.apache.org/jira/browse/SOLR-13410
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Affects Versions: master (9.0)
>Reporter: Kesharee Nandan Vishwakarma
>Assignee: Ishan Chattopadhyaya
>Priority: Major
> Fix For: 8.1
>
> Attachments: SOLR-13410.patch, SOLR-13410.patch, SOLR-13410.patch, 
> SOLR-13410.patch, overseerElection.log
>
>
> Whenever a designated overseer node is restarted and overseer role is added 
> back if a designated node is not overseer leader following tasks take place:
>  1. one by one nodes from electionNodes list become leader and ask designated 
> node `to come join election at head`
>  2. current overseer node Fires Quit command and exits from Overseer Loop
>  3. Next node from `Overseer Loop` becomes leader repeats steps 1,2 until 
> designated overseer node becomes the leader
>  Problem with above flow: OverseerNodePrioritizer is not able to add 
> `designated node` at the head of electionNodes list
> Steps to reproduce:
>  # Setup solrcloud with 5 nodes, including one designated overseer
>  # Restart overseer container
> Attached relevant logs



--
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-13410) Designated overseer not able to become overseer quickly

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-13410:


Commit d92582fa21283603bfe0c026f9bf0877210d0e36 in lucene-solr's branch 
refs/heads/branch_8x from Ishan Chattopadhyaya
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=d92582f ]

SOLR-13410: Making the test more resilient


> Designated overseer not able to become overseer quickly 
> 
>
> Key: SOLR-13410
> URL: https://issues.apache.org/jira/browse/SOLR-13410
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Affects Versions: master (9.0)
>Reporter: Kesharee Nandan Vishwakarma
>Assignee: Ishan Chattopadhyaya
>Priority: Major
> Fix For: 8.1
>
> Attachments: SOLR-13410.patch, SOLR-13410.patch, SOLR-13410.patch, 
> SOLR-13410.patch, overseerElection.log
>
>
> Whenever a designated overseer node is restarted and overseer role is added 
> back if a designated node is not overseer leader following tasks take place:
>  1. one by one nodes from electionNodes list become leader and ask designated 
> node `to come join election at head`
>  2. current overseer node Fires Quit command and exits from Overseer Loop
>  3. Next node from `Overseer Loop` becomes leader repeats steps 1,2 until 
> designated overseer node becomes the leader
>  Problem with above flow: OverseerNodePrioritizer is not able to add 
> `designated node` at the head of electionNodes list
> Steps to reproduce:
>  # Setup solrcloud with 5 nodes, including one designated overseer
>  # Restart overseer container
> Attached relevant logs



--
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-8.x-Solaris (64bit/jdk1.8.0) - Build # 111 - Failure!

[Policeman Jenkins Server]

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

No tests ran.

Build Log:
[...truncated 13015 lines...]
   [junit4] Suite: org.apache.solr.cloud.TestPullReplicaErrorHandling
   [junit4]   2> 284682 INFO  
(SUITE-TestPullReplicaErrorHandling-seed#[5366837DEF97E64E]-worker) [] 
o.a.s.SolrTestCaseJ4 SecureRandom sanity checks: 
test.solr.allowed.securerandom=null & java.security.egd=file:/dev/./urandom
   [junit4]   2> Creating dataDir: 
/export/home/jenkins/workspace/Lucene-Solr-8.x-Solaris/solr/build/solr-core/test/J1/temp/solr.cloud.TestPullReplicaErrorHandling_5366837DEF97E64E-001/init-core-data-001
   [junit4]   2> 284683 WARN  
(SUITE-TestPullReplicaErrorHandling-seed#[5366837DEF97E64E]-worker) [] 
o.a.s.SolrTestCaseJ4 startTrackingSearchers: numOpens=2 numCloses=2
   [junit4]   2> 284683 INFO  
(SUITE-TestPullReplicaErrorHandling-seed#[5366837DEF97E64E]-worker) [] 
o.a.s.SolrTestCaseJ4 Using TrieFields (NUMERIC_POINTS_SYSPROP=false) 
w/NUMERIC_DOCVALUES_SYSPROP=false
   [junit4]   2> 284683 INFO  
(SUITE-TestPullReplicaErrorHandling-seed#[5366837DEF97E64E]-worker) [] 
o.a.s.SolrTestCaseJ4 Randomized ssl (false) and clientAuth (false) via: 
@org.apache.solr.SolrTestCaseJ4$SuppressSSL(bugUrl=https://issues.apache.org/jira/browse/SOLR-5776)
   [junit4]   2> 284683 INFO  
(SUITE-TestPullReplicaErrorHandling-seed#[5366837DEF97E64E]-worker) [] 
o.a.s.c.MiniSolrCloudCluster Starting cluster of 4 servers in 
/export/home/jenkins/workspace/Lucene-Solr-8.x-Solaris/solr/build/solr-core/test/J1/temp/solr.cloud.TestPullReplicaErrorHandling_5366837DEF97E64E-001/tempDir-001
   [junit4]   2> 284687 INFO  
(SUITE-TestPullReplicaErrorHandling-seed#[5366837DEF97E64E]-worker) [] 
o.a.s.c.ZkTestServer STARTING ZK TEST SERVER
   [junit4]   2> 284687 INFO  (ZkTestServer Run Thread) [] 
o.a.s.c.ZkTestServer client port:0.0.0.0/0.0.0.0:0
   [junit4]   2> 284687 INFO  (ZkTestServer Run Thread) [] 
o.a.s.c.ZkTestServer Starting server
   [junit4]   2> 284787 INFO  
(SUITE-TestPullReplicaErrorHandling-seed#[5366837DEF97E64E]-worker) [] 
o.a.s.c.ZkTestServer start zk server on port:56159
   [junit4]   2> 284787 INFO  
(SUITE-TestPullReplicaErrorHandling-seed#[5366837DEF97E64E]-worker) [] 
o.a.s.c.ZkTestServer parse host and port list: 127.0.0.1:56159
   [junit4]   2> 284787 INFO  
(SUITE-TestPullReplicaErrorHandling-seed#[5366837DEF97E64E]-worker) [] 
o.a.s.c.ZkTestServer connecting to 127.0.0.1 56159
   [junit4]   2> 284794 INFO  (zkConnectionManagerCallback-1671-thread-1) [
] o.a.s.c.c.ConnectionManager zkClient has connected
   [junit4]   2> 284798 INFO  (zkConnectionManagerCallback-1673-thread-1) [
] o.a.s.c.c.ConnectionManager zkClient has connected
   [junit4]   2> 284801 INFO  (zkConnectionManagerCallback-1675-thread-1) [
] o.a.s.c.c.ConnectionManager zkClient has connected
   [junit4]   2> 284803 WARN  (jetty-launcher-1676-thread-1) [] 
o.e.j.s.AbstractConnector Ignoring deprecated socket close linger time
   [junit4]   2> 284803 INFO  (jetty-launcher-1676-thread-1) [] 
o.a.s.c.s.e.JettySolrRunner Start Jetty (original configured port=0)
   [junit4]   2> 284803 INFO  (jetty-launcher-1676-thread-1) [] 
o.a.s.c.s.e.JettySolrRunner Trying to start Jetty on port 0 try number 1 ...
   [junit4]   2> 284803 INFO  (jetty-launcher-1676-thread-1) [] 
o.e.j.s.Server jetty-9.4.14.v20181114; built: 2018-11-14T21:20:31.478Z; git: 
c4550056e785fb5665914545889f21dc136ad9e6; jvm 1.8.0_201-b09
   [junit4]   2> 284803 WARN  (jetty-launcher-1676-thread-2) [] 
o.e.j.s.AbstractConnector Ignoring deprecated socket close linger time
   [junit4]   2> 284804 INFO  (jetty-launcher-1676-thread-2) [] 
o.a.s.c.s.e.JettySolrRunner Start Jetty (original configured port=0)
   [junit4]   2> 284804 INFO  (jetty-launcher-1676-thread-2) [] 
o.a.s.c.s.e.JettySolrRunner Trying to start Jetty on port 0 try number 1 ...
   [junit4]   2> 284804 INFO  (jetty-launcher-1676-thread-2) [] 
o.e.j.s.Server jetty-9.4.14.v20181114; built: 2018-11-14T21:20:31.478Z; git: 
c4550056e785fb5665914545889f21dc136ad9e6; jvm 1.8.0_201-b09
   [junit4]   2> 284805 WARN  (jetty-launcher-1676-thread-4) [] 
o.e.j.s.AbstractConnector Ignoring deprecated socket close linger time
   [junit4]   2> 284805 INFO  (jetty-launcher-1676-thread-4) [] 
o.a.s.c.s.e.JettySolrRunner Start Jetty (original configured port=0)
   [junit4]   2> 284805 INFO  (jetty-launcher-1676-thread-4) [] 
o.a.s.c.s.e.JettySolrRunner Trying to start Jetty on port 0 try number 1 ...
   [junit4]   2> 284805 INFO  (jetty-launcher-1676-thread-4) [] 
o.e.j.s.Server jetty-9.4.14.v20181114; built: 2018-11-14T21:20:31.478Z; git: 
c4550056e785fb5665914545889f21dc136ad9e6; jvm 1.8.0_201-b09
   [junit4]   2> 284806 INFO  (jetty-launcher-1676-thread-1) [] 
o.e.j.s.session DefaultSessionIdManager workerName=node0
   [junit4]   2> 284806 

[jira] [Commented] (LUCENE-8757) Better Segment To Thread Mapping Algorithm

[Atri Sharma (JIRA)]

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

Atri Sharma commented on LUCENE-8757:
-

Hi [~simonw],

 

Spending a bit more time thinking about your suggestions, I agree that it is a 
great idea, albeit requiring more thought and effort than what this Jira 
proposes to achieve.

I have opened LUCENE-8794 - Cost Based Slice Allocation Algorithm for 
discussing the same. Please share your thoughts.

 

Would it make sense to push this patch, and then let users consume it and 
provide feedback while we iterate on the more sophisticated version? We could 
even have both of the methods available as options to users, potentially

 

Thoughts?

 

> Better Segment To Thread Mapping Algorithm
> --
>
> Key: LUCENE-8757
> URL: https://issues.apache.org/jira/browse/LUCENE-8757
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Atri Sharma
>Priority: Major
> Attachments: LUCENE-8757.patch
>
>
> The current segments to threads allocation algorithm always allocates one 
> thread per segment. This is detrimental to performance in case of skew in 
> segment sizes since small segments also get their dedicated thread. This can 
> lead to performance degradation due to context switching overheads.
>  
> A better algorithm which is cognizant of size skew would have better 
> performance for realistic scenarios



--
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: precommit failures

[Uwe Schindler]

I am not fully sure if the "java.naming" module is enabled by default in Java 
11. Maybe that's a side effect of some global configuration parameter.

Is Java version really fully identical including vendor?

The strange thing is that only ecj breaks. Could it be that you have older 
version of ecj in ant's classpath?

Uwe

Am May 6, 2019 7:47:45 PM UTC schrieb Erick Erickson :
>Weirder and weirder. My mac pro precommits successfully, same Java
>version but my MBP fails every time.
>
>> On May 6, 2019, at 9:03 AM, Dawid Weiss 
>wrote:
>> 
>> I had it this morning before committing the fst patch from Mike.
>> Cleaned the repo, re-ran precommit and it passed... Very strange.
>> 
>> D.
>> 
>> On Mon, May 6, 2019 at 5:53 PM Erick Erickson
> wrote:
>>> 
>>> 
>>> Both Kevin Risden and I are seeing:
>>> 
>>> [ecj-lint] 1. ERROR in
>/Users/Erick/apache/solrVersions/playspace/solr/contrib/dataimporthandler/src/java/org/apache/solr/handler/dataimport/JdbcDataSource.java
>(at line 28)
>>> [ecj-lint] import javax.naming.InitialContext;
>>> [ecj-lint]^^^
>>> [ecj-lint] The type javax.naming.InitialContext is not accessible```
>>> 
>>> This import hasn’t been changed since 2009.
>>> 
>>> I'm using: openjdk version “11.0.2” 2019-01-15
>>> 
>>> I tried a fresh clone of master and cleaned the ivy cache, still the
>same problem. But we can't be the only ones seeing this, any clues?
>>>
>-
>>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>> 
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>> 
>
>
>-
>To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>For additional commands, e-mail: dev-h...@lucene.apache.org

--
Uwe Schindler
Achterdiek 19, 28357 Bremen
https://www.thetaphi.de

[jira] [Created] (LUCENE-8794) Cost Based Slice Allocation Algorithm

[Atri Sharma (JIRA)]

Atri Sharma created LUCENE-8794:
---

 Summary: Cost Based Slice Allocation Algorithm
 Key: LUCENE-8794
 URL: https://issues.apache.org/jira/browse/LUCENE-8794
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Atri Sharma


In https://issues.apache.org/jira/browse/LUCENE-8757, the idea of a cost based 
and dynamically adjusting slice allocation algorithm was conceived. We should 
ideally have a hard cap on the number of threads that can be consumed by a 
single query, and have static cost factors associated with segments and assign 
them to threads in a fair manner. We will also need to ensure that we end up 
not assigning individual threads to small segments, or making more thread s 
that needed (thread context switching could outweight benefits).



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

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

Re: Lucene/Solr 8.1

[Ishan Chattopadhyaya]

Provided there are no reproducible failures, I'll spin up an RC in
12-16 hours time.

On Fri, May 3, 2019 at 5:35 PM Ishan Chattopadhyaya
 wrote:
>
> No problem and thanks Uwe!
>
> On Fri, 3 May, 2019, 5:33 PM Uwe Schindler,  wrote:
>>
>> 8.1 Jobs are running on Jenkins since this morning - sorry for the delay.
>>
>> Uwe
>>
>> -
>> Uwe Schindler
>> Achterdiek 19, D-28357 Bremen
>> https://www.thetaphi.de
>> eMail: u...@thetaphi.de
>>
>> > -Original Message-
>> > From: Ishan Chattopadhyaya 
>> > Sent: Wednesday, May 1, 2019 11:54 AM
>> > To: Lucene Dev 
>> > Subject: Re: Lucene/Solr 8.1
>> >
>> > I've cut the release branch, branch_8_1.
>> > Seems like I don't have authorization to create a new Jenkins job for
>> > 8.1. Can someone with the access please help?
>> >
>> > On Tue, Apr 30, 2019 at 9:48 PM Ishan Chattopadhyaya
>> >  wrote:
>> > >
>> > > Hi all,
>> > > I'll cut the release branch in around 12-18 hours.
>> > > Planning to build the first RC on 2nd May.
>> > > Thanks and regards,
>> > > Ishan
>> > >
>> > > On Fri, Apr 19, 2019 at 12:04 AM Joel Bernstein 
>> > wrote:
>> > > >
>> > > > +1 to April 30th timeframe.
>> > > >
>> > > > On Thu, Apr 18, 2019 at 12:40 PM Erick Erickson
>> >  wrote:
>> > > >>
>> > > >> 30 Apr seems reasonable to me for cutting the branch.
>> > > >>
>> > > >> Thanks!
>> > > >>
>> > > >> > On Apr 18, 2019, at 9:23 AM, Ishan Chattopadhyaya
>> >  wrote:
>> > > >> >
>> > > >> >> I'm expecting
>> > > >> >> you'd build a RC soon after cutting the branch?
>> > > >> >
>> > > >> > Sure, maybe a day or two after the branch cutting.
>> > > >> >
>> > > >> >
>> > > >> > On Wed, Apr 17, 2019 at 8:51 PM Adrien Grand 
>> > wrote:
>> > > >> >>
>> > > >> >> +1 to do a 8.1 soon too, thanks Ishan for volunteering! I'm 
>> > > >> >> expecting
>> > > >> >> you'd build a RC soon after cutting the branch?
>> > > >> >>
>> > > >> >> On Wed, Apr 17, 2019 at 10:08 AM Ishan Chattopadhyaya
>> > > >> >>  wrote:
>> > > >> >>>
>> > > >> >>> +1 for a 8.1 soon. I can volunteer for RM.
>> > > >> >>> Does 30 April (about 2 weeks from now) sound reasonable for a
>> > branch cutting?
>> > > >> >>>
>> > > >> >>> On Wed, Apr 17, 2019 at 1:14 PM Ignacio Vera
>> >  wrote:
>> > > >> 
>> > > >>  Hi all,
>> > > >> 
>> > > >>  Feature freeze for 8.0 was long time ago (January 29th) and there
>> > is interesting stuff that has not been released yet. In Lucene in 
>> > particular
>> > there is the new BKD tree strategy for segment merging  which provides a
>> > significant performance boost for high dimensions, the new Luke module or
>> > the new query visitor API for naming a few. I see that in Solr there is as 
>> > well
>> > quite a few unreleased changes.
>> > > >> 
>> > > >>  I might not be able to be the release manager this time as I 
>> > > >>  will be
>> > on holidays the next few weeks but I would like to gauge the interest in 
>> > the
>> > community to have a new release soonish.
>> > > >> 
>> > > >>  Cheers,
>> > > >> 
>> > > >>  Ignacio
>> > > >> 
>> > > >> >>>
>> > > >> >>> -
>> > > >> >>> 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
>> > > >> >>
>> > > >> >
>> > > >> > -
>> > > >> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> > > >> > For additional commands, e-mail: dev-h...@lucene.apache.org
>> > > >> >
>> > > >>
>> > > >>
>> > > >> -
>> > > >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> > > >> For additional commands, e-mail: dev-h...@lucene.apache.org
>> > > >>
>> >
>> > -
>> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> > For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>>
>> -
>> 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] Solr-reference-guide-8.x - Build # 2757 - Failure

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Solr-reference-guide-8.x/2757/

Log: 
Started by timer
[EnvInject] - Loading node environment variables.
Building remotely on websites1 (git-websites svn-websites) in workspace 
/home/jenkins/jenkins-slave/workspace/Solr-reference-guide-8.x
No credentials specified
 > git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
 > git config remote.origin.url 
 > https://gitbox.apache.org/repos/asf/lucene-solr.git # timeout=10
Cleaning workspace
 > git rev-parse --verify HEAD # timeout=10
Resetting working tree
 > git reset --hard # timeout=10
 > git clean -fdx # timeout=10
Fetching upstream changes from 
https://gitbox.apache.org/repos/asf/lucene-solr.git
 > git --version # timeout=10
 > git fetch --tags --progress 
 > https://gitbox.apache.org/repos/asf/lucene-solr.git 
 > +refs/heads/*:refs/remotes/origin/*
 > git rev-parse refs/remotes/origin/branch_8x^{commit} # timeout=10
 > git rev-parse refs/remotes/origin/origin/branch_8x^{commit} # timeout=10
Checking out Revision d92582fa21283603bfe0c026f9bf0877210d0e36 
(refs/remotes/origin/branch_8x)
 > git config core.sparsecheckout # timeout=10
 > git checkout -f d92582fa21283603bfe0c026f9bf0877210d0e36
Commit message: "SOLR-13410: Making the test more resilient"
 > git rev-list --no-walk d92582fa21283603bfe0c026f9bf0877210d0e36 # timeout=10
No emails were triggered.
[Solr-reference-guide-8.x] $ /bin/bash -xe /tmp/jenkins5743589639563735362.sh
+ bash dev-tools/scripts/jenkins.build.ref.guide.sh
+ set -e
+ RVM_PATH=/home/jenkins/.rvm
+ RUBY_VERSION=ruby-2.3.3
+ GEMSET=solr-refguide-gemset
+ curl -sSL https://get.rvm.io
+ bash -s -- --ignore-dotfiles stable
Turning on ignore dotfiles mode.
Downloading https://github.com/rvm/rvm/archive/1.29.7.tar.gz
Downloading 
https://github.com/rvm/rvm/releases/download/1.29.7/1.29.7.tar.gz.asc
gpg: Signature made Thu 03 Jan 2019 10:01:48 PM UTC using RSA key ID 39499BDB
gpg: Good signature from "Piotr Kuczynski "
gpg: WARNING: This key is not certified with a trusted signature!
gpg:  There is no indication that the signature belongs to the owner.
Primary key fingerprint: 7D2B AF1C F37B 13E2 069D  6956 105B D0E7 3949 9BDB
GPG verified '/home/jenkins/shared/.rvm/archives/rvm-1.29.7.tgz'
Upgrading the RVM installation in /home/jenkins/shared/.rvm/
Upgrade of RVM in /home/jenkins/shared/.rvm/ is complete.
  * It looks like some old stuff is laying around RVM, you can cleanup with: 
rvm cleanup all

  * No new notes to display.

+ set +x
Running 'source /home/jenkins/.rvm/scripts/rvm'
Running 'rvm cleanup all'
Warning! PATH is not properly set up, 
/home/jenkins/shared/.rvm/gems/ruby-2.3.3/bin is not at first place.
 Usually this is caused by shell initialization files. Search for 
PATH=... entries.
 You can also re-add RVM to your profile by running: rvm get 
stable --auto-dotfiles
 To fix it temporarily in this shell session run: rvm use 
ruby-2.3.3
 To ignore this error add 
rvm_silence_path_mismatch_check_flag=1 to your 
~/.rvmrc file.
Cleaning up rvm archives
Cleaning up rvm repos
Cleaning up rvm src
Cleaning up rvm log
Cleaning up rvm tmp
Cleaning up rvm gemsets
Cleaning up rvm links
Cleanup done.
Running 'rvm autolibs disable'
Warning! PATH is not properly set up, 
/home/jenkins/shared/.rvm/gems/ruby-2.3.3/bin is not at first place.
 Usually this is caused by shell initialization files. Search for 
PATH=... entries.
 You can also re-add RVM to your profile by running: rvm get 
stable --auto-dotfiles
 To fix it temporarily in this shell session run: rvm use 
ruby-2.3.3
 To ignore this error add 
rvm_silence_path_mismatch_check_flag=1 to your 
~/.rvmrc file.
Running 'rvm install ruby-2.3.3'
Warning! PATH is not properly set up, 
/home/jenkins/shared/.rvm/gems/ruby-2.3.3/bin is not at first place.
 Usually this is caused by shell initialization files. Search for 
PATH=... entries.
 You can also re-add RVM to your profile by running: rvm get 
stable --auto-dotfiles
 To fix it temporarily in this shell session run: rvm use 
ruby-2.3.3
 To ignore this error add 
rvm_silence_path_mismatch_check_flag=1 to your 
~/.rvmrc file.
Already installed ruby-2.3.3.
To reinstall use:

rvm reinstall ruby-2.3.3

Running 'rvm gemset create solr-refguide-gemset'
ruby-2.3.3 - #gemset created 
/home/jenkins/shared/.rvm/gems/ruby-2.3.3@solr-refguide-gemset
ruby-2.3.3 - #generating solr-refguide-gemset 
wrappers|/-\|/-\|.-\|/-\|/-.|/-\|/-\|.-\|/-\|/-.|/-\|/-\|.-\|/-\|/-.|/-\|/-\.
Running 'rvm ruby-2.3.3@solr-refguide-gemset'
Using /home/jenkins/shared/.rvm/gems/ruby-2.3.3 with gemset solr-refguide-gemset
Running 'gem install --force --version 3.5.0 jekyll'
Successfully installed jekyll-3.5.0
Parsing documentation for jekyll-3.5.0
Done installing documentation for jekyll after 1 seconds
1 gem 

Re: precommit failures

[Erick Erickson]

Weirder and weirder. My mac pro precommits successfully, same Java version but 
my MBP fails every time.

> On May 6, 2019, at 9:03 AM, Dawid Weiss  wrote:
> 
> I had it this morning before committing the fst patch from Mike.
> Cleaned the repo, re-ran precommit and it passed... Very strange.
> 
> D.
> 
> On Mon, May 6, 2019 at 5:53 PM Erick Erickson  wrote:
>> 
>> 
>> Both Kevin Risden and I are seeing:
>> 
>> [ecj-lint] 1. ERROR in 
>> /Users/Erick/apache/solrVersions/playspace/solr/contrib/dataimporthandler/src/java/org/apache/solr/handler/dataimport/JdbcDataSource.java
>>  (at line 28)
>> [ecj-lint] import javax.naming.InitialContext;
>> [ecj-lint]^^^
>> [ecj-lint] The type javax.naming.InitialContext is not accessible```
>> 
>> This import hasn’t been changed since 2009.
>> 
>> I'm using: openjdk version “11.0.2” 2019-01-15
>> 
>> I tried a fresh clone of master and cleaned the ivy cache, still the same 
>> problem. But we can't be the only ones seeing this, any clues?
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
> 


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

[jira] [Updated] (LUCENE-7840) BooleanQuery.rewriteNoScoring - optimize away any SHOULD clauses if at least 1 MUST/FILTER clause and 0==minShouldMatch

[Atri Sharma (JIRA)]

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

Atri Sharma updated LUCENE-7840:

Attachment: LUCENE-7840.patch

> BooleanQuery.rewriteNoScoring - optimize away any SHOULD clauses if at least 
> 1 MUST/FILTER clause and 0==minShouldMatch
> ---
>
> Key: LUCENE-7840
> URL: https://issues.apache.org/jira/browse/LUCENE-7840
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Hoss Man
>Priority: Major
> Attachments: LUCENE-7840.patch
>
>
> I haven't thought this through completely, let alone write up a patch / test 
> case, but IIUC...
> We should be able to optimize  {{ BooleanQuery rewriteNoScoring() }} so that 
> (after converting MUST clauses to FILTER clauses) we can check for the common 
> case of {{0==getMinimumNumberShouldMatch()}} and throw away any SHOULD 
> clauses as long as there is is at least one FILTER clause.



--
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-7840) BooleanQuery.rewriteNoScoring - optimize away any SHOULD clauses if at least 1 MUST/FILTER clause and 0==minShouldMatch

[Atri Sharma (JIRA)]

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

Atri Sharma commented on LUCENE-7840:
-

[~jim.ferenczi] Attached a patch, please take a look. Thanks

> BooleanQuery.rewriteNoScoring - optimize away any SHOULD clauses if at least 
> 1 MUST/FILTER clause and 0==minShouldMatch
> ---
>
> Key: LUCENE-7840
> URL: https://issues.apache.org/jira/browse/LUCENE-7840
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Hoss Man
>Priority: Major
> Attachments: LUCENE-7840.patch
>
>
> I haven't thought this through completely, let alone write up a patch / test 
> case, but IIUC...
> We should be able to optimize  {{ BooleanQuery rewriteNoScoring() }} so that 
> (after converting MUST clauses to FILTER clauses) we can check for the common 
> case of {{0==getMinimumNumberShouldMatch()}} and throw away any SHOULD 
> clauses as long as there is is at least one FILTER clause.



--
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-13389) rectify discrepencies in socket (and connect) timeout values used throughout the code and tests - probably helping to reduce TimeoutExceptions in tests

[Gus Heck (JIRA)]

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

Gus Heck commented on SOLR-13389:
-

I see two issues here:
 # How do we bring sanity to the management of timeout settings in the 
application
 # What those settings should look like when running the tests

Do we want to deal with both issues here, or maybe separate them? 

> rectify discrepencies in socket (and connect) timeout values used throughout 
> the code and tests - probably helping to reduce TimeoutExceptions in tests
> ---
>
> Key: SOLR-13389
> URL: https://issues.apache.org/jira/browse/SOLR-13389
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Assignee: Hoss Man
>Priority: Major
>
> While looking into some jenkins test failures caused by distributed requests 
> that timeout, i realized that the "socket timeout" aka "idle timeout" aka 
> "SO_TIMEOUT" values used in various places in the code & sample configs can 
> vary significantly, and in the case of *test* configs/code can differ from 
> the default / production configs by an order of magnitude.
> I think we should consider rectifying some of the various places/ways that 
> different values are sprinkled through out the code to reduce the number of 
> (different) places we have magic constants.  I believe a large number of 
> jenkins test failures we currently see due to timeout exceptions are simply 
> because tests (or test configs) override sensible defaults w/values that are 
> too low to be useful.
> (NOTE: all of these problems / discrepancies also apply to "connect timeout" 
> which should probably be addressed at the same time, but for now i'm focusing 
> on the "socket timeout" since it seems to be the bigger problem in jenkins 
> failures -- if we reach consensus on standardizing some values across the 
> board the same approach can be made to connect timeouts at the same time)



--
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-13410) Designated overseer not able to become overseer quickly

[Ishan Chattopadhyaya (JIRA)]

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

Ishan Chattopadhyaya resolved SOLR-13410.
-
Resolution: Fixed

> Designated overseer not able to become overseer quickly 
> 
>
> Key: SOLR-13410
> URL: https://issues.apache.org/jira/browse/SOLR-13410
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Affects Versions: master (9.0)
>Reporter: Kesharee Nandan Vishwakarma
>Assignee: Ishan Chattopadhyaya
>Priority: Major
> Fix For: 8.1
>
> Attachments: SOLR-13410.patch, SOLR-13410.patch, SOLR-13410.patch, 
> SOLR-13410.patch, overseerElection.log
>
>
> Whenever a designated overseer node is restarted and overseer role is added 
> back if a designated node is not overseer leader following tasks take place:
>  1. one by one nodes from electionNodes list become leader and ask designated 
> node `to come join election at head`
>  2. current overseer node Fires Quit command and exits from Overseer Loop
>  3. Next node from `Overseer Loop` becomes leader repeats steps 1,2 until 
> designated overseer node becomes the leader
>  Problem with above flow: OverseerNodePrioritizer is not able to add 
> `designated node` at the head of electionNodes list
> Steps to reproduce:
>  # Setup solrcloud with 5 nodes, including one designated overseer
>  # Restart overseer container
> Attached relevant logs



--
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-13318) JsonFacetingResponse classes should record provide access to count fields as longs

[Munendra S N (JIRA)]

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

Munendra S N commented on SOLR-13318:
-

[~gerlowskija]
Thanks for merging this

In branch_8x and branch_8_1, new methods are introduced and old methods are 
deprecated. In the master, old methods are changed to return long instead of 
int and new methods are not added
So, any one using new methods after 8.1 release, again have to make changes to 
use different methods in 9.0. Would this okay from user perspective?

> JsonFacetingResponse classes should record  provide access to count fields as 
> longs
> ---
>
> Key: SOLR-13318
> URL: https://issues.apache.org/jira/browse/SOLR-13318
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrJ
>Affects Versions: 7.7.1
>Reporter: Jason Gerlowski
>Assignee: Jason Gerlowski
>Priority: Minor
> Attachments: SOLR-13318-branch_8x.patch, SOLR-13318.patch, 
> SOLR-13318.patch
>
>
> JsonFacetingResponse and its series of dependent classes hold a variety of 
> count fields for bucket counts and various optional properties 
> ({{allBuckets}}, {{numBuckets}}, etc.).  Currently, some of the code that 
> parses these values out of the originating NamedList either stores or casts 
> the values as ints.  When doc counts are low this works fine.  But when the 
> doc counts become larger and stray into "long" territory, SolrJ is liable to 
> blow up with ClassCastExceptions.
> A user on the list reported on of these with the partial stack trace:
> {code}
> Caused by: java.lang.ClassCastException: java.lang.Long cannot be cast to 
> java.lang.Integer
>   at 
> org.apache.solr.client.solrj.response.json.NestableJsonFacet.(NestableJsonFacet.java:52)
>   at 
> org.apache.solr.client.solrj.response.QueryResponse.extractJsonFacetingInfo(QueryResponse.java:200)
>   at 
> org.apache.solr.client.solrj.response.QueryResponse.getJsonFacetingResponse(QueryResponse.java:571)
> {code}
> We should fix this so that these classes can be used without incident for any 
> doc counts.



--
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: Call for help: moving from ant build to gradle

[Mark Miller]

Yes, but hopefully just practically useful stuff :)

I think a lot of the cruft and pain now is that we banged and smashed and
pried ant+ivy to act like a modern build system at the expense of
performance issues and a lack of simple features and sophisticated hacks to
get around some of the performance issues, and ...

We also like to pretend we have such great control over our dependencies,
but we are one of the worst behaved libraries in terms of managing our
dependencies in maven central and unnecessary stuff we ship and wrong stuff
we ship for various modules.

A lot of that is just because it's hard to do otherwise with our system.

With groovy its much easier to clean that up and also verify it stays that
way. There are enough hoops to accomplishing that in our current system
that no one deals with it.

It won't all be amazing, but it will be better for sure and we will
certainly have more developer help than in the past.

- Mark

On Mon, May 6, 2019 at 1:36 AM Dawid Weiss  wrote:

> > Switching to gradle means deleting tons of crap - all sorts of work
> arounds and ant abuse go away.
>
> True. But other things will creep in. Take a look at any larger gradle
> build -- there's lots of groovy-code magic in there...
>
> To be clear: I do think the switch over to gradle is worth it (for the
> reasons you mentioned, if not anything else).
>
> Dawid
>
> On Mon, May 6, 2019 at 8:03 AM Mark Miller  wrote:
> >
> > I don't know that we need or want to do side by side, it's just doable.
> If we did do that, certainly the goal would be to keep it short. Whatever
> keeps people from pulling the rug out from under me if I work on this
> further.
> >
> > Any other bike-shedding to be done or major concerns?
> >
> > This really will be a lot of work - one of those the last 20% takes 80%
> of the time type things.
> >
> > Please, please, please, stop me now.
> >
> > - Mark
> >
> >
> > On Sun, May 5, 2019 at 11:39 PM David Smiley 
> wrote:
> >>
> >> I agree that an easier-to-understand build is an important virtue we
> should try to achieve here (for the reasons you mentioned).  Our build is
> too complex and non-standard.  Any other benefits are icing on the cake.
> >>
> >> RE "side by side"; that could weigh us down maintaining more; I hope
> this isn't long term.
> >>
> >> ~ David Smiley
> >> Apache Lucene/Solr Search Developer
> >> http://www.linkedin.com/in/davidwsmiley
> >>
> >>
> >> On Sun, May 5, 2019 at 6:23 PM Mark Miller 
> wrote:
> >>>
> >>> We can indeed make them work side by side.
> >>>
> >>> - Mark
> >>>
> >>> On Sun, May 5, 2019 at 11:36 AM Erick Erickson <
> erickerick...@gmail.com> wrote:
> 
>  I don’t know enough about the differences to even think consider
> complaining.
> 
>  Is the proposal that we use Gradle for master and continue to use ant
> for 8x? As long as the two build systems can exist side by side (i.e. we
> can build master by executing some Gradle target and continue to build 8x
> with Ant like we always have) the minor inconvenience doesn’t merit
> standing in the way of progress.
> 
>  If that’s the case I don’t particularly care if we continue to use
> Ant with 8x forever. Or maybe some ambitious person can work on bringing 8x
> to Gradle after it has some mileage on master.
> 
>  And I have great faith that you wouldn’t be putting in the work
> unless you thought it was worth it ;)
> 
>  Erick
> 
>  > On May 4, 2019, at 10:31 PM, Mark Miller 
> wrote:
>  >
>  > We already dump out to groovy to do anything interesting, so I
> doubt there is much we can't replicate.
>  >
>  > - Mark
>  >
>  > On Sat, May 4, 2019 at 9:09 PM Ishan Chattopadhyaya <
> ichattopadhy...@gmail.com> wrote:
>  > Would beasting of tests be possible through gradle?
>  >
>  > On Sun, May 5, 2019 at 7:33 AM Mark Miller 
> wrote:
>  > >
>  > > I looked into this a little more.
>  > >
>  > > Seems if we just do it with master and going forward, we don’t
> need multi version support - Uwe seems to have taken it out with the move
> to Java 11?
>  > >
>  > > I can handle regenerate.
>  > >
>  > > The other quality checks shouldn’t be crazy.
>  > >
>  > > So I guess we can probably do this, but before I focus on BS
> details, please speak up if you hate the idea of Gradle and you have the
> clout to stop it.
>  > >
>  > >
>  > > Mark
>  > >
>  > >
>  > >
>  > >
>  > > On Sat, May 4, 2019 at 5:56 PM Mark Miller 
> wrote:
>  > >>
>  > >> I've got my own lucene-solr gradle branch as well.
>  > >>
>  > >> I stole the BuildPlugin and CheckWorkingCopy from Dat's branch,
> but also made some changes.
>  > >>
>  > >> * Similar to above above, I don't move the src files so it can
> keep things up to date without lots of pain.
>  > >> * I used a plugin that lets us define versions in a root props
> file like we currently do and ensures we use 

[JENKINS] Lucene-Solr-BadApples-8.x-Linux (64bit/jdk-11.0.2) - Build # 54 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-BadApples-8.x-Linux/54/
Java: 64bit/jdk-11.0.2 -XX:+UseCompressedOops -XX:+UseSerialGC

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

Error Message:
 Timeout waiting to see state for collection=collection1 
:DocCollection(collection1//collections/collection1/state.json/15)={   
"pullReplicas":"0",   "replicationFactor":"2",   "shards":{"shard1":{   
"range":"8000-7fff",   "state":"active",   "replicas":{ 
"core_node2":{   "core":"collection1_shard1_replica_n1",   
"base_url":"http://127.0.0.1:46197/solr;,   
"node_name":"127.0.0.1:46197_solr",   "state":"down",   
"type":"NRT",   "force_set_state":"false"}, "core_node4":{  
 "core":"collection1_shard1_replica_n3",   
"base_url":"http://127.0.0.1:40351/solr;,   
"node_name":"127.0.0.1:40351_solr",   "state":"active",   
"type":"NRT",   "force_set_state":"false",   
"leader":"true",   "router":{"name":"compositeId"},   
"maxShardsPerNode":"2",   "autoAddReplicas":"false",   "nrtReplicas":"2",   
"tlogReplicas":"0"} Live Nodes: [127.0.0.1:40351_solr, 127.0.0.1:46197_solr] 
Last available state: 
DocCollection(collection1//collections/collection1/state.json/15)={   
"pullReplicas":"0",   "replicationFactor":"2",   "shards":{"shard1":{   
"range":"8000-7fff",   "state":"active",   "replicas":{ 
"core_node2":{   "core":"collection1_shard1_replica_n1",   
"base_url":"http://127.0.0.1:46197/solr;,   
"node_name":"127.0.0.1:46197_solr",   "state":"down",   
"type":"NRT",   "force_set_state":"false"}, "core_node4":{  
 "core":"collection1_shard1_replica_n3",   
"base_url":"http://127.0.0.1:40351/solr;,   
"node_name":"127.0.0.1:40351_solr",   "state":"active",   
"type":"NRT",   "force_set_state":"false",   
"leader":"true",   "router":{"name":"compositeId"},   
"maxShardsPerNode":"2",   "autoAddReplicas":"false",   "nrtReplicas":"2",   
"tlogReplicas":"0"}

Stack Trace:
java.lang.AssertionError: 
Timeout waiting to see state for collection=collection1 
:DocCollection(collection1//collections/collection1/state.json/15)={
  "pullReplicas":"0",
  "replicationFactor":"2",
  "shards":{"shard1":{
  "range":"8000-7fff",
  "state":"active",
  "replicas":{
"core_node2":{
  "core":"collection1_shard1_replica_n1",
  "base_url":"http://127.0.0.1:46197/solr;,
  "node_name":"127.0.0.1:46197_solr",
  "state":"down",
  "type":"NRT",
  "force_set_state":"false"},
"core_node4":{
  "core":"collection1_shard1_replica_n3",
  "base_url":"http://127.0.0.1:40351/solr;,
  "node_name":"127.0.0.1:40351_solr",
  "state":"active",
  "type":"NRT",
  "force_set_state":"false",
  "leader":"true",
  "router":{"name":"compositeId"},
  "maxShardsPerNode":"2",
  "autoAddReplicas":"false",
  "nrtReplicas":"2",
  "tlogReplicas":"0"}
Live Nodes: [127.0.0.1:40351_solr, 127.0.0.1:46197_solr]
Last available state: 
DocCollection(collection1//collections/collection1/state.json/15)={
  "pullReplicas":"0",
  "replicationFactor":"2",
  "shards":{"shard1":{
  "range":"8000-7fff",
  "state":"active",
  "replicas":{
"core_node2":{
  "core":"collection1_shard1_replica_n1",
  "base_url":"http://127.0.0.1:46197/solr;,
  "node_name":"127.0.0.1:46197_solr",
  "state":"down",
  "type":"NRT",
  "force_set_state":"false"},
"core_node4":{
  "core":"collection1_shard1_replica_n3",
  "base_url":"http://127.0.0.1:40351/solr;,
  "node_name":"127.0.0.1:40351_solr",
  "state":"active",
  "type":"NRT",
  "force_set_state":"false",
  "leader":"true",
  "router":{"name":"compositeId"},
  "maxShardsPerNode":"2",
  "autoAddReplicas":"false",
  "nrtReplicas":"2",
  "tlogReplicas":"0"}
at 
__randomizedtesting.SeedInfo.seed([7343DEB582E16F28:FB17E16F2C1D02D0]:0)
at org.junit.Assert.fail(Assert.java:88)
at 
org.apache.solr.cloud.SolrCloudTestCase.waitForState(SolrCloudTestCase.java:310)
at 
org.apache.solr.cloud.SolrCloudTestCase.waitForState(SolrCloudTestCase.java:288)
at 
org.apache.solr.cloud.TestCloudRecovery2.test(TestCloudRecovery2.java:106)
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:566)
at 

Re: Call for help: moving from ant build to gradle

[Dawid Weiss]

> Switching to gradle means deleting tons of crap - all sorts of work arounds 
> and ant abuse go away.

True. But other things will creep in. Take a look at any larger gradle
build -- there's lots of groovy-code magic in there...

To be clear: I do think the switch over to gradle is worth it (for the
reasons you mentioned, if not anything else).

Dawid

On Mon, May 6, 2019 at 8:03 AM Mark Miller  wrote:
>
> I don't know that we need or want to do side by side, it's just doable. If we 
> did do that, certainly the goal would be to keep it short. Whatever keeps 
> people from pulling the rug out from under me if I work on this further.
>
> Any other bike-shedding to be done or major concerns?
>
> This really will be a lot of work - one of those the last 20% takes 80% of 
> the time type things.
>
> Please, please, please, stop me now.
>
> - Mark
>
>
> On Sun, May 5, 2019 at 11:39 PM David Smiley  wrote:
>>
>> I agree that an easier-to-understand build is an important virtue we should 
>> try to achieve here (for the reasons you mentioned).  Our build is too 
>> complex and non-standard.  Any other benefits are icing on the cake.
>>
>> RE "side by side"; that could weigh us down maintaining more; I hope this 
>> isn't long term.
>>
>> ~ David Smiley
>> Apache Lucene/Solr Search Developer
>> http://www.linkedin.com/in/davidwsmiley
>>
>>
>> On Sun, May 5, 2019 at 6:23 PM Mark Miller  wrote:
>>>
>>> We can indeed make them work side by side.
>>>
>>> - Mark
>>>
>>> On Sun, May 5, 2019 at 11:36 AM Erick Erickson  
>>> wrote:

 I don’t know enough about the differences to even think consider 
 complaining.

 Is the proposal that we use Gradle for master and continue to use ant for 
 8x? As long as the two build systems can exist side by side (i.e. we can 
 build master by executing some Gradle target and continue to build 8x with 
 Ant like we always have) the minor inconvenience doesn’t merit standing in 
 the way of progress.

 If that’s the case I don’t particularly care if we continue to use Ant 
 with 8x forever. Or maybe some ambitious person can work on bringing 8x to 
 Gradle after it has some mileage on master.

 And I have great faith that you wouldn’t be putting in the work unless you 
 thought it was worth it ;)

 Erick

 > On May 4, 2019, at 10:31 PM, Mark Miller  wrote:
 >
 > We already dump out to groovy to do anything interesting, so I doubt 
 > there is much we can't replicate.
 >
 > - Mark
 >
 > On Sat, May 4, 2019 at 9:09 PM Ishan Chattopadhyaya 
 >  wrote:
 > Would beasting of tests be possible through gradle?
 >
 > On Sun, May 5, 2019 at 7:33 AM Mark Miller  wrote:
 > >
 > > I looked into this a little more.
 > >
 > > Seems if we just do it with master and going forward, we don’t need 
 > > multi version support - Uwe seems to have taken it out with the move 
 > > to Java 11?
 > >
 > > I can handle regenerate.
 > >
 > > The other quality checks shouldn’t be crazy.
 > >
 > > So I guess we can probably do this, but before I focus on BS details, 
 > > please speak up if you hate the idea of Gradle and you have the clout 
 > > to stop it.
 > >
 > >
 > > Mark
 > >
 > >
 > >
 > >
 > > On Sat, May 4, 2019 at 5:56 PM Mark Miller  
 > > wrote:
 > >>
 > >> I've got my own lucene-solr gradle branch as well.
 > >>
 > >> I stole the BuildPlugin and CheckWorkingCopy from Dat's branch, but 
 > >> also made some changes.
 > >>
 > >> * Similar to above above, I don't move the src files so it can keep 
 > >> things up to date without lots of pain.
 > >> * I used a plugin that lets us define versions in a root props file 
 > >> like we currently do and ensures we use the same versions in all 
 > >> modules even after auto conflict resolution (unlike gradle by default)
 > >> * It also locks versions so we can continue to pay attention to scary 
 > >> automatic dependency resolution changes
 > >> * implementation and api used instead of compile
 > >> * Things build and the majority of tests pass (Lucene's 
 > >> TestVirtualMethod does not for example)
 > >>
 > >> If someone like Uwe is serious about helping out with fun extras 
 > >> (regenerating sources, extracting data from ICU, quality checks, 
 > >> documentation (XSLT)), I'd look at contributing.
 > >>
 > >> - Mark
 > >>
 > >>
 > >> On Mon, Apr 8, 2019 at 9:44 AM Đạt Cao Mạnh  
 > >> wrote:
 > >>>
 > >>> Cool Diego,
 > >>>
 > >>> I will take a look on this. Thanks a lot!
 > >>
 > >>
 > >>
 > >> --
 > >> - Mark
 > >>
 > >> http://about.me/markrmiller
 > >
 > > --
 > > - Mark
 > >
 > > http://about.me/markrmiller
 >
 >
 > --
 > - Mark
 >
 > 

[jira] [Commented] (SOLR-13331) Atomic Update Multivalue remove does not work

[JIRA]

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

Thomas Wöckinger commented on SOLR-13331:
-

I nearly finished refactoring and unit tests, is it possible to do a pull 
request over github?

> Atomic Update Multivalue remove does not work
> -
>
> Key: SOLR-13331
> URL: https://issues.apache.org/jira/browse/SOLR-13331
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: UpdateRequestProcessors
>Affects Versions: 7.7, 7.7.1, 8.0
> Environment: Standalone Solr Server
>Reporter: Thomas Wöckinger
>Assignee: Jason Gerlowski
>Priority: Critical
>  Labels: patch
> Fix For: 7.7.2, 8.1, master (9.0)
>
> Attachments: Fix-SOLR13331-Add-toNativeType-implementations.patch, 
> SOLR-13331.patch
>
>
> When using JavaBinCodec the values of collections are of type 
> ByteArrayUtf8CharSequence, existing field values are Strings so the remove 
> Operation does not have any effect.
> The relevant code is located in class AtomicUpdateDocumentMerger method 
> doRemove.
> The method parameter fieldVal contains the collection values of type 
> ByteArrayUtf8CharSequence, the variable original contains the collection of 
> Strings



--
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: Call for help: moving from ant build to gradle

[Mark Miller]

I don't know that we need or want to do side by side, it's just doable. If
we did do that, certainly the goal would be to keep it short. Whatever
keeps people from pulling the rug out from under me if I work on this
further.

Any other bike-shedding to be done or major concerns?

This really will be a lot of work - one of those the last 20% takes 80% of
the time type things.

Please, please, please, stop me now.

- Mark


On Sun, May 5, 2019 at 11:39 PM David Smiley 
wrote:

> I agree that an easier-to-understand build is an important virtue we
> should try to achieve here (for the reasons you mentioned).  Our build is
> too complex and non-standard.  Any other benefits are icing on the cake.
>
> RE "side by side"; that could weigh us down maintaining more; I hope this
> isn't long term.
>
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley
>
>
> On Sun, May 5, 2019 at 6:23 PM Mark Miller  wrote:
>
>> We can indeed make them work side by side.
>>
>> - Mark
>>
>> On Sun, May 5, 2019 at 11:36 AM Erick Erickson 
>> wrote:
>>
>>> I don’t know enough about the differences to even think consider
>>> complaining.
>>>
>>> Is the proposal that we use Gradle for master and continue to use ant
>>> for 8x? As long as the two build systems can exist side by side (i.e. we
>>> can build master by executing some Gradle target and continue to build 8x
>>> with Ant like we always have) the minor inconvenience doesn’t merit
>>> standing in the way of progress.
>>>
>>> If that’s the case I don’t particularly care if we continue to use Ant
>>> with 8x forever. Or maybe some ambitious person can work on bringing 8x to
>>> Gradle after it has some mileage on master.
>>>
>>> And I have great faith that you wouldn’t be putting in the work unless
>>> you thought it was worth it ;)
>>>
>>> Erick
>>>
>>> > On May 4, 2019, at 10:31 PM, Mark Miller 
>>> wrote:
>>> >
>>> > We already dump out to groovy to do anything interesting, so I doubt
>>> there is much we can't replicate.
>>> >
>>> > - Mark
>>> >
>>> > On Sat, May 4, 2019 at 9:09 PM Ishan Chattopadhyaya <
>>> ichattopadhy...@gmail.com> wrote:
>>> > Would beasting of tests be possible through gradle?
>>> >
>>> > On Sun, May 5, 2019 at 7:33 AM Mark Miller 
>>> wrote:
>>> > >
>>> > > I looked into this a little more.
>>> > >
>>> > > Seems if we just do it with master and going forward, we don’t need
>>> multi version support - Uwe seems to have taken it out with the move to
>>> Java 11?
>>> > >
>>> > > I can handle regenerate.
>>> > >
>>> > > The other quality checks shouldn’t be crazy.
>>> > >
>>> > > So I guess we can probably do this, but before I focus on BS
>>> details, please speak up if you hate the idea of Gradle and you have the
>>> clout to stop it.
>>> > >
>>> > >
>>> > > Mark
>>> > >
>>> > >
>>> > >
>>> > >
>>> > > On Sat, May 4, 2019 at 5:56 PM Mark Miller 
>>> wrote:
>>> > >>
>>> > >> I've got my own lucene-solr gradle branch as well.
>>> > >>
>>> > >> I stole the BuildPlugin and CheckWorkingCopy from Dat's branch, but
>>> also made some changes.
>>> > >>
>>> > >> * Similar to above above, I don't move the src files so it can keep
>>> things up to date without lots of pain.
>>> > >> * I used a plugin that lets us define versions in a root props file
>>> like we currently do and ensures we use the same versions in all modules
>>> even after auto conflict resolution (unlike gradle by default)
>>> > >> * It also locks versions so we can continue to pay attention to
>>> scary automatic dependency resolution changes
>>> > >> * implementation and api used instead of compile
>>> > >> * Things build and the majority of tests pass (Lucene's
>>> TestVirtualMethod does not for example)
>>> > >>
>>> > >> If someone like Uwe is serious about helping out with fun extras
>>> (regenerating sources, extracting data from ICU, quality checks,
>>> documentation (XSLT)), I'd look at contributing.
>>> > >>
>>> > >> - Mark
>>> > >>
>>> > >>
>>> > >> On Mon, Apr 8, 2019 at 9:44 AM Đạt Cao Mạnh <
>>> caomanhdat...@gmail.com> wrote:
>>> > >>>
>>> > >>> Cool Diego,
>>> > >>>
>>> > >>> I will take a look on this. Thanks a lot!
>>> > >>
>>> > >>
>>> > >>
>>> > >> --
>>> > >> - Mark
>>> > >>
>>> > >> http://about.me/markrmiller
>>> > >
>>> > > --
>>> > > - Mark
>>> > >
>>> > > http://about.me/markrmiller
>>> >
>>> >
>>> > --
>>> > - Mark
>>> >
>>> > http://about.me/markrmiller
>>>
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>>
>>>
>>
>> --
>> - Mark
>>
>> http://about.me/markrmiller
>>
>

-- 
- Mark

http://about.me/markrmiller

[jira] [Commented] (LUCENE-8793) Enhanced UI for CustomAnalyzer : show analysis steps

[Tomoko Uchida (JIRA)]

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

Tomoko Uchida commented on LUCENE-8793:
---

[~jun_o]: thanks for the nice patch!

I did some sanity checks locally. First of all, this works for me by the ant 
target: {{ant -f lucene/luke/build.xml run}} :)

I noticed a few things:

1. Javadocs linter failed, so {{ant precommit}} also failed.
{code:java}
-documentation-lint:
 [echo] checking for broken html...
[jtidy] FIXME: Broken HTML checks were disabled, as jtidy can't handle 
HTML5.
 [echo] Checking for broken links...
 [exec] 
 [exec] Crawl/parse...
 [exec] 
 [exec] Verify...
 [echo] Checking for missing docs...
 [exec] 
 [exec] 
build/docs/luke/org/apache/lucene/luke/app/desktop/components/fragments/analysis/package-summary.html
 [exec]   missing description: 
SimpleAnalyzeResultPanelOperator.TokensTableModel
 [exec]   missing description: SimpleAnalyzeResultPanelProvider
 [exec]   missing description: 
StepByStepAnalyzeResultPanelOperator.NamedTokensTableModel
 [exec]   missing description: StepByStepAnalyzeResultPanelProvider
 [exec] 
 [exec] Missing javadocs were found!

BUILD FAILED
{code}
But we can delay this until all other things are done.

2. Omitting char filters is not intuitive.

I think this patch is not complete without support for the charfilters, because 
users would expect whole analysis steps are shown in this panel. Maybe we can 
show the results for char filters along with those for tokenizer/tokenfilters 
by laying out the sub-panels vertically, not horizontally? (I have not yet 
checked the details. Just an idea.)

Vertical layout may be also good when you add many filters like this:

!Screenshot from 2019-05-06 13-45-40.png|width=724,height=212!

In this case, I added a char filter and four token filters.

!Screenshot from 2019-05-06 13-46-16.png|width=362,height=216!

 

3. "Test Analyzer Step by Step" button is visible when a "Preset" analyzer is 
selected.

The button does not make sense with preset analyzers, because there is always 
only one step and the result is identical with "Test Analyzer".

I think this button should not be visible (or at least disabled) when "Preset" 
is selected.

4. "Test Analyzer Step by Step" could be a checkbox, not a button.

To me, this functionality looks like an option to change "Test Analyzer" 
behaviour. So I'd use a checkbox (labeled "step-by-step", for example) to 
switch the result panel. Do you have thoughts about this?

And, I just wanted to add comments about the restriction:
{quote}Current patch is only show each tokenizer/filters result independently, 
so the result doesn't show deletion/separation by next filter, e.g. "library" 
by WordDelimiterFilter is different position between other output.
{quote}
Except the support for charfilters as I noted above, it seems to be fine to me. 
This can be done by another issue (in the future.)

I have not yet checked the code... will do soon.

> Enhanced UI for CustomAnalyzer : show analysis steps
> 
>
> Key: LUCENE-8793
> URL: https://issues.apache.org/jira/browse/LUCENE-8793
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/luke
>Reporter: Jun Ohtani
>Priority: Minor
> Attachments: LUCENE-8793.patch, Screen Shot 2019-05-06 at 
> 10.00.57.png, Screenshot from 2019-05-06 13-45-40.png, Screenshot from 
> 2019-05-06 13-46-16.png
>
>
> This is a migrated issue from previous Luke project in GitHub: 
> [https://github.com/DmitryKey/luke/issues/134]
>  
> For on-the-fly inspection / debugging, it is desirable to show the more 
> detailed step by step information in the Custom Analyzer UI.
> This will be just like Solr's Analysis screen,
> [https://lucene.apache.org/solr/guide/7_5/analysis-screen.html]
> or Elasticsearch's {{_analyze}} API and Kibana's Analyzer UI.
> [https://www.elastic.co/guide/en/elasticsearch/reference/current/indices-analyze.html]
> [https://github.com/johtani/analyze-api-ui-plugin]



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

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

[JENKINS] Lucene-Solr-SmokeRelease-8.x - Build # 92 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-8.x/92/

No tests ran.

Build Log:
[...truncated 23880 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 2531 links (2070 relative) to 3358 anchors in 253 files
 [echo] Validated Links & Anchors via: 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.x/solr/build/solr-ref-guide/bare-bones-html/

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

package:

-unpack-solr-tgz:

-ensure-solr-tgz-exists:
[mkdir] Created dir: 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.x/solr/build/solr.tgz.unpacked
[untar] Expanding: 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.x/solr/package/solr-8.2.0.tgz
 into 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.x/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-8.x/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-8.x/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-8.x/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-8.x/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-8.x/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-8.x/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-8.x/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-8.x/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-8.x/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-8.x/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-8.x/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:

[JENKINS-EA] Lucene-Solr-master-Linux (64bit/jdk-13-ea+18) - Build # 24041 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/24041/
Java: 64bit/jdk-13-ea+18 -XX:-UseCompressedOops -XX:+UseG1GC

8 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.update.processor.DistributedUpdateProcessorTest

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([A79804FDC8F9C13D]:0)
at 
com.carrotsearch.randomizedtesting.RandomizedTest.assumeNoException(RandomizedTest.java:742)
at 
org.apache.solr.SolrTestCaseJ4.assumeWorkingMockito(SolrTestCaseJ4.java:374)
at 
org.apache.solr.update.processor.DistributedUpdateProcessorTest.beforeClass(DistributedUpdateProcessorTest.java:60)
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:372)
... 24 more


FAILED:  
junit.framework.TestSuite.org.apache.solr.update.processor.DistributedUpdateProcessorTest

Error Message:


Stack Trace:
java.lang.NullPointerException
at __randomizedtesting.SeedInfo.seed([A79804FDC8F9C13D]:0)
at 
org.apache.solr.update.processor.DistributedUpdateProcessorTest.AfterClass(DistributedUpdateProcessorTest.java:67)
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 

[GitHub] [lucene-solr] janhoy commented on issue #635: SOLR-13371 improve security chapters in refguide

[GitBox]

janhoy commented on issue #635: SOLR-13371 improve security chapters in refguide
URL: https://github.com/apache/lucene-solr/pull/635#issuecomment-489542609
 
 
   Friendly reminder @ctargett (or anyone else who care about ref guide )


This is an automated message from the Apache Git Service.
To respond to the message, please log on to 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] (LUCENE-8791) Add CollectorRescorer

[Atri Sharma (JIRA)]

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

Atri Sharma commented on LUCENE-8791:
-

Hi [~elbek@gmail.com]

 

bq. Yes, it takes CollectorManager instance and it is all it needs. Also It 
makes sense to me that constructor takes CollectorManager because without it, 
there is no point of creating CollectorRescorer. Also as you see It doesn't 
necessarily only run in parallel. if ExecutorService is null then it runs 
sequential, so calling it parallel would be wrong. JavaDoc on constructor 
highlights this.

Ok, I am fine with it as long as it is clearly advertised (maybe add it in the 
class heading's Javadocs itself?)

bq. Corrected it to use ord based assignment.

Could you add a test for this?

I will take another deeper look into the updated patch today and post comments.


> Add CollectorRescorer
> -
>
> Key: LUCENE-8791
> URL: https://issues.apache.org/jira/browse/LUCENE-8791
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Elbek Kamoliddinov
>Priority: Major
> Attachments: LUCENE-8791.patch, LUCENE-8791.patch
>
>
> This is another implementation of query rescorer api (LUCENE-5489). It adds 
> rescoring functionality based on provided CollectorManager. 
>  



--
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-8781) Explore FST direct array arc encoding

[ASF subversion and git services (JIRA)]

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

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

Commit 5c9e7d53511095914bd9cac1e36754517c77ced2 in lucene-solr's branch 
refs/heads/master from Dawid Weiss
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=5c9e7d5 ]

LUCENE-8781: FST lookup performance has been improved in many cases by encoding 
Arcs using full-sized arrays with gaps. The new encoding is enabled for 
postings in the default codec and for suggesters. (Mike Sokolov)


> Explore FST direct array arc encoding 
> --
>
> Key: LUCENE-8781
> URL: https://issues.apache.org/jira/browse/LUCENE-8781
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Mike Sokolov
>Priority: Major
> Attachments: FST-2-4.png, FST-6-9.png, FST-size.png
>
>  Time Spent: 3h
>  Remaining Estimate: 0h
>
> This issue is for exploring an alternate FST encoding of Arcs as full-sized 
> arrays so Arcs are addressed directly by label, avoiding binary search that 
> we use today for arrays of Arcs. PR: 
> https://github.com/apache/lucene-solr/pull/657
> h3. Testing
> ant test passes. I added some unit tests that were helpful in uncovering bugs 
> while
> implementing which are more difficult to chase down when uncovered by the 
> randomized testing we already do. They don't really test anything new; 
> they're just more focused.
> I'm not sure why, but ant precommit failed for me with:
> {noformat}
>  ...lucene-solr/solr/common-build.xml:536: Check for forbidden API calls 
> failed while scanning class 
> 'org.apache.solr.metrics.reporters.SolrGangliaReporterTest' 
> (SolrGangliaReporterTest.java): java.lang.ClassNotFoundException: 
> info.ganglia.gmetric4j.gmetric.GMetric (while looking up details about 
> referenced class 'info.ganglia.gmetric4j.gmetric.GMetric')
> {noformat}
> I also got Test2BFST running (it was originally timing out due to excessive 
> calls to ramBytesUsage(), which seems to have gotten slow), and it passed; 
> that change isn't include here.
> h4. Micro-benchmark
> I timed lookups in FST via FSTEnum.seekExact in a unit test under various 
> conditions. 
> h5. English words
> A test of looking up existing words in a dictionary of ~17 English words 
> shows improvements; the numbers listed are % change in FST size, time to look 
> up (FSTEnum.seekExact) words that are in the dict, and time to look up random 
> strings that are not in the dict. The comparison is against the current 
> codebase with the optimization disabled. A separate comparison of showed no 
> significant change of the baseline (no opto applied) vs the current master 
> FST impl with no code changes applied.
> ||  load=2||   load=4 ||  load=16 ||
> | +4, -6, -7  | +18, -11, -8 | +22, -11.5, -7 |
> The "load factor" used for those measurements controls when direct array arc 
> encoding is used;
> namely when the number of outgoing arcs was > load * (max label - min label).
> h5. sequential and random terms
> The same test, with terms being a sequence of integers as strings shows a 
> larger improvement, around 20% (load=4). This is presumably the best case for 
> this delta, where every Arc is encoded as a direct lookup.
> When random lowercase ASCII strings are used, a smaller improvement of around 
> 4% is seen.
> h4. luceneutil
> Testing w/luceneutil (wikimediumall) we see improvements mostly in the 
> PKLookup case. Other results seem noisy, with perhaps a small improvment in 
> some of the queries.
> {noformat}
> TaskQPS base  StdDevQPS opto  StdDev  
>   Pct diff
>   OrHighHigh6.93  (3.0%)6.89  (3.1%)   
> -0.5% (  -6% -5%)
>OrHighMed   45.15  (3.9%)   44.92  (3.5%)   
> -0.5% (  -7% -7%)
> Wildcard8.72  (4.7%)8.69  (4.6%)   
> -0.4% (  -9% -9%)
>   AndHighLow  274.11  (2.6%)  273.58  (3.1%)   
> -0.2% (  -5% -5%)
>OrHighLow  241.41  (1.9%)  241.11  (3.5%)   
> -0.1% (  -5% -5%)
>   AndHighMed   52.23  (4.1%)   52.41  (5.3%)
> 0.3% (  -8% -   10%)
>  MedTerm 1026.24  (3.1%) 1030.52  (4.3%)
> 0.4% (  -6% -8%)
> HighTerm .10  (3.4%) 1116.70  (4.0%)
> 0.5% (  -6% -8%)
>HighTermDayOfYearSort   14.59  (8.2%)   14.73  (9.3%)
> 1.0% ( -15% -   20%)
>  AndHighHigh   13.45  (6.2%)   13.61  (4.4%)
> 1.2% (  -8% -   12%)
>HighTermMonthSort   63.09 (12.5%)   64.13 (10.9%)
> 1.6% ( -19% -  

[GitHub] [lucene-solr] dweiss closed pull request #657: LUCENE-8781: FST direct arc addressing

[GitBox]

dweiss closed pull request #657: LUCENE-8781: FST direct arc addressing
URL: https://github.com/apache/lucene-solr/pull/657
 
 
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on to 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-12833) Use timed-out lock in DistributedUpdateProcessor

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-12833:


Commit b2337262b19eb0ec890fc3a3589d4e5754df23db in lucene-solr's branch 
refs/heads/branch_8x from Andrzej Bialecki
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=b233726 ]

SOLR-12833: This test needs the update log - use "enable.update.log" property 
to turn it on.


> Use timed-out lock in DistributedUpdateProcessor
> 
>
> Key: SOLR-12833
> URL: https://issues.apache.org/jira/browse/SOLR-12833
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: update, UpdateRequestProcessors
>Affects Versions: 7.5, 8.0
>Reporter: jefferyyuan
>Assignee: Mark Miller
>Priority: Blocker
> Fix For: 7.7, 8.0, 8.1
>
> Attachments: SOLR-12833-noint.patch, SOLR-12833.patch, 
> SOLR-12833.patch, threadDump.txt
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> There is a synchronize block that blocks other update requests whose IDs fall 
> in the same hash bucket. The update waits forever until it gets the lock at 
> the synchronize block, this can be a problem in some cases.
>  
> Some add/update requests (for example updates with spatial/shape analysis) 
> like may take time (30+ seconds or even more), this would the request time 
> out and fail.
> Client may retry the same requests multiple times or several minutes, this 
> would make things worse.
> The server side receives all the update requests but all except one can do 
> nothing, have to wait there. This wastes precious memory and cpu resource.
> We have seen the case 2000+ threads are blocking at the synchronize lock, and 
> only a few updates are making progress. Each thread takes 3+ mb memory which 
> causes OOM.
> Also if the update can't get the lock in expected time range, its better to 
> fail fast.
>  
> We can have one configuration in solrconfig.xml: 
> updateHandler/versionLock/timeInMill, so users can specify how long they want 
> to wait the version bucket lock.
> The default value can be -1, so it behaves same - wait forever until it gets 
> the lock.



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

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

[GitHub] [lucene-solr] dweiss commented on issue #657: LUCENE-8781: FST direct arc addressing

[GitBox]

dweiss commented on issue #657: LUCENE-8781: FST direct arc addressing
URL: https://github.com/apache/lucene-solr/pull/657#issuecomment-489558774
 
 
   Committed to master, thanks Mike!


This is an automated message from the Apache Git Service.
To respond to the message, please log on to 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] [Resolved] (LUCENE-8781) Explore FST direct array arc encoding

[Dawid Weiss (JIRA)]

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

Dawid Weiss resolved LUCENE-8781.
-
   Resolution: Fixed
 Assignee: Dawid Weiss
Fix Version/s: master (9.0)

> Explore FST direct array arc encoding 
> --
>
> Key: LUCENE-8781
> URL: https://issues.apache.org/jira/browse/LUCENE-8781
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Mike Sokolov
>Assignee: Dawid Weiss
>Priority: Major
> Fix For: master (9.0)
>
> Attachments: FST-2-4.png, FST-6-9.png, FST-size.png
>
>  Time Spent: 3h 20m
>  Remaining Estimate: 0h
>
> This issue is for exploring an alternate FST encoding of Arcs as full-sized 
> arrays so Arcs are addressed directly by label, avoiding binary search that 
> we use today for arrays of Arcs. PR: 
> https://github.com/apache/lucene-solr/pull/657
> h3. Testing
> ant test passes. I added some unit tests that were helpful in uncovering bugs 
> while
> implementing which are more difficult to chase down when uncovered by the 
> randomized testing we already do. They don't really test anything new; 
> they're just more focused.
> I'm not sure why, but ant precommit failed for me with:
> {noformat}
>  ...lucene-solr/solr/common-build.xml:536: Check for forbidden API calls 
> failed while scanning class 
> 'org.apache.solr.metrics.reporters.SolrGangliaReporterTest' 
> (SolrGangliaReporterTest.java): java.lang.ClassNotFoundException: 
> info.ganglia.gmetric4j.gmetric.GMetric (while looking up details about 
> referenced class 'info.ganglia.gmetric4j.gmetric.GMetric')
> {noformat}
> I also got Test2BFST running (it was originally timing out due to excessive 
> calls to ramBytesUsage(), which seems to have gotten slow), and it passed; 
> that change isn't include here.
> h4. Micro-benchmark
> I timed lookups in FST via FSTEnum.seekExact in a unit test under various 
> conditions. 
> h5. English words
> A test of looking up existing words in a dictionary of ~17 English words 
> shows improvements; the numbers listed are % change in FST size, time to look 
> up (FSTEnum.seekExact) words that are in the dict, and time to look up random 
> strings that are not in the dict. The comparison is against the current 
> codebase with the optimization disabled. A separate comparison of showed no 
> significant change of the baseline (no opto applied) vs the current master 
> FST impl with no code changes applied.
> ||  load=2||   load=4 ||  load=16 ||
> | +4, -6, -7  | +18, -11, -8 | +22, -11.5, -7 |
> The "load factor" used for those measurements controls when direct array arc 
> encoding is used;
> namely when the number of outgoing arcs was > load * (max label - min label).
> h5. sequential and random terms
> The same test, with terms being a sequence of integers as strings shows a 
> larger improvement, around 20% (load=4). This is presumably the best case for 
> this delta, where every Arc is encoded as a direct lookup.
> When random lowercase ASCII strings are used, a smaller improvement of around 
> 4% is seen.
> h4. luceneutil
> Testing w/luceneutil (wikimediumall) we see improvements mostly in the 
> PKLookup case. Other results seem noisy, with perhaps a small improvment in 
> some of the queries.
> {noformat}
> TaskQPS base  StdDevQPS opto  StdDev  
>   Pct diff
>   OrHighHigh6.93  (3.0%)6.89  (3.1%)   
> -0.5% (  -6% -5%)
>OrHighMed   45.15  (3.9%)   44.92  (3.5%)   
> -0.5% (  -7% -7%)
> Wildcard8.72  (4.7%)8.69  (4.6%)   
> -0.4% (  -9% -9%)
>   AndHighLow  274.11  (2.6%)  273.58  (3.1%)   
> -0.2% (  -5% -5%)
>OrHighLow  241.41  (1.9%)  241.11  (3.5%)   
> -0.1% (  -5% -5%)
>   AndHighMed   52.23  (4.1%)   52.41  (5.3%)
> 0.3% (  -8% -   10%)
>  MedTerm 1026.24  (3.1%) 1030.52  (4.3%)
> 0.4% (  -6% -8%)
> HighTerm .10  (3.4%) 1116.70  (4.0%)
> 0.5% (  -6% -8%)
>HighTermDayOfYearSort   14.59  (8.2%)   14.73  (9.3%)
> 1.0% ( -15% -   20%)
>  AndHighHigh   13.45  (6.2%)   13.61  (4.4%)
> 1.2% (  -8% -   12%)
>HighTermMonthSort   63.09 (12.5%)   64.13 (10.9%)
> 1.6% ( -19% -   28%)
>  LowTerm 1338.94  (3.3%) 1383.90  (5.5%)
> 3.4% (  -5% -   12%)
> PKLookup  120.45  (2.5%)  130.91  (3.5%)
> 8.7% (   2% -   15%)
> {noformat}
> h4.FST perf tests
> I ran LookupBenchmarkTest to see the impact on the suggesters 

[jira] [Commented] (SOLR-12833) Use timed-out lock in DistributedUpdateProcessor

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-12833:


Commit 2de07e64a959ee380b8bb0159c6193055c969492 in lucene-solr's branch 
refs/heads/branch_7_7 from Andrzej Bialecki
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=2de07e6 ]

SOLR-12833: This test needs the update log - use "enable.update.log" property 
to turn it on.


> Use timed-out lock in DistributedUpdateProcessor
> 
>
> Key: SOLR-12833
> URL: https://issues.apache.org/jira/browse/SOLR-12833
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: update, UpdateRequestProcessors
>Affects Versions: 7.5, 8.0
>Reporter: jefferyyuan
>Assignee: Mark Miller
>Priority: Blocker
> Fix For: 7.7, 8.0, 8.1
>
> Attachments: SOLR-12833-noint.patch, SOLR-12833.patch, 
> SOLR-12833.patch, threadDump.txt
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> There is a synchronize block that blocks other update requests whose IDs fall 
> in the same hash bucket. The update waits forever until it gets the lock at 
> the synchronize block, this can be a problem in some cases.
>  
> Some add/update requests (for example updates with spatial/shape analysis) 
> like may take time (30+ seconds or even more), this would the request time 
> out and fail.
> Client may retry the same requests multiple times or several minutes, this 
> would make things worse.
> The server side receives all the update requests but all except one can do 
> nothing, have to wait there. This wastes precious memory and cpu resource.
> We have seen the case 2000+ threads are blocking at the synchronize lock, and 
> only a few updates are making progress. Each thread takes 3+ mb memory which 
> causes OOM.
> Also if the update can't get the lock in expected time range, its better to 
> fail fast.
>  
> We can have one configuration in solrconfig.xml: 
> updateHandler/versionLock/timeInMill, so users can specify how long they want 
> to wait the version bucket lock.
> The default value can be -1, so it behaves same - wait forever until it gets 
> the lock.



--
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-12833) Use timed-out lock in DistributedUpdateProcessor

[Andrzej Bialecki (JIRA)]

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

Andrzej Bialecki  commented on SOLR-12833:
--

I think it's easier to just set the system property "enable.update.log" and 
clear it after the test. I'll make this change.

> Use timed-out lock in DistributedUpdateProcessor
> 
>
> Key: SOLR-12833
> URL: https://issues.apache.org/jira/browse/SOLR-12833
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: update, UpdateRequestProcessors
>Affects Versions: 7.5, 8.0
>Reporter: jefferyyuan
>Assignee: Mark Miller
>Priority: Blocker
> Fix For: 7.7, 8.0, 8.1
>
> Attachments: SOLR-12833-noint.patch, SOLR-12833.patch, 
> SOLR-12833.patch, threadDump.txt
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> There is a synchronize block that blocks other update requests whose IDs fall 
> in the same hash bucket. The update waits forever until it gets the lock at 
> the synchronize block, this can be a problem in some cases.
>  
> Some add/update requests (for example updates with spatial/shape analysis) 
> like may take time (30+ seconds or even more), this would the request time 
> out and fail.
> Client may retry the same requests multiple times or several minutes, this 
> would make things worse.
> The server side receives all the update requests but all except one can do 
> nothing, have to wait there. This wastes precious memory and cpu resource.
> We have seen the case 2000+ threads are blocking at the synchronize lock, and 
> only a few updates are making progress. Each thread takes 3+ mb memory which 
> causes OOM.
> Also if the update can't get the lock in expected time range, its better to 
> fail fast.
>  
> We can have one configuration in solrconfig.xml: 
> updateHandler/versionLock/timeInMill, so users can specify how long they want 
> to wait the version bucket lock.
> The default value can be -1, so it behaves same - wait forever until it gets 
> the lock.



--
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-13-ea+18) - Build # 24042 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/24042/
Java: 64bit/jdk-13-ea+18 -XX:-UseCompressedOops -XX:+UseSerialGC

8 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.update.processor.DistributedUpdateProcessorTest

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([6318C31A2B6CB264]:0)
at 
com.carrotsearch.randomizedtesting.RandomizedTest.assumeNoException(RandomizedTest.java:742)
at 
org.apache.solr.SolrTestCaseJ4.assumeWorkingMockito(SolrTestCaseJ4.java:374)
at 
org.apache.solr.update.processor.DistributedUpdateProcessorTest.beforeClass(DistributedUpdateProcessorTest.java:60)
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:372)
... 24 more


FAILED:  
junit.framework.TestSuite.org.apache.solr.update.processor.DistributedUpdateProcessorTest

Error Message:


Stack Trace:
java.lang.NullPointerException
at __randomizedtesting.SeedInfo.seed([6318C31A2B6CB264]:0)
at 
org.apache.solr.update.processor.DistributedUpdateProcessorTest.AfterClass(DistributedUpdateProcessorTest.java:68)
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 

[jira] [Commented] (SOLR-12833) Use timed-out lock in DistributedUpdateProcessor

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-12833:


Commit 9617264ff2a3835b514b5fd18e3c8c6fd0d53e42 in lucene-solr's branch 
refs/heads/branch_8_1 from Andrzej Bialecki
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=9617264 ]

SOLR-12833: This test needs the update log - use "enable.update.log" property 
to turn it on.


> Use timed-out lock in DistributedUpdateProcessor
> 
>
> Key: SOLR-12833
> URL: https://issues.apache.org/jira/browse/SOLR-12833
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: update, UpdateRequestProcessors
>Affects Versions: 7.5, 8.0
>Reporter: jefferyyuan
>Assignee: Mark Miller
>Priority: Blocker
> Fix For: 7.7, 8.0, 8.1
>
> Attachments: SOLR-12833-noint.patch, SOLR-12833.patch, 
> SOLR-12833.patch, threadDump.txt
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> There is a synchronize block that blocks other update requests whose IDs fall 
> in the same hash bucket. The update waits forever until it gets the lock at 
> the synchronize block, this can be a problem in some cases.
>  
> Some add/update requests (for example updates with spatial/shape analysis) 
> like may take time (30+ seconds or even more), this would the request time 
> out and fail.
> Client may retry the same requests multiple times or several minutes, this 
> would make things worse.
> The server side receives all the update requests but all except one can do 
> nothing, have to wait there. This wastes precious memory and cpu resource.
> We have seen the case 2000+ threads are blocking at the synchronize lock, and 
> only a few updates are making progress. Each thread takes 3+ mb memory which 
> causes OOM.
> Also if the update can't get the lock in expected time range, its better to 
> fail fast.
>  
> We can have one configuration in solrconfig.xml: 
> updateHandler/versionLock/timeInMill, so users can specify how long they want 
> to wait the version bucket lock.
> The default value can be -1, so it behaves same - wait forever until it gets 
> the lock.



--
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-12833) Use timed-out lock in DistributedUpdateProcessor

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-12833:


Commit ef3b6a1aa39d41e17edb2fdcf0187d22377f56d4 in lucene-solr's branch 
refs/heads/master from Andrzej Bialecki
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=ef3b6a1 ]

SOLR-12833: This test needs the update log - use "enable.update.log" property 
to turn it on.


> Use timed-out lock in DistributedUpdateProcessor
> 
>
> Key: SOLR-12833
> URL: https://issues.apache.org/jira/browse/SOLR-12833
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: update, UpdateRequestProcessors
>Affects Versions: 7.5, 8.0
>Reporter: jefferyyuan
>Assignee: Mark Miller
>Priority: Blocker
> Fix For: 7.7, 8.0, 8.1
>
> Attachments: SOLR-12833-noint.patch, SOLR-12833.patch, 
> SOLR-12833.patch, threadDump.txt
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> There is a synchronize block that blocks other update requests whose IDs fall 
> in the same hash bucket. The update waits forever until it gets the lock at 
> the synchronize block, this can be a problem in some cases.
>  
> Some add/update requests (for example updates with spatial/shape analysis) 
> like may take time (30+ seconds or even more), this would the request time 
> out and fail.
> Client may retry the same requests multiple times or several minutes, this 
> would make things worse.
> The server side receives all the update requests but all except one can do 
> nothing, have to wait there. This wastes precious memory and cpu resource.
> We have seen the case 2000+ threads are blocking at the synchronize lock, and 
> only a few updates are making progress. Each thread takes 3+ mb memory which 
> causes OOM.
> Also if the update can't get the lock in expected time range, its better to 
> fail fast.
>  
> We can have one configuration in solrconfig.xml: 
> updateHandler/versionLock/timeInMill, so users can specify how long they want 
> to wait the version bucket lock.
> The default value can be -1, so it behaves same - wait forever until it gets 
> the lock.



--
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-13331) Atomic Update Multivalue remove does not work

[Jason Gerlowski (JIRA)]

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

Jason Gerlowski commented on SOLR-13331:


Yes, if that's how you prefer to package things up.  Committers who have 
configured their accounts correctly should be able to merge PRs directly from 
the Github UI.  I had some trouble doing this the last time I tried, but this 
will be a good opportunity to force me to fix that.  Please tag me in the 
comments of your PR if you put one together, so I don't miss it. (username: 
gerlowskija)

> Atomic Update Multivalue remove does not work
> -
>
> Key: SOLR-13331
> URL: https://issues.apache.org/jira/browse/SOLR-13331
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: UpdateRequestProcessors
>Affects Versions: 7.7, 7.7.1, 8.0
> Environment: Standalone Solr Server
>Reporter: Thomas Wöckinger
>Assignee: Jason Gerlowski
>Priority: Critical
>  Labels: patch
> Fix For: 7.7.2, 8.1, master (9.0)
>
> Attachments: Fix-SOLR13331-Add-toNativeType-implementations.patch, 
> SOLR-13331.patch
>
>
> When using JavaBinCodec the values of collections are of type 
> ByteArrayUtf8CharSequence, existing field values are Strings so the remove 
> Operation does not have any effect.
> The relevant code is located in class AtomicUpdateDocumentMerger method 
> doRemove.
> The method parameter fieldVal contains the collection values of type 
> ByteArrayUtf8CharSequence, the variable original contains the collection of 
> Strings



--
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-7840) BooleanQuery.rewriteNoScoring - optimize away any SHOULD clauses if at least 1 MUST/FILTER clause and 0==minShouldMatch

[Atri Sharma (JIRA)]

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

Atri Sharma commented on LUCENE-7840:
-

[~jim.ferenczi]

Sure, would it make sense to refactor to move the code to rewriteNoScoring then?

> BooleanQuery.rewriteNoScoring - optimize away any SHOULD clauses if at least 
> 1 MUST/FILTER clause and 0==minShouldMatch
> ---
>
> Key: LUCENE-7840
> URL: https://issues.apache.org/jira/browse/LUCENE-7840
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Hoss Man
>Priority: Major
>
> I haven't thought this through completely, let alone write up a patch / test 
> case, but IIUC...
> We should be able to optimize  {{ BooleanQuery rewriteNoScoring() }} so that 
> (after converting MUST clauses to FILTER clauses) we can check for the common 
> case of {{0==getMinimumNumberShouldMatch()}} and throw away any SHOULD 
> clauses as long as there is is at least one FILTER clause.



--
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-13318) JsonFacetingResponse classes should record provide access to count fields as longs

[Jason Gerlowski (JIRA)]

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

Jason Gerlowski commented on SOLR-13318:


bq. Would this be okay from a user's perspective?

I agree it's not great, but hopefully its good enough.  The approach that I 
took here causes anyone currently using BucketBasedJsonFacet to potentially 
update their code twice.  That's not ideal.  You're right.  But I also didn't 
want new users coming in to 9.0 to see method names that were inconsistent with 
the rest of that group of classes  (e.g. "What does that "count" suffix mean on 
{{getNumBucketsCount}}?  Nothing else has that, maybe it doesn't mean what I 
think").  Both options are non-ideal, but we have to choose one.

I tried to choose the option that would affect the fewest users.  As of 7.x and 
8.0, BucketBasedJsonFacet throws an undeclared exception when used with any 
multi-shard collection. This is a huge problem, and makes the methods arguably 
unusable.  Because of this, there are probably very few BBJF users.  So I opted 
to cause those few users a bit of extra work, in favor of having a more 
consistent interface for the users coming on in 9.x, now that the class is 
safer.

So anyway, there are negative aspects of this approach, but hopefully 
outweighed or mitigated by other things.

> JsonFacetingResponse classes should record  provide access to count fields as 
> longs
> ---
>
> Key: SOLR-13318
> URL: https://issues.apache.org/jira/browse/SOLR-13318
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrJ
>Affects Versions: 7.7.1
>Reporter: Jason Gerlowski
>Assignee: Jason Gerlowski
>Priority: Minor
> Attachments: SOLR-13318-branch_8x.patch, SOLR-13318.patch, 
> SOLR-13318.patch
>
>
> JsonFacetingResponse and its series of dependent classes hold a variety of 
> count fields for bucket counts and various optional properties 
> ({{allBuckets}}, {{numBuckets}}, etc.).  Currently, some of the code that 
> parses these values out of the originating NamedList either stores or casts 
> the values as ints.  When doc counts are low this works fine.  But when the 
> doc counts become larger and stray into "long" territory, SolrJ is liable to 
> blow up with ClassCastExceptions.
> A user on the list reported on of these with the partial stack trace:
> {code}
> Caused by: java.lang.ClassCastException: java.lang.Long cannot be cast to 
> java.lang.Integer
>   at 
> org.apache.solr.client.solrj.response.json.NestableJsonFacet.(NestableJsonFacet.java:52)
>   at 
> org.apache.solr.client.solrj.response.QueryResponse.extractJsonFacetingInfo(QueryResponse.java:200)
>   at 
> org.apache.solr.client.solrj.response.QueryResponse.getJsonFacetingResponse(QueryResponse.java:571)
> {code}
> We should fix this so that these classes can be used without incident for any 
> doc counts.



--
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-7840) BooleanQuery.rewriteNoScoring - optimize away any SHOULD clauses if at least 1 MUST/FILTER clause and 0==minShouldMatch

[Jim Ferenczi (JIRA)]

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

Jim Ferenczi commented on LUCENE-7840:
--

I think so yes, we don't need to build the scorer supplier for the SHOULD 
clauses so it makes sense to move the logic there.

> BooleanQuery.rewriteNoScoring - optimize away any SHOULD clauses if at least 
> 1 MUST/FILTER clause and 0==minShouldMatch
> ---
>
> Key: LUCENE-7840
> URL: https://issues.apache.org/jira/browse/LUCENE-7840
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Hoss Man
>Priority: Major
>
> I haven't thought this through completely, let alone write up a patch / test 
> case, but IIUC...
> We should be able to optimize  {{ BooleanQuery rewriteNoScoring() }} so that 
> (after converting MUST clauses to FILTER clauses) we can check for the common 
> case of {{0==getMinimumNumberShouldMatch()}} and throw away any SHOULD 
> clauses as long as there is is at least one FILTER clause.



--
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-7840) BooleanQuery.rewriteNoScoring - optimize away any SHOULD clauses if at least 1 MUST/FILTER clause and 0==minShouldMatch

[Atri Sharma (JIRA)]

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

Atri Sharma commented on LUCENE-7840:
-

I have a patch for this – will post it shortly

> BooleanQuery.rewriteNoScoring - optimize away any SHOULD clauses if at least 
> 1 MUST/FILTER clause and 0==minShouldMatch
> ---
>
> Key: LUCENE-7840
> URL: https://issues.apache.org/jira/browse/LUCENE-7840
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Hoss Man
>Priority: Major
>
> I haven't thought this through completely, let alone write up a patch / test 
> case, but IIUC...
> We should be able to optimize  {{ BooleanQuery rewriteNoScoring() }} so that 
> (after converting MUST clauses to FILTER clauses) we can check for the common 
> case of {{0==getMinimumNumberShouldMatch()}} and throw away any SHOULD 
> clauses as long as there is is at least one FILTER clause.



--
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-7840) BooleanQuery.rewriteNoScoring - optimize away any SHOULD clauses if at least 1 MUST/FILTER clause and 0==minShouldMatch

[Jim Ferenczi (JIRA)]

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

Jim Ferenczi commented on LUCENE-7840:
--

Note that the logic to remove SHOULD clauses is already implemented when we 
build the Scorer:
https://github.com/apache/lucene-solr/blob/master/lucene/core/src/java/org/apache/lucene/search/BooleanWeight.java#L391
Moving the logic to rewriteNoScoring makes sense to me but this won't optimize 
anything since the removal is already in place.


> BooleanQuery.rewriteNoScoring - optimize away any SHOULD clauses if at least 
> 1 MUST/FILTER clause and 0==minShouldMatch
> ---
>
> Key: LUCENE-7840
> URL: https://issues.apache.org/jira/browse/LUCENE-7840
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Hoss Man
>Priority: Major
>
> I haven't thought this through completely, let alone write up a patch / test 
> case, but IIUC...
> We should be able to optimize  {{ BooleanQuery rewriteNoScoring() }} so that 
> (after converting MUST clauses to FILTER clauses) we can check for the common 
> case of {{0==getMinimumNumberShouldMatch()}} and throw away any SHOULD 
> clauses as long as there is is at least one FILTER clause.



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

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

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

[Apache Jenkins Server]

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

No tests ran.

Build Log:
[...truncated 23470 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 2531 links (2070 relative) to 3358 anchors in 253 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.

[jira] [Commented] (SOLR-13318) JsonFacetingResponse classes should record provide access to count fields as longs

[Jason Gerlowski (JIRA)]

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

Jason Gerlowski commented on SOLR-13318:


Yes, I'd like to backport to 7.7.2 but ran out of time last night.  If I have 
time after work today I'm still aiming for 7.7.2, as long as there's not an RC 
or a freeze before then.

> JsonFacetingResponse classes should record  provide access to count fields as 
> longs
> ---
>
> Key: SOLR-13318
> URL: https://issues.apache.org/jira/browse/SOLR-13318
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrJ
>Affects Versions: 7.7.1
>Reporter: Jason Gerlowski
>Assignee: Jason Gerlowski
>Priority: Minor
> Attachments: SOLR-13318-branch_8x.patch, SOLR-13318.patch, 
> SOLR-13318.patch
>
>
> JsonFacetingResponse and its series of dependent classes hold a variety of 
> count fields for bucket counts and various optional properties 
> ({{allBuckets}}, {{numBuckets}}, etc.).  Currently, some of the code that 
> parses these values out of the originating NamedList either stores or casts 
> the values as ints.  When doc counts are low this works fine.  But when the 
> doc counts become larger and stray into "long" territory, SolrJ is liable to 
> blow up with ClassCastExceptions.
> A user on the list reported on of these with the partial stack trace:
> {code}
> Caused by: java.lang.ClassCastException: java.lang.Long cannot be cast to 
> java.lang.Integer
>   at 
> org.apache.solr.client.solrj.response.json.NestableJsonFacet.(NestableJsonFacet.java:52)
>   at 
> org.apache.solr.client.solrj.response.QueryResponse.extractJsonFacetingInfo(QueryResponse.java:200)
>   at 
> org.apache.solr.client.solrj.response.QueryResponse.getJsonFacetingResponse(QueryResponse.java:571)
> {code}
> We should fix this so that these classes can be used without incident for any 
> doc counts.



--
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-13185) NPE in query parsing because of missing null check

[Charles Sanders (JIRA)]

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

Charles Sanders commented on SOLR-13185:


Added new patch which includes a unit test

> NPE in query parsing because of missing null check
> --
>
> Key: SOLR-13185
> URL: https://issues.apache.org/jira/browse/SOLR-13185
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: query parsers
>Affects Versions: master (9.0)
> Environment: h1. Steps to reproduce
> * Use a Linux machine.
> *  Build commit {{ea2c8ba}} of Solr as described in the section below.
> * Build the films collection as described below.
> * Start the server using the command {{./bin/solr start -f -p 8983 -s 
> /tmp/home}}
> * Request the URL given in the bug description.
> h1. Compiling the server
> {noformat}
> git clone https://github.com/apache/lucene-solr
> cd lucene-solr
> git checkout ea2c8ba
> ant compile
> cd solr
> ant server
> {noformat}
> h1. Building the collection
> We followed [Exercise 
> 2|http://lucene.apache.org/solr/guide/7_5/solr-tutorial.html#exercise-2] from 
> the [Solr 
> Tutorial|http://lucene.apache.org/solr/guide/7_5/solr-tutorial.html]. The 
> attached file ({{home.zip}}) gives the contents of folder {{/tmp/home}} that 
> you will obtain by following the steps below:
> {noformat}
> mkdir -p /tmp/home
> echo '' > 
> /tmp/home/solr.xml
> {noformat}
> In one terminal start a Solr instance in foreground:
> {noformat}
> ./bin/solr start -f -p 8983 -s /tmp/home
> {noformat}
> In another terminal, create a collection of movies, with no shards and no 
> replication, and initialize it:
> {noformat}
> bin/solr create -c films
> curl -X POST -H 'Content-type:application/json' --data-binary '{"add-field": 
> {"name":"name", "type":"text_general", "multiValued":false, "stored":true}}' 
> http://localhost:8983/solr/films/schema
> curl -X POST -H 'Content-type:application/json' --data-binary 
> '{"add-copy-field" : {"source":"*","dest":"_text_"}}' 
> http://localhost:8983/solr/films/schema
> ./bin/post -c films example/films/films.json
> {noformat}
>Reporter: Johannes Kloos
>Priority: Minor
>  Labels: diffblue, newdev
> Attachments: SOLR-13185.patch, SOLR-13185.patch, home.zip
>
>
> Requesting the following URL causes Solr to return an HTTP 500 error response:
> {noformat}
> http://localhost:8983/solr/films/select?defType=complexphrase=AND
> {noformat}
> The error response seems to be caused by the following uncaught exception:
> {noformat}
> java.lang.NullPointerException
> at java.io.StringReader.(StringReader.java:50)
> at 
> org.apache.lucene.queryparser.classic.QueryParserBase.parse(QueryParserBase.java:106)
> at 
> org.apache.lucene.queryparser.complexPhrase.ComplexPhraseQueryParser.parse(ComplexPhraseQueryParser.java:125)
> at 
> org.apache.solr.search.ComplexPhraseQParserPlugin$ComplexPhraseQParser.parse(ComplexPhraseQParserPlugin.java:164)
> at org.apache.solr.search.QParser.getQuery(QParser.java:173)
> at 
> org.apache.solr.handler.component.QueryComponent.prepare(QueryComponent.java:158)
> [...]
> {noformat}
> What happens here is that a querystring (qstr) is passed into a StringReader. 
> Ultimately, this query string comes from the method o.a.s.h.c.QueryComponent, 
> in method prepare (line 157), where it is extracted using rb.queryString() 
> [rb is of type responseBuffer]. The query string stored in the response 
> buffer was earlier on extracted from the request URL by looking for the "q" 
> parameter; note that this parameter is absent in the example request, so qstr 
> would be null. The extracted qstr is then passed to QParser.getParser, which 
> expects a non-null query string.
> We found this bug using [Diffblue Microservices 
> Testing|https://www.diffblue.com/labs/]. Find more information on this [fuzz 
> testing 
> campaign|https://www.diffblue.com/blog/2018/12/19/diffblue-microservice-testing-a-sneak-peek-at-our-early-product-and-results].



--
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-8793) Enhanced UI for CustomAnalyzer : show analysis steps

[Jun Ohtani (JIRA)]

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

Jun Ohtani commented on LUCENE-8793:


Thanks for your comment. 

I will fix 1, 3, and 4.

About 2, I was worry about the difference between current table and step by 
step table if we use vertical layout. There is a confusion. If we use vertical 
layout, we should change the layout current table too.

I agree with you about showing charfilters result. I will try to consider 
layouts.

> Enhanced UI for CustomAnalyzer : show analysis steps
> 
>
> Key: LUCENE-8793
> URL: https://issues.apache.org/jira/browse/LUCENE-8793
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/luke
>Reporter: Jun Ohtani
>Priority: Minor
> Attachments: LUCENE-8793.patch, Screen Shot 2019-05-06 at 
> 10.00.57.png, Screenshot from 2019-05-06 13-45-40.png, Screenshot from 
> 2019-05-06 13-46-16.png
>
>
> This is a migrated issue from previous Luke project in GitHub: 
> [https://github.com/DmitryKey/luke/issues/134]
>  
> For on-the-fly inspection / debugging, it is desirable to show the more 
> detailed step by step information in the Custom Analyzer UI.
> This will be just like Solr's Analysis screen,
> [https://lucene.apache.org/solr/guide/7_5/analysis-screen.html]
> or Elasticsearch's {{_analyze}} API and Kibana's Analyzer UI.
> [https://www.elastic.co/guide/en/elasticsearch/reference/current/indices-analyze.html]
> [https://github.com/johtani/analyze-api-ui-plugin]



--
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-13185) NPE in query parsing because of missing null check

[Charles Sanders (JIRA)]

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

Charles Sanders updated SOLR-13185:
---
Attachment: SOLR-13185.patch

> NPE in query parsing because of missing null check
> --
>
> Key: SOLR-13185
> URL: https://issues.apache.org/jira/browse/SOLR-13185
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: query parsers
>Affects Versions: master (9.0)
> Environment: h1. Steps to reproduce
> * Use a Linux machine.
> *  Build commit {{ea2c8ba}} of Solr as described in the section below.
> * Build the films collection as described below.
> * Start the server using the command {{./bin/solr start -f -p 8983 -s 
> /tmp/home}}
> * Request the URL given in the bug description.
> h1. Compiling the server
> {noformat}
> git clone https://github.com/apache/lucene-solr
> cd lucene-solr
> git checkout ea2c8ba
> ant compile
> cd solr
> ant server
> {noformat}
> h1. Building the collection
> We followed [Exercise 
> 2|http://lucene.apache.org/solr/guide/7_5/solr-tutorial.html#exercise-2] from 
> the [Solr 
> Tutorial|http://lucene.apache.org/solr/guide/7_5/solr-tutorial.html]. The 
> attached file ({{home.zip}}) gives the contents of folder {{/tmp/home}} that 
> you will obtain by following the steps below:
> {noformat}
> mkdir -p /tmp/home
> echo '' > 
> /tmp/home/solr.xml
> {noformat}
> In one terminal start a Solr instance in foreground:
> {noformat}
> ./bin/solr start -f -p 8983 -s /tmp/home
> {noformat}
> In another terminal, create a collection of movies, with no shards and no 
> replication, and initialize it:
> {noformat}
> bin/solr create -c films
> curl -X POST -H 'Content-type:application/json' --data-binary '{"add-field": 
> {"name":"name", "type":"text_general", "multiValued":false, "stored":true}}' 
> http://localhost:8983/solr/films/schema
> curl -X POST -H 'Content-type:application/json' --data-binary 
> '{"add-copy-field" : {"source":"*","dest":"_text_"}}' 
> http://localhost:8983/solr/films/schema
> ./bin/post -c films example/films/films.json
> {noformat}
>Reporter: Johannes Kloos
>Priority: Minor
>  Labels: diffblue, newdev
> Attachments: SOLR-13185.patch, SOLR-13185.patch, home.zip
>
>
> Requesting the following URL causes Solr to return an HTTP 500 error response:
> {noformat}
> http://localhost:8983/solr/films/select?defType=complexphrase=AND
> {noformat}
> The error response seems to be caused by the following uncaught exception:
> {noformat}
> java.lang.NullPointerException
> at java.io.StringReader.(StringReader.java:50)
> at 
> org.apache.lucene.queryparser.classic.QueryParserBase.parse(QueryParserBase.java:106)
> at 
> org.apache.lucene.queryparser.complexPhrase.ComplexPhraseQueryParser.parse(ComplexPhraseQueryParser.java:125)
> at 
> org.apache.solr.search.ComplexPhraseQParserPlugin$ComplexPhraseQParser.parse(ComplexPhraseQParserPlugin.java:164)
> at org.apache.solr.search.QParser.getQuery(QParser.java:173)
> at 
> org.apache.solr.handler.component.QueryComponent.prepare(QueryComponent.java:158)
> [...]
> {noformat}
> What happens here is that a querystring (qstr) is passed into a StringReader. 
> Ultimately, this query string comes from the method o.a.s.h.c.QueryComponent, 
> in method prepare (line 157), where it is extracted using rb.queryString() 
> [rb is of type responseBuffer]. The query string stored in the response 
> buffer was earlier on extracted from the request URL by looking for the "q" 
> parameter; note that this parameter is absent in the example request, so qstr 
> would be null. The extracted qstr is then passed to QParser.getParser, which 
> expects a non-null query string.
> We found this bug using [Diffblue Microservices 
> Testing|https://www.diffblue.com/labs/]. Find more information on this [fuzz 
> testing 
> campaign|https://www.diffblue.com/blog/2018/12/19/diffblue-microservice-testing-a-sneak-peek-at-our-early-product-and-results].



--
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: Call for help: moving from ant build to gradle

[Erick Erickson]

I want to be clear about my question of whether we’d use Gradle for master and 
continue to use Ant for 8x. 

It is _totally_ and _completely_ a matter of what would be easiest and up to 
the people who are doing the heavy lifting. If moving both to Gradle would be 
easiest, that has my vote. If a split process would be easier, then that has my 
vote.

And, frankly, if nobody has speaks up they don’t get a vote AFAIC.

Erick


> On May 6, 2019, at 12:12 AM, Mark Miller  wrote:
> 
> Yes, but hopefully just practically useful stuff :)
> 
> I think a lot of the cruft and pain now is that we banged and smashed and 
> pried ant+ivy to act like a modern build system at the expense of performance 
> issues and a lack of simple features and sophisticated hacks to get around 
> some of the performance issues, and ...
> 
> We also like to pretend we have such great control over our dependencies, but 
> we are one of the worst behaved libraries in terms of managing our 
> dependencies in maven central and unnecessary stuff we ship and wrong stuff 
> we ship for various modules.
> 
> A lot of that is just because it's hard to do otherwise with our system.
> 
> With groovy its much easier to clean that up and also verify it stays that 
> way. There are enough hoops to accomplishing that in our current system that 
> no one deals with it.
> 
> It won't all be amazing, but it will be better for sure and we will certainly 
> have more developer help than in the past.
> 
> - Mark
> 
> On Mon, May 6, 2019 at 1:36 AM Dawid Weiss  wrote:
> > Switching to gradle means deleting tons of crap - all sorts of work arounds 
> > and ant abuse go away.
> 
> True. But other things will creep in. Take a look at any larger gradle
> build -- there's lots of groovy-code magic in there...
> 
> To be clear: I do think the switch over to gradle is worth it (for the
> reasons you mentioned, if not anything else).
> 
> Dawid
> 
> On Mon, May 6, 2019 at 8:03 AM Mark Miller  wrote:
> >
> > I don't know that we need or want to do side by side, it's just doable. If 
> > we did do that, certainly the goal would be to keep it short. Whatever 
> > keeps people from pulling the rug out from under me if I work on this 
> > further.
> >
> > Any other bike-shedding to be done or major concerns?
> >
> > This really will be a lot of work - one of those the last 20% takes 80% of 
> > the time type things.
> >
> > Please, please, please, stop me now.
> >
> > - Mark
> >
> >
> > On Sun, May 5, 2019 at 11:39 PM David Smiley  
> > wrote:
> >>
> >> I agree that an easier-to-understand build is an important virtue we 
> >> should try to achieve here (for the reasons you mentioned).  Our build is 
> >> too complex and non-standard.  Any other benefits are icing on the cake.
> >>
> >> RE "side by side"; that could weigh us down maintaining more; I hope this 
> >> isn't long term.
> >>
> >> ~ David Smiley
> >> Apache Lucene/Solr Search Developer
> >> http://www.linkedin.com/in/davidwsmiley
> >>
> >>
> >> On Sun, May 5, 2019 at 6:23 PM Mark Miller  wrote:
> >>>
> >>> We can indeed make them work side by side.
> >>>
> >>> - Mark
> >>>
> >>> On Sun, May 5, 2019 at 11:36 AM Erick Erickson  
> >>> wrote:
> 
>  I don’t know enough about the differences to even think consider 
>  complaining.
> 
>  Is the proposal that we use Gradle for master and continue to use ant 
>  for 8x? As long as the two build systems can exist side by side (i.e. we 
>  can build master by executing some Gradle target and continue to build 
>  8x with Ant like we always have) the minor inconvenience doesn’t merit 
>  standing in the way of progress.
> 
>  If that’s the case I don’t particularly care if we continue to use Ant 
>  with 8x forever. Or maybe some ambitious person can work on bringing 8x 
>  to Gradle after it has some mileage on master.
> 
>  And I have great faith that you wouldn’t be putting in the work unless 
>  you thought it was worth it ;)
> 
>  Erick
> 
>  > On May 4, 2019, at 10:31 PM, Mark Miller  wrote:
>  >
>  > We already dump out to groovy to do anything interesting, so I doubt 
>  > there is much we can't replicate.
>  >
>  > - Mark
>  >
>  > On Sat, May 4, 2019 at 9:09 PM Ishan Chattopadhyaya 
>  >  wrote:
>  > Would beasting of tests be possible through gradle?
>  >
>  > On Sun, May 5, 2019 at 7:33 AM Mark Miller  
>  > wrote:
>  > >
>  > > I looked into this a little more.
>  > >
>  > > Seems if we just do it with master and going forward, we don’t need 
>  > > multi version support - Uwe seems to have taken it out with the move 
>  > > to Java 11?
>  > >
>  > > I can handle regenerate.
>  > >
>  > > The other quality checks shouldn’t be crazy.
>  > >
>  > > So I guess we can probably do this, but before I focus on BS 
>  > > details, please speak up if you hate the idea of Gradle and you 

[jira] [Commented] (SOLR-13318) JsonFacetingResponse classes should record provide access to count fields as longs

[Munendra S N (JIRA)]

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

Munendra S N commented on SOLR-13318:
-

Makes sense. Also, is there a plan to backport this to 7.7x as there is plan to 
release 7.7.2??


> JsonFacetingResponse classes should record  provide access to count fields as 
> longs
> ---
>
> Key: SOLR-13318
> URL: https://issues.apache.org/jira/browse/SOLR-13318
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrJ
>Affects Versions: 7.7.1
>Reporter: Jason Gerlowski
>Assignee: Jason Gerlowski
>Priority: Minor
> Attachments: SOLR-13318-branch_8x.patch, SOLR-13318.patch, 
> SOLR-13318.patch
>
>
> JsonFacetingResponse and its series of dependent classes hold a variety of 
> count fields for bucket counts and various optional properties 
> ({{allBuckets}}, {{numBuckets}}, etc.).  Currently, some of the code that 
> parses these values out of the originating NamedList either stores or casts 
> the values as ints.  When doc counts are low this works fine.  But when the 
> doc counts become larger and stray into "long" territory, SolrJ is liable to 
> blow up with ClassCastExceptions.
> A user on the list reported on of these with the partial stack trace:
> {code}
> Caused by: java.lang.ClassCastException: java.lang.Long cannot be cast to 
> java.lang.Integer
>   at 
> org.apache.solr.client.solrj.response.json.NestableJsonFacet.(NestableJsonFacet.java:52)
>   at 
> org.apache.solr.client.solrj.response.QueryResponse.extractJsonFacetingInfo(QueryResponse.java:200)
>   at 
> org.apache.solr.client.solrj.response.QueryResponse.getJsonFacetingResponse(QueryResponse.java:571)
> {code}
> We should fix this so that these classes can be used without incident for any 
> doc counts.



--
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-7840) BooleanQuery.rewriteNoScoring - optimize away any SHOULD clauses if at least 1 MUST/FILTER clause and 0==minShouldMatch

[Atri Sharma (JIRA)]

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

Atri Sharma commented on LUCENE-7840:
-

+1, will raise a patch

> BooleanQuery.rewriteNoScoring - optimize away any SHOULD clauses if at least 
> 1 MUST/FILTER clause and 0==minShouldMatch
> ---
>
> Key: LUCENE-7840
> URL: https://issues.apache.org/jira/browse/LUCENE-7840
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Hoss Man
>Priority: Major
>
> I haven't thought this through completely, let alone write up a patch / test 
> case, but IIUC...
> We should be able to optimize  {{ BooleanQuery rewriteNoScoring() }} so that 
> (after converting MUST clauses to FILTER clauses) we can check for the common 
> case of {{0==getMinimumNumberShouldMatch()}} and throw away any SHOULD 
> clauses as long as there is is at least one FILTER clause.



--
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-8.x-Linux (64bit/jdk1.8.0_201) - Build # 522 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-8.x-Linux/522/
Java: 64bit/jdk1.8.0_201 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC

2 tests failed.
FAILED:  org.apache.solr.cloud.AliasIntegrationTest.testClusterStateProviderAPI

Error Message:
{} expected:<2> but was:<0>

Stack Trace:
java.lang.AssertionError: {} expected:<2> but was:<0>
at 
__randomizedtesting.SeedInfo.seed([CEB36C71F521A1D6:D164F05D862A589D]: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.AliasIntegrationTest.testClusterStateProviderAPI(AliasIntegrationTest.java:291)
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.cloud.HttpPartitionWithTlogReplicasTest.test

Error Message:
Error from server at http://127.0.0.1:36981/ko/dt: Underlying core creation 
failed while creating collection: c8n_1x2

Re: Call for help: moving from ant build to gradle

[Shawn Heisey]

On 5/6/2019 7:37 AM, Erick Erickson wrote:

I want to be clear about my question of whether we’d use Gradle for master and 
continue to use Ant for 8x.

It is _totally_ and _completely_ a matter of what would be easiest and up to 
the people who are doing the heavy lifting. If moving both to Gradle would be 
easiest, that has my vote. If a split process would be easier, then that has my 
vote.

And, frankly, if nobody has speaks up they don’t get a vote AFAIC.


When I try to understand the build system, I get lost.  That might 
continue to happen even with a switch to gradle, of course.  Just having 
somebody work on the build system is likely to clean it up and make it 
easier to understand ... whether we migrate or not.


I do like your idea of doing the work in master, letting it bake for a 
while to work out the kinks, and if it turns out really nice, 
backporting it to the stable branch.


Thanks,
Shawn

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

Re: Call for help: moving from ant build to gradle

[Erik Hatcher]

As the ol' "Ant guy" curmudgeon, with no active clout, .  I'm all for this 
modernization effort +1Kudos to Mark, and others, for prodding ahead on 
this long discussed and overdue overhaul.

Erik


> On May 6, 2019, at 3:12 AM, Mark Miller  wrote:
> 
> Yes, but hopefully just practically useful stuff :)
> 
> I think a lot of the cruft and pain now is that we banged and smashed and 
> pried ant+ivy to act like a modern build system at the expense of performance 
> issues and a lack of simple features and sophisticated hacks to get around 
> some of the performance issues, and ...
> 
> We also like to pretend we have such great control over our dependencies, but 
> we are one of the worst behaved libraries in terms of managing our 
> dependencies in maven central and unnecessary stuff we ship and wrong stuff 
> we ship for various modules.
> 
> A lot of that is just because it's hard to do otherwise with our system.
> 
> With groovy its much easier to clean that up and also verify it stays that 
> way. There are enough hoops to accomplishing that in our current system that 
> no one deals with it.
> 
> It won't all be amazing, but it will be better for sure and we will certainly 
> have more developer help than in the past.
> 
> - Mark
> 
> On Mon, May 6, 2019 at 1:36 AM Dawid Weiss  > wrote:
> > Switching to gradle means deleting tons of crap - all sorts of work arounds 
> > and ant abuse go away.
> 
> True. But other things will creep in. Take a look at any larger gradle
> build -- there's lots of groovy-code magic in there...
> 
> To be clear: I do think the switch over to gradle is worth it (for the
> reasons you mentioned, if not anything else).
> 
> Dawid
> 
> On Mon, May 6, 2019 at 8:03 AM Mark Miller  > wrote:
> >
> > I don't know that we need or want to do side by side, it's just doable. If 
> > we did do that, certainly the goal would be to keep it short. Whatever 
> > keeps people from pulling the rug out from under me if I work on this 
> > further.
> >
> > Any other bike-shedding to be done or major concerns?
> >
> > This really will be a lot of work - one of those the last 20% takes 80% of 
> > the time type things.
> >
> > Please, please, please, stop me now.
> >
> > - Mark
> >
> >
> > On Sun, May 5, 2019 at 11:39 PM David Smiley  > > wrote:
> >>
> >> I agree that an easier-to-understand build is an important virtue we 
> >> should try to achieve here (for the reasons you mentioned).  Our build is 
> >> too complex and non-standard.  Any other benefits are icing on the cake.
> >>
> >> RE "side by side"; that could weigh us down maintaining more; I hope this 
> >> isn't long term.
> >>
> >> ~ David Smiley
> >> Apache Lucene/Solr Search Developer
> >> http://www.linkedin.com/in/davidwsmiley 
> >> 
> >>
> >>
> >> On Sun, May 5, 2019 at 6:23 PM Mark Miller  >> > wrote:
> >>>
> >>> We can indeed make them work side by side.
> >>>
> >>> - Mark
> >>>
> >>> On Sun, May 5, 2019 at 11:36 AM Erick Erickson  >>> > wrote:
> 
>  I don’t know enough about the differences to even think consider 
>  complaining.
> 
>  Is the proposal that we use Gradle for master and continue to use ant 
>  for 8x? As long as the two build systems can exist side by side (i.e. we 
>  can build master by executing some Gradle target and continue to build 
>  8x with Ant like we always have) the minor inconvenience doesn’t merit 
>  standing in the way of progress.
> 
>  If that’s the case I don’t particularly care if we continue to use Ant 
>  with 8x forever. Or maybe some ambitious person can work on bringing 8x 
>  to Gradle after it has some mileage on master.
> 
>  And I have great faith that you wouldn’t be putting in the work unless 
>  you thought it was worth it ;)
> 
>  Erick
> 
>  > On May 4, 2019, at 10:31 PM, Mark Miller   > > wrote:
>  >
>  > We already dump out to groovy to do anything interesting, so I doubt 
>  > there is much we can't replicate.
>  >
>  > - Mark
>  >
>  > On Sat, May 4, 2019 at 9:09 PM Ishan Chattopadhyaya 
>  > mailto:ichattopadhy...@gmail.com>> wrote:
>  > Would beasting of tests be possible through gradle?
>  >
>  > On Sun, May 5, 2019 at 7:33 AM Mark Miller   > > wrote:
>  > >
>  > > I looked into this a little more.
>  > >
>  > > Seems if we just do it with master and going forward, we don’t need 
>  > > multi version support - Uwe seems to have taken it out with the move 
>  > > to Java 11?
>  > >
>  > > I can handle regenerate.
>  > >
>  > > The other quality checks shouldn’t be crazy.
>  > >
>  > > So I guess we can probably do this, but 

[JENKINS-EA] Lucene-Solr-master-Linux (64bit/jdk-13-ea+18) - Build # 24043 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/24043/
Java: 64bit/jdk-13-ea+18 -XX:-UseCompressedOops -XX:+UseG1GC

8 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.update.processor.DistributedUpdateProcessorTest

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([8E0C1A8EA85BF92B]:0)
at 
com.carrotsearch.randomizedtesting.RandomizedTest.assumeNoException(RandomizedTest.java:742)
at 
org.apache.solr.SolrTestCaseJ4.assumeWorkingMockito(SolrTestCaseJ4.java:374)
at 
org.apache.solr.update.processor.DistributedUpdateProcessorTest.beforeClass(DistributedUpdateProcessorTest.java:60)
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:372)
... 24 more


FAILED:  
junit.framework.TestSuite.org.apache.solr.update.processor.DistributedUpdateProcessorTest

Error Message:


Stack Trace:
java.lang.NullPointerException
at __randomizedtesting.SeedInfo.seed([8E0C1A8EA85BF92B]:0)
at 
org.apache.solr.update.processor.DistributedUpdateProcessorTest.AfterClass(DistributedUpdateProcessorTest.java:68)
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 

[jira] [Commented] (LUCENE-8791) Add CollectorRescorer

[Elbek Kamoliddinov (JIRA)]

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

Elbek Kamoliddinov commented on LUCENE-8791:


{{testMultiSegment}} is creating multiple segments, also {{testRandom}} does 
commit with conditioned on {{rarely()}} to have multisegment index. So both of 
these tests should be sufficient? 

Thanks again looking into it. 

 

> Add CollectorRescorer
> -
>
> Key: LUCENE-8791
> URL: https://issues.apache.org/jira/browse/LUCENE-8791
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Elbek Kamoliddinov
>Priority: Major
> Attachments: LUCENE-8791.patch, LUCENE-8791.patch
>
>
> This is another implementation of query rescorer api (LUCENE-5489). It adds 
> rescoring functionality based on provided CollectorManager. 
>  



--
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-8793) Enhanced UI for CustomAnalyzer : show analysis steps

[Jun Ohtani (JIRA)]

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

Jun Ohtani commented on LUCENE-8793:


I've changed the patch for fixing 1, 3, and 4.

And added charfilter's result.

Also changed the layout of results.

See detail in LUCENE-8793-2.patch file.

 

!Screen Shot 2019-05-07 at 1.40.47.png|width=768,height=544!

> Enhanced UI for CustomAnalyzer : show analysis steps
> 
>
> Key: LUCENE-8793
> URL: https://issues.apache.org/jira/browse/LUCENE-8793
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/luke
>Reporter: Jun Ohtani
>Priority: Minor
> Attachments: LUCENE-8793-2.patch, LUCENE-8793.patch, Screen Shot 
> 2019-05-06 at 10.00.57.png, Screen Shot 2019-05-07 at 1.40.47.png, Screenshot 
> from 2019-05-06 13-45-40.png, Screenshot from 2019-05-06 13-46-16.png
>
>
> This is a migrated issue from previous Luke project in GitHub: 
> [https://github.com/DmitryKey/luke/issues/134]
>  
> For on-the-fly inspection / debugging, it is desirable to show the more 
> detailed step by step information in the Custom Analyzer UI.
> This will be just like Solr's Analysis screen,
> [https://lucene.apache.org/solr/guide/7_5/analysis-screen.html]
> or Elasticsearch's {{_analyze}} API and Kibana's Analyzer UI.
> [https://www.elastic.co/guide/en/elasticsearch/reference/current/indices-analyze.html]
> [https://github.com/johtani/analyze-api-ui-plugin]



--
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-8793) Enhanced UI for CustomAnalyzer : show analysis steps

[Jun Ohtani (JIRA)]

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

Jun Ohtani updated LUCENE-8793:
---
Attachment: LUCENE-8793-2.patch

> Enhanced UI for CustomAnalyzer : show analysis steps
> 
>
> Key: LUCENE-8793
> URL: https://issues.apache.org/jira/browse/LUCENE-8793
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/luke
>Reporter: Jun Ohtani
>Priority: Minor
> Attachments: LUCENE-8793-2.patch, LUCENE-8793.patch, Screen Shot 
> 2019-05-06 at 10.00.57.png, Screen Shot 2019-05-07 at 1.40.47.png, Screenshot 
> from 2019-05-06 13-45-40.png, Screenshot from 2019-05-06 13-46-16.png
>
>
> This is a migrated issue from previous Luke project in GitHub: 
> [https://github.com/DmitryKey/luke/issues/134]
>  
> For on-the-fly inspection / debugging, it is desirable to show the more 
> detailed step by step information in the Custom Analyzer UI.
> This will be just like Solr's Analysis screen,
> [https://lucene.apache.org/solr/guide/7_5/analysis-screen.html]
> or Elasticsearch's {{_analyze}} API and Kibana's Analyzer UI.
> [https://www.elastic.co/guide/en/elasticsearch/reference/current/indices-analyze.html]
> [https://github.com/johtani/analyze-api-ui-plugin]



--
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-8793) Enhanced UI for CustomAnalyzer : show analysis steps

[Jun Ohtani (JIRA)]

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

Jun Ohtani updated LUCENE-8793:
---
Attachment: Screen Shot 2019-05-07 at 1.40.47.png

> Enhanced UI for CustomAnalyzer : show analysis steps
> 
>
> Key: LUCENE-8793
> URL: https://issues.apache.org/jira/browse/LUCENE-8793
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/luke
>Reporter: Jun Ohtani
>Priority: Minor
> Attachments: LUCENE-8793.patch, Screen Shot 2019-05-06 at 
> 10.00.57.png, Screen Shot 2019-05-07 at 1.40.47.png, Screenshot from 
> 2019-05-06 13-45-40.png, Screenshot from 2019-05-06 13-46-16.png
>
>
> This is a migrated issue from previous Luke project in GitHub: 
> [https://github.com/DmitryKey/luke/issues/134]
>  
> For on-the-fly inspection / debugging, it is desirable to show the more 
> detailed step by step information in the Custom Analyzer UI.
> This will be just like Solr's Analysis screen,
> [https://lucene.apache.org/solr/guide/7_5/analysis-screen.html]
> or Elasticsearch's {{_analyze}} API and Kibana's Analyzer UI.
> [https://www.elastic.co/guide/en/elasticsearch/reference/current/indices-analyze.html]
> [https://github.com/johtani/analyze-api-ui-plugin]



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

precommit failures

[Erick Erickson]

Both Kevin Risden and I are seeing: 

[ecj-lint] 1. ERROR in 
/Users/Erick/apache/solrVersions/playspace/solr/contrib/dataimporthandler/src/java/org/apache/solr/handler/dataimport/JdbcDataSource.java
 (at line 28)
 [ecj-lint] import javax.naming.InitialContext;
 [ecj-lint]^^^
 [ecj-lint] The type javax.naming.InitialContext is not accessible```

This import hasn’t been changed since 2009.

I'm using: openjdk version “11.0.2” 2019-01-15

I tried a fresh clone of master and cleaned the ivy cache, still the same 
problem. But we can't be the only ones seeing this, any clues?
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: precommit failures

[Dawid Weiss]

I had it this morning before committing the fst patch from Mike.
Cleaned the repo, re-ran precommit and it passed... Very strange.

D.

On Mon, May 6, 2019 at 5:53 PM Erick Erickson  wrote:
>
>
> Both Kevin Risden and I are seeing:
>
> [ecj-lint] 1. ERROR in 
> /Users/Erick/apache/solrVersions/playspace/solr/contrib/dataimporthandler/src/java/org/apache/solr/handler/dataimport/JdbcDataSource.java
>  (at line 28)
>  [ecj-lint] import javax.naming.InitialContext;
>  [ecj-lint]^^^
>  [ecj-lint] The type javax.naming.InitialContext is not accessible```
>
> This import hasn’t been changed since 2009.
>
> I'm using: openjdk version “11.0.2” 2019-01-15
>
> I tried a fresh clone of master and cleaned the ivy cache, still the same 
> problem. But we can't be the only ones seeing this, any clues?
> -
> 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-8.x - Build # 92 - Still unstable

[Apache Jenkins Server]

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

1 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.handler.TestReplicationHandler

Error Message:
ObjectTracker found 5 object(s) that were not released!!! 
[MockDirectoryWrapper, SolrCore, RawDirectoryWrapper, MockDirectoryWrapper, 
InternalHttpClient] 
org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: 
org.apache.lucene.store.MockDirectoryWrapper  at 
org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42)
  at 
org.apache.solr.core.CachingDirectoryFactory.get(CachingDirectoryFactory.java:348)
  at 
org.apache.solr.handler.IndexFetcher.fetchLatestIndex(IndexFetcher.java:509)  
at org.apache.solr.handler.IndexFetcher.fetchLatestIndex(IndexFetcher.java:351) 
 at 
org.apache.solr.handler.ReplicationHandler.doFetch(ReplicationHandler.java:424) 
 at 
org.apache.solr.handler.ReplicationHandler.lambda$setupPolling$13(ReplicationHandler.java:1193)
  at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)  
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)  at 
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
  at 
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
  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:1063)  at 
org.apache.solr.core.SolrCore.reload(SolrCore.java:675)  at 
org.apache.solr.core.CoreContainer.reload(CoreContainer.java:1499)  at 
org.apache.solr.handler.IndexFetcher.lambda$reloadCore$0(IndexFetcher.java:934) 
 at java.lang.Thread.run(Thread.java:748)  
org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: 
org.apache.lucene.store.RawDirectoryWrapper  at 
org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42)
  at 
org.apache.solr.core.CachingDirectoryFactory.get(CachingDirectoryFactory.java:348)
  at org.apache.solr.core.SolrCore.getNewIndexDir(SolrCore.java:368)  at 
org.apache.solr.core.SolrCore.initIndex(SolrCore.java:747)  at 
org.apache.solr.core.SolrCore.(SolrCore.java:976)  at 
org.apache.solr.core.SolrCore.(SolrCore.java:883)  at 
org.apache.solr.core.CoreContainer.createFromDescriptor(CoreContainer.java:1238)
  at org.apache.solr.core.CoreContainer.lambda$load$13(CoreContainer.java:749)  
at 
com.codahale.metrics.InstrumentedExecutorService$InstrumentedCallable.call(InstrumentedExecutorService.java:202)
  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.lucene.store.MockDirectoryWrapper  at 
org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42)
  at 
org.apache.solr.core.CachingDirectoryFactory.get(CachingDirectoryFactory.java:348)
  at 
org.apache.solr.handler.IndexFetcher.fetchLatestIndex(IndexFetcher.java:509)  
at org.apache.solr.handler.IndexFetcher.fetchLatestIndex(IndexFetcher.java:351) 
 at 
org.apache.solr.handler.ReplicationHandler.doFetch(ReplicationHandler.java:424) 
 at 
org.apache.solr.handler.ReplicationHandler.lambda$setupPolling$13(ReplicationHandler.java:1193)
  at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)  
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)  at 
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
  at 
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
  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.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 

BadApples

[Erick Erickson]

Not too much change from two weeks ago. No tests are to be un-annotated. Full 
list attached:DO NOT ENABLE LIST:
MoveReplicaHDFSTest.testFailedMove
MoveReplicaHDFSTest.testNormalFailedMove
TestControlledRealTimeReopenThread.testCRTReopen
TestICUNormalizer2CharFilter.testRandomStrings
TestICUTokenizerCJK
TestImpersonationWithHadoopAuth.testForwarding
TestLTRReRankingPipeline.testDifferentTopN
TestRandomChains


DO NOT ANNOTATE LIST
CdcrBidirectionalTest.testBiDir
IndexSizeTriggerTest.testMergeIntegration
IndexSizeTriggerTest.testMixedBounds
IndexSizeTriggerTest.testSplitIntegration
IndexSizeTriggerTest.testTrigger
InfixSuggestersTest.testShutdownDuringBuild
ShardSplitTest.test
ShardSplitTest.testSplitMixedReplicaTypes
ShardSplitTest.testSplitWithChaosMonkey
TestLatLonShapeQueries.testRandomBig
TestRandomChains.testRandomChainsWithLargeStrings
TestTriggerIntegration.testSearchRate

Processing file (History bit 3): HOSS-2019-05-06.csv
Processing file (History bit 2): HOSS-2019-04-22.csv
Processing file (History bit 1): HOSS-2019-04-15.csv
Processing file (History bit 0): HOSS-2019-04-08.csv


**Annotated tests that didn't fail in the last 4 weeks.

  **Tests removed from the next two lists because they were specified in 
'doNotEnable' in the properties file
 MoveReplicaHDFSTest.testNormalFailedMove

  **Annotations will be removed from the following tests because they haven't 
failed in the last 4 rollups.

  **Methods: 0


Failures in Hoss' reports for the last 4 rollups.

There were 238 unannotated tests that failed in Hoss' rollups. Ordered by the 
date I downloaded the rollup file, newest->oldest. See above for the dates the 
files were collected 
These tests were NOT BadApple'd or AwaitsFix'd
All tests that failed 4 weeks running will be BadApple'd unless there are 
objections

Failures in the last 4 reports..
   Report   Pct runsfails   test
 0123   0.4 1277  5  AuditLoggerIntegrationTest.testAsync
 0123   1.8 1245119  
AuditLoggerIntegrationTest.testAsyncQueueDrain
 0123   0.5 1262 41  
CategoryRoutedAliasUpdateProcessorTest.testSliceRouting
 0123  25.8  129 36  
HdfsAutoAddReplicasIntegrationTest.testSimple
 0123   4.5   87  7  HdfsBasicDistributedZkTest.test
 0123   4.8   91  5  HdfsChaosMonkeyNothingIsSafeTest.test
 0123   0.9 1253 16  HttpPartitionTest.test
 0123   0.5 1245 12  HttpPartitionWithTlogReplicasTest.test
 0123   0.5 1252  6  LeaderVoteWaitTimeoutTest.basicTest
 0123   1.2 1290 10  ReindexCollectionTest.testFailure
 0123   0.4 1266  4  ShardSplitTest.testSplitShardWithRuleLink
 0123  13.9  123 11  ShardSplitTest.testSplitWithChaosMonkey
 0123   1.7 1296 22  SolrRrdBackendFactoryTest.testBasic
 0123   1.8 1255 15  SystemCollectionCompatTest.testBackCompat
 0123   0.5 1234  7  TestCloudRecovery2.test
 0123   8.0  104 10  
TestDocTermOrdsUninvertLimit.testTriggerUnInvertLimit
 0123  21.8 1257 61  TestInPlaceUpdatesDistrib.test
 0123   0.5 1231  4  TestPackedInts.testPackedLongValues
 0123   0.5 1235 13  
TestReplicationHandlerDiskOverFlow.testDiskOverFlow
 Will BadApple all tests above this line except ones listed at the 
top**



 0123.0  837 14  NestedShardedAtomicUpdateTest.test
 0120.4  919  5  ReindexCollectionTest.testReshapeReindexing
 012   20.8   70 12  TestIndexWriterOnVMError.testCheckpoint
 01 3   0.5  982  7  LeaderFailoverAfterPartitionTest.test
 01 3   0.5  954  3  
LegacyCloudClusterPropTest.testCreateCollectionSwitchLegacyCloud
 01 3   0.5  970  9  MathExpressionTest.testGammaDistribution
 01 3   0.5  960  3  ShardRoutingTest.test
 01 2.6  455 13  
AliasIntegrationTest.testClusterStateProviderAPI
 01 0.5  615  2  
CollectionsAPISolrJTest.testCreateCollWithDefaultClusterPropertiesNewFormat
 01 0.5  610  2  DistributedQueueTest.testPeekElements
 01 0.5  574  3  OverseerTest.testOverseerFailure
 01 0.5  610  4  PeerSyncReplicationTest.test
 0135.3  681105  PeerSyncWithLeaderTest.test
 0 23   0.5  865  3  
CategoryRoutedAliasUpdateProcessorTest.testMustMatch
 0 23   0.8  884  4  ReindexCollectionTest.testBasicReindexing
 0 23   0.9  829  4  
StreamDecoratorTest.testParallelCommitStream
 0 23   0.5  834  3  
TestRandomChains.testRandomChainsWithLargeStrings
 0 23   0.5  836  5  TestSolrConfigHandlerCloud.test
 0 20.5  471

[JENKINS] Lucene-Solr-8.1-Linux (32bit/jdk1.8.0_201) - Build # 292 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-8.1-Linux/292/
Java: 32bit/jdk1.8.0_201 -client -XX:+UseG1GC

1 tests failed.
FAILED:  org.apache.solr.cloud.OverseerRolesTest.testDesignatedOverseerRestarts

Error Message:
Timed out waiting for overseer state change. The current overseer is: 
127.0.0.1:43791_solr

Stack Trace:
java.lang.AssertionError: Timed out waiting for overseer state change. The 
current overseer is: 127.0.0.1:43791_solr
at 
__randomizedtesting.SeedInfo.seed([9E52BF62113126CC:9673A83D2F6F34C6]:0)
at org.junit.Assert.fail(Assert.java:88)
at 
org.apache.solr.cloud.OverseerRolesTest.waitForNewOverseer(OverseerRolesTest.java:70)
at 
org.apache.solr.cloud.OverseerRolesTest.waitForNewOverseer(OverseerRolesTest.java:75)
at 
org.apache.solr.cloud.OverseerRolesTest.testDesignatedOverseerRestarts(OverseerRolesTest.java:189)
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