[GitHub] [lucene-solr] thomaswoeckinger commented on issue #755: SOLR-13592: Introduce EmbeddedSolrTestBase for better integration tests

[GitBox]

thomaswoeckinger commented on issue #755: SOLR-13592: Introduce 
EmbeddedSolrTestBase for better integration tests
URL: https://github.com/apache/lucene-solr/pull/755#issuecomment-521514103
 
 
   Did not had time to test yet, i am at vacation for the next to week, than i 
can continue to work on it.


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

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

[Apache Jenkins Server]

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

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

Error Message:
Timeout occurred while waiting response from server at: http://127.0.0.1:41398

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: Timeout occurred while 
waiting response from server at: http://127.0.0.1:41398
at 
__randomizedtesting.SeedInfo.seed([9397BBABF411188F:1BC384715AED7577]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:667)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:262)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:245)
at 
org.apache.solr.client.solrj.impl.LBSolrClient.doRequest(LBSolrClient.java:368)
at 
org.apache.solr.client.solrj.impl.LBSolrClient.request(LBSolrClient.java:296)
at 
org.apache.solr.client.solrj.impl.BaseCloudSolrClient.sendRequest(BaseCloudSolrClient.java:1128)
at 
org.apache.solr.client.solrj.impl.BaseCloudSolrClient.requestWithRetryOnStaleState(BaseCloudSolrClient.java:897)
at 
org.apache.solr.client.solrj.impl.BaseCloudSolrClient.request(BaseCloudSolrClient.java:829)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:211)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:228)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.createServers(AbstractFullDistribZkTestBase.java:338)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:1080)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:1054)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:947)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 

[jira] [Resolved] (SOLR-13695) SPLITSHARD (link), followed by DELETESHARD of parent shard causes data loss

[Ishan Chattopadhyaya (JIRA)]

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

Ishan Chattopadhyaya resolved SOLR-13695.
-
Resolution: Invalid

> SPLITSHARD (link), followed by DELETESHARD of parent shard causes data loss
> ---
>
> Key: SOLR-13695
> URL: https://issues.apache.org/jira/browse/SOLR-13695
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Ishan Chattopadhyaya
>Assignee: Ishan Chattopadhyaya
>Priority: Critical
>
> One of my clients experienced data loss with the following sequence of 
> operations:
> 1) SPLITSHARD with method as "link".
> 2) DELETESHARD of the parent (inactive) shard.
> 3) Query for documents in the subshards, seems like both subshards have 0 
> documents.
> Proposing a fix (after offline discussion with [~noble.paul]) based on 
> running FORCEMERGE after SPLITSHARD (such that segments are rewritten), and 
> not letting DELETESHARD delete the data directory until the FORCEMERGE 
> operations finish.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Commented] (SOLR-13695) SPLITSHARD (link), followed by DELETESHARD of parent shard causes data loss

[Ishan Chattopadhyaya (JIRA)]

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

Ishan Chattopadhyaya commented on SOLR-13695:
-

Seems like there are other factors at play here which caused data loss. 
SPLITSHARD was actually issued with method=rewrite, but failed immediately (the 
speed with which the SPLITSHARD completed fooled me to believe it is 
method=link). However, the status of SPLITSHARD was 0 (success?), and after a 
subsequent DELETESHARD, there were no documents.  So, actually, the SPLITSHARD 
itself caused the data loss, not the DELETESHARD.

I'll close this issue and re-open another one for this problem.

> SPLITSHARD (link), followed by DELETESHARD of parent shard causes data loss
> ---
>
> Key: SOLR-13695
> URL: https://issues.apache.org/jira/browse/SOLR-13695
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Ishan Chattopadhyaya
>Assignee: Ishan Chattopadhyaya
>Priority: Critical
>
> One of my clients experienced data loss with the following sequence of 
> operations:
> 1) SPLITSHARD with method as "link".
> 2) DELETESHARD of the parent (inactive) shard.
> 3) Query for documents in the subshards, seems like both subshards have 0 
> documents.
> Proposing a fix (after offline discussion with [~noble.paul]) based on 
> running FORCEMERGE after SPLITSHARD (such that segments are rewritten), and 
> not letting DELETESHARD delete the data directory until the FORCEMERGE 
> operations finish.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Commented] (SOLR-13683) SolrJ 8.1.1 Http2SolrClient should allow customizing HTTP headers

[Cao Manh Dat (JIRA)]

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

Cao Manh Dat commented on SOLR-13683:
-

This one
{code}
Http2SolrClient.Builder().withHttpClient(Http2SolrClient httpClient)
{code} 
is used for sharing connections pool between multiple {{Http2SolrClient}}s.

The idea here to hiding the underlying {{HttpClient}} (what if we want to 
switch to different client in the future?). More over it help us preventing 
access to {{HttpClient}}. Even in Solr code base right now. Manually modifying 
HttpClient to change {{connectionTimeout}} and {{socketTimeout}} without going 
through provided methods by Http[2]SolrClient is common. This is not good and 
sometime quite confusing for knowing exact params are used by underlying 
HttpClient.

{quote}
Http2SolrClient does not allow configuring custom headers
{quote}
It does, if you want to set basic auth for a specific request uses 
{{SolrRequest#setBasicAuthCredentials}}.

If you want to set basic auth for all requests sent by {{Http2SolrClient}} uses
{{PreemptiveBasicAuthClientBuilderFactory#setup()}}.

If {{PreemptiveBasicAuthClientBuilderFactory}} behaviour is not suitable for 
you, you can always add your own custom headers by using 
{{Http2SolrClient#addListenerFactory()}}. 

> SolrJ 8.1.1 Http2SolrClient should allow customizing HTTP headers
> -
>
> Key: SOLR-13683
> URL: https://issues.apache.org/jira/browse/SOLR-13683
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: clients - java
>Affects Versions: 8.1.1
>Reporter: Niranjan Nanda
>Priority: Minor
>
> Currently {{Http2SolrClient}} does not allow configuring custom headers. For 
> example, how to pass Basic Auth headers? It should expose some builder APIs 
> to pass such headers.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[JENKINS] Lucene-Solr-master-Linux (64bit/jdk-11.0.3) - Build # 24546 - Failure!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/24546/
Java: 64bit/jdk-11.0.3 -XX:-UseCompressedOops -XX:+UseG1GC

All tests passed

Build Log:
[...truncated 64681 lines...]
-ecj-javadoc-lint-tests:
[mkdir] Created dir: /tmp/ecj2059418404
 [ecj-lint] Compiling 48 source files to /tmp/ecj2059418404
 [ecj-lint] invalid Class-Path header in manifest of jar file: 
/home/jenkins/.ivy2/cache/org.restlet.jee/org.restlet/jars/org.restlet-2.3.0.jar
 [ecj-lint] invalid Class-Path header in manifest of jar file: 
/home/jenkins/.ivy2/cache/org.restlet.jee/org.restlet.ext.servlet/jars/org.restlet.ext.servlet-2.3.0.jar
 [ecj-lint] --
 [ecj-lint] 1. ERROR in 
/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/contrib/dataimporthandler/src/test/org/apache/solr/handler/dataimport/MockInitialContextFactory.java
 (at line 23)
 [ecj-lint] import javax.naming.NamingException;
 [ecj-lint]
 [ecj-lint] The type javax.naming.NamingException is not accessible
 [ecj-lint] --
 [ecj-lint] 2. ERROR in 
/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/contrib/dataimporthandler/src/test/org/apache/solr/handler/dataimport/MockInitialContextFactory.java
 (at line 28)
 [ecj-lint] public class MockInitialContextFactory implements 
InitialContextFactory {
 [ecj-lint]  ^
 [ecj-lint] The type MockInitialContextFactory must implement the inherited 
abstract method InitialContextFactory.getInitialContext(Hashtable)
 [ecj-lint] --
 [ecj-lint] 3. ERROR in 
/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/contrib/dataimporthandler/src/test/org/apache/solr/handler/dataimport/MockInitialContextFactory.java
 (at line 30)
 [ecj-lint] private final javax.naming.Context context;
 [ecj-lint]   
 [ecj-lint] The type javax.naming.Context is not accessible
 [ecj-lint] --
 [ecj-lint] 4. ERROR in 
/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/contrib/dataimporthandler/src/test/org/apache/solr/handler/dataimport/MockInitialContextFactory.java
 (at line 33)
 [ecj-lint] context = mock(javax.naming.Context.class);
 [ecj-lint] ^^^
 [ecj-lint] context cannot be resolved to a variable
 [ecj-lint] --
 [ecj-lint] 5. ERROR in 
/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/contrib/dataimporthandler/src/test/org/apache/solr/handler/dataimport/MockInitialContextFactory.java
 (at line 33)
 [ecj-lint] context = mock(javax.naming.Context.class);
 [ecj-lint]
 [ecj-lint] The type javax.naming.Context is not accessible
 [ecj-lint] --
 [ecj-lint] 6. ERROR in 
/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/contrib/dataimporthandler/src/test/org/apache/solr/handler/dataimport/MockInitialContextFactory.java
 (at line 36)
 [ecj-lint] when(context.lookup(anyString())).thenAnswer(invocation -> 
objects.get(invocation.getArgument(0)));
 [ecj-lint]  ^^^
 [ecj-lint] context cannot be resolved
 [ecj-lint] --
 [ecj-lint] 7. ERROR in 
/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/contrib/dataimporthandler/src/test/org/apache/solr/handler/dataimport/MockInitialContextFactory.java
 (at line 38)
 [ecj-lint] } catch (NamingException e) {
 [ecj-lint]  ^^^
 [ecj-lint] NamingException cannot be resolved to a type
 [ecj-lint] --
 [ecj-lint] 8. ERROR in 
/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/contrib/dataimporthandler/src/test/org/apache/solr/handler/dataimport/MockInitialContextFactory.java
 (at line 45)
 [ecj-lint] public javax.naming.Context getInitialContext(Hashtable env) {
 [ecj-lint]
 [ecj-lint] The type javax.naming.Context is not accessible
 [ecj-lint] --
 [ecj-lint] 9. ERROR in 
/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/contrib/dataimporthandler/src/test/org/apache/solr/handler/dataimport/MockInitialContextFactory.java
 (at line 46)
 [ecj-lint] return context;
 [ecj-lint]^^^
 [ecj-lint] context cannot be resolved to a variable
 [ecj-lint] --
 [ecj-lint] 9 problems (9 errors)

BUILD FAILED
/home/jenkins/workspace/Lucene-Solr-master-Linux/build.xml:634: The following 
error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-master-Linux/build.xml:101: The following 
error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/build.xml:651: The 
following error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/common-build.xml:479: The 
following error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/common-build.xml:2015: 
The following error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/common-build.xml:2048: 
Compile failed; see the compiler error output for 

[jira] [Commented] (SOLR-13683) SolrJ 8.1.1 Http2SolrClient should allow customizing HTTP headers

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar commented on SOLR-13683:
--

bq. Our use case is indexing documents to Solr; hence, we do not use 
SolrRequest APIs. We use SolrClient.add(collectionName, 
Collection) API. Do you have any document which shows how to 
use SolrRequest API for indexing use cases?

You can use UpdateRequest class which has an add method that accepts a 
Collection instead of calling add on CloudHttp2SolrClient 
directly.

> SolrJ 8.1.1 Http2SolrClient should allow customizing HTTP headers
> -
>
> Key: SOLR-13683
> URL: https://issues.apache.org/jira/browse/SOLR-13683
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: clients - java
>Affects Versions: 8.1.1
>Reporter: Niranjan Nanda
>Priority: Minor
>
> Currently {{Http2SolrClient}} does not allow configuring custom headers. For 
> example, how to pass Basic Auth headers? It should expose some builder APIs 
> to pass such headers.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

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

[Apache Jenkins Server]

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

1 tests failed.
FAILED:  
org.apache.solr.update.processor.DimensionalRoutedAliasUpdateProcessorTest.testCatTime

Error Message:
waiting for collections to be created Timeout waiting to see state for 
collection=testCatTime__CRA__shorthair__TRA__2019-07-03 :null Live Nodes: 
[127.0.0.1:32964_solr, 127.0.0.1:39329_solr, 127.0.0.1:40592_solr, 
127.0.0.1:43160_solr] Last available state: null

Stack Trace:
java.lang.AssertionError: waiting for collections to be created
Timeout waiting to see state for 
collection=testCatTime__CRA__shorthair__TRA__2019-07-03 :null
Live Nodes: [127.0.0.1:32964_solr, 127.0.0.1:39329_solr, 127.0.0.1:40592_solr, 
127.0.0.1:43160_solr]
Last available state: null
at 
__randomizedtesting.SeedInfo.seed([602FD3FA1199023F:67249CF92E6A53D7]: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.update.processor.RoutedAliasUpdateProcessorTest.waitCol(RoutedAliasUpdateProcessorTest.java:241)
at 
org.apache.solr.update.processor.RoutedAliasUpdateProcessorTest.waitColAndAlias(RoutedAliasUpdateProcessorTest.java:72)
at 
org.apache.solr.update.processor.DimensionalRoutedAliasUpdateProcessorTest.testCatTime(DimensionalRoutedAliasUpdateProcessorTest.java:480)
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 

[JENKINS] Lucene-Solr-master-MacOSX (64bit/jdk-11.0.3) - Build # 5291 - Failure!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-MacOSX/5291/
Java: 64bit/jdk-11.0.3 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC

All tests passed

Build Log:
[...truncated 2043 lines...]
   [junit4] JVM J1: stderr was not empty, see: 
/Users/jenkins/workspace/Lucene-Solr-master-MacOSX/lucene/build/core/test/temp/junit4-J1-20190814_234241_26717714051498880304505.syserr
   [junit4] >>> JVM J1 emitted unexpected output (verbatim) 
   [junit4] OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was 
deprecated in version 9.0 and will likely be removed in a future release.
   [junit4] <<< JVM J1: EOF 

[...truncated 5 lines...]
   [junit4] JVM J0: stderr was not empty, see: 
/Users/jenkins/workspace/Lucene-Solr-master-MacOSX/lucene/build/core/test/temp/junit4-J0-20190814_234241_26813913881354164299082.syserr
   [junit4] >>> JVM J0 emitted unexpected output (verbatim) 
   [junit4] OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was 
deprecated in version 9.0 and will likely be removed in a future release.
   [junit4] <<< JVM J0: EOF 

[...truncated 293 lines...]
   [junit4] JVM J1: stderr was not empty, see: 
/Users/jenkins/workspace/Lucene-Solr-master-MacOSX/lucene/build/test-framework/test/temp/junit4-J1-20190814_235154_84116538284303218578175.syserr
   [junit4] >>> JVM J1 emitted unexpected output (verbatim) 
   [junit4] OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was 
deprecated in version 9.0 and will likely be removed in a future release.
   [junit4] <<< JVM J1: EOF 

[...truncated 3 lines...]
   [junit4] JVM J0: stderr was not empty, see: 
/Users/jenkins/workspace/Lucene-Solr-master-MacOSX/lucene/build/test-framework/test/temp/junit4-J0-20190814_235154_8413310451378713355155.syserr
   [junit4] >>> JVM J0 emitted unexpected output (verbatim) 
   [junit4] OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was 
deprecated in version 9.0 and will likely be removed in a future release.
   [junit4] <<< JVM J0: EOF 

[...truncated 1091 lines...]
   [junit4] JVM J1: stderr was not empty, see: 
/Users/jenkins/workspace/Lucene-Solr-master-MacOSX/lucene/build/analysis/common/test/temp/junit4-J1-20190814_235308_6509028213152907527916.syserr
   [junit4] >>> JVM J1 emitted unexpected output (verbatim) 
   [junit4] OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was 
deprecated in version 9.0 and will likely be removed in a future release.
   [junit4] <<< JVM J1: EOF 

   [junit4] JVM J0: stderr was not empty, see: 
/Users/jenkins/workspace/Lucene-Solr-master-MacOSX/lucene/build/analysis/common/test/temp/junit4-J0-20190814_235308_65017519368845013713644.syserr
   [junit4] >>> JVM J0 emitted unexpected output (verbatim) 
   [junit4] OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was 
deprecated in version 9.0 and will likely be removed in a future release.
   [junit4] <<< JVM J0: EOF 

[...truncated 242 lines...]
   [junit4] JVM J1: stderr was not empty, see: 
/Users/jenkins/workspace/Lucene-Solr-master-MacOSX/lucene/build/analysis/icu/test/temp/junit4-J1-20190814_235536_9008401674540910489564.syserr
   [junit4] >>> JVM J1 emitted unexpected output (verbatim) 
   [junit4] OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was 
deprecated in version 9.0 and will likely be removed in a future release.
   [junit4] <<< JVM J1: EOF 

[...truncated 3 lines...]
   [junit4] JVM J0: stderr was not empty, see: 
/Users/jenkins/workspace/Lucene-Solr-master-MacOSX/lucene/build/analysis/icu/test/temp/junit4-J0-20190814_235536_89511488482860052062785.syserr
   [junit4] >>> JVM J0 emitted unexpected output (verbatim) 
   [junit4] OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was 
deprecated in version 9.0 and will likely be removed in a future release.
   [junit4] <<< JVM J0: EOF 

[...truncated 217 lines...]
   [junit4] JVM J0: stderr was not empty, see: 
/Users/jenkins/workspace/Lucene-Solr-master-MacOSX/lucene/build/analysis/kuromoji/test/temp/junit4-J0-20190814_235549_4887008672178837195676.syserr
   [junit4] >>> JVM J0 emitted unexpected output (verbatim) 
   [junit4] OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was 
deprecated in version 9.0 and will likely be removed in a future release.
   [junit4] <<< JVM J0: EOF 

[...truncated 3 lines...]
   [junit4] JVM J1: stderr was not empty, see: 
/Users/jenkins/workspace/Lucene-Solr-master-MacOSX/lucene/build/analysis/kuromoji/test/temp/junit4-J1-20190814_235549_48818032562201309606357.syserr
   [junit4] >>> JVM J1 emitted unexpected output (verbatim) 
   [junit4] OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was 
deprecated in version 9.0 and will likely be removed in a future release.
   [junit4] <<< JVM J1: EOF 

[...truncated 157 lines...]
   [junit4] JVM J1: stderr was not empty, see: 

[JENKINS] Lucene-Solr-NightlyTests-master - Build # 1930 - Failure

[Apache Jenkins Server]

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

No tests ran.

Build Log:
[...truncated 25 lines...]
ERROR: Failed to check out http://svn.apache.org/repos/asf/lucene/test-data
org.tmatesoft.svn.core.SVNException: svn: E175002: connection refused by the 
server
svn: E175002: OPTIONS request failed on '/repos/asf/lucene/test-data'
at 
org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:112)
at 
org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:96)
at 
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:765)
at 
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:352)
at 
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:340)
at 
org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:910)
at 
org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:702)
at 
org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:113)
at 
org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:1035)
at 
org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getLatestRevision(DAVRepository.java:164)
at 
org.tmatesoft.svn.core.internal.wc2.ng.SvnNgRepositoryAccess.getRevisionNumber(SvnNgRepositoryAccess.java:119)
at 
org.tmatesoft.svn.core.internal.wc2.SvnRepositoryAccess.getLocations(SvnRepositoryAccess.java:178)
at 
org.tmatesoft.svn.core.internal.wc2.ng.SvnNgRepositoryAccess.createRepositoryFor(SvnNgRepositoryAccess.java:43)
at 
org.tmatesoft.svn.core.internal.wc2.ng.SvnNgAbstractUpdate.checkout(SvnNgAbstractUpdate.java:831)
at 
org.tmatesoft.svn.core.internal.wc2.ng.SvnNgCheckout.run(SvnNgCheckout.java:26)
at 
org.tmatesoft.svn.core.internal.wc2.ng.SvnNgCheckout.run(SvnNgCheckout.java:11)
at 
org.tmatesoft.svn.core.internal.wc2.ng.SvnNgOperationRunner.run(SvnNgOperationRunner.java:20)
at 
org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:21)
at 
org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1239)
at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:294)
at 
hudson.scm.subversion.CheckoutUpdater$SubversionUpdateTask.perform(CheckoutUpdater.java:133)
at 
hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:168)
at 
hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:176)
at 
hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:134)
at 
hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:168)
at 
hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM.java:1041)
at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:1017)
at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:990)
at hudson.FilePath$FileCallableWrapper.call(FilePath.java:3086)
at hudson.remoting.UserRequest.perform(UserRequest.java:212)
at hudson.remoting.UserRequest.perform(UserRequest.java:54)
at hudson.remoting.Request$2.run(Request.java:369)
at 
hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:744)
Caused by: java.net.ConnectException: Connection refused
at java.net.PlainSocketImpl.socketConnect(Native Method)
at 
java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:345)
at 
java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206)
at 
java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
at java.net.Socket.connect(Socket.java:589)
at 
org.tmatesoft.svn.core.internal.util.SVNSocketConnection.run(SVNSocketConnection.java:57)
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
... 4 more
java.net.ConnectException: Connection refused
at java.net.PlainSocketImpl.socketConnect(Native Method)
at 
java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:345)
at 
java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206)
at 
java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)

[JENKINS] Lucene-Solr-NightlyTests-8.x - Build # 181 - Still Failing

[Apache Jenkins Server]

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

No tests ran.

Build Log:
[...truncated 25 lines...]
ERROR: Failed to check out http://svn.apache.org/repos/asf/lucene/test-data
org.tmatesoft.svn.core.SVNException: svn: E175002: connection refused by the 
server
svn: E175002: OPTIONS request failed on '/repos/asf/lucene/test-data'
at 
org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:112)
at 
org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:96)
at 
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:765)
at 
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:352)
at 
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:340)
at 
org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:910)
at 
org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:702)
at 
org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:113)
at 
org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:1035)
at 
org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getLatestRevision(DAVRepository.java:164)
at 
org.tmatesoft.svn.core.internal.wc2.ng.SvnNgRepositoryAccess.getRevisionNumber(SvnNgRepositoryAccess.java:119)
at 
org.tmatesoft.svn.core.internal.wc2.SvnRepositoryAccess.getLocations(SvnRepositoryAccess.java:178)
at 
org.tmatesoft.svn.core.internal.wc2.ng.SvnNgRepositoryAccess.createRepositoryFor(SvnNgRepositoryAccess.java:43)
at 
org.tmatesoft.svn.core.internal.wc2.ng.SvnNgAbstractUpdate.checkout(SvnNgAbstractUpdate.java:831)
at 
org.tmatesoft.svn.core.internal.wc2.ng.SvnNgCheckout.run(SvnNgCheckout.java:26)
at 
org.tmatesoft.svn.core.internal.wc2.ng.SvnNgCheckout.run(SvnNgCheckout.java:11)
at 
org.tmatesoft.svn.core.internal.wc2.ng.SvnNgOperationRunner.run(SvnNgOperationRunner.java:20)
at 
org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:21)
at 
org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1239)
at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:294)
at 
hudson.scm.subversion.CheckoutUpdater$SubversionUpdateTask.perform(CheckoutUpdater.java:133)
at 
hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:168)
at 
hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:176)
at 
hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:134)
at 
hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:168)
at 
hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM.java:1041)
at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:1017)
at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:990)
at hudson.FilePath$FileCallableWrapper.call(FilePath.java:3086)
at hudson.remoting.UserRequest.perform(UserRequest.java:212)
at hudson.remoting.UserRequest.perform(UserRequest.java:54)
at hudson.remoting.Request$2.run(Request.java:369)
at 
hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:744)
Caused by: java.net.ConnectException: Connection refused
at java.net.PlainSocketImpl.socketConnect(Native Method)
at 
java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:345)
at 
java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206)
at 
java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
at java.net.Socket.connect(Socket.java:589)
at 
org.tmatesoft.svn.core.internal.util.SVNSocketConnection.run(SVNSocketConnection.java:57)
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
... 4 more
java.net.ConnectException: Connection refused
at java.net.PlainSocketImpl.socketConnect(Native Method)
at 
java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:345)
at 
java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206)
at 
java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)

[jira] [Assigned] (LUCENE-8621) Move LatLonShape and XYShape out of sandbox

[Nicholas Knize (JIRA)]

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

Nicholas Knize reassigned LUCENE-8621:
--

Assignee: Nicholas Knize

> Move LatLonShape and XYShape out of sandbox
> ---
>
> Key: LUCENE-8621
> URL: https://issues.apache.org/jira/browse/LUCENE-8621
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Adrien Grand
>Assignee: Nicholas Knize
>Priority: Minor
>
> LatLonShape has matured a lot over the last months, I'd like to start 
> thinking about moving it out of sandbox so that it doesn't stay there for too 
> long like what happened to LatLonPoint. I am pretty happy with the current 
> encoding. To my knowledge, we might just need to do a minor modification 
> because of 
> LUCENE-8620.
> {{XYShape}} and foundation classes will also need to be refactored. 



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Commented] (LUCENE-8621) Move LatLonShape and XYShape out of sandbox

[Nicholas Knize (JIRA)]

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

Nicholas Knize commented on LUCENE-8621:


Per LUCENE-8369 I'll take the task of refactoring {{LatLonShape}}, {{XYShape}}, 
and all foundation, utility, and query classes 

> Move LatLonShape and XYShape out of sandbox
> ---
>
> Key: LUCENE-8621
> URL: https://issues.apache.org/jira/browse/LUCENE-8621
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Adrien Grand
>Priority: Minor
>
> LatLonShape has matured a lot over the last months, I'd like to start 
> thinking about moving it out of sandbox so that it doesn't stay there for too 
> long like what happened to LatLonPoint. I am pretty happy with the current 
> encoding. To my knowledge, we might just need to do a minor modification 
> because of 
> LUCENE-8620.
> {{XYShape}} and foundation classes will also need to be refactored. 



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Updated] (LUCENE-8621) Move LatLonShape and XYShape out of sandbox

[Nicholas Knize (JIRA)]

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

Nicholas Knize updated LUCENE-8621:
---
Description: 
LatLonShape has matured a lot over the last months, I'd like to start thinking 
about moving it out of sandbox so that it doesn't stay there for too long like 
what happened to LatLonPoint. I am pretty happy with the current encoding. To 
my knowledge, we might just need to do a minor modification because of 
LUCENE-8620.

{{XYShape}} and foundation classes will also need to be refactored. 

  was:
LatLonShape has matured a lot over the last months, I'd like to start thinking 
about moving it out of sandbox so that it doesn't stay there for too long like 
what happened to LatLonPoint. I am pretty happy with the current encoding. To 
my knowledge, we might just need to do a minor modification because of 
LUCENE-8620.


> Move LatLonShape and XYShape out of sandbox
> ---
>
> Key: LUCENE-8621
> URL: https://issues.apache.org/jira/browse/LUCENE-8621
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Adrien Grand
>Priority: Minor
>
> LatLonShape has matured a lot over the last months, I'd like to start 
> thinking about moving it out of sandbox so that it doesn't stay there for too 
> long like what happened to LatLonPoint. I am pretty happy with the current 
> encoding. To my knowledge, we might just need to do a minor modification 
> because of 
> LUCENE-8620.
> {{XYShape}} and foundation classes will also need to be refactored. 



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Comment Edited] (LUCENE-8369) Remove the spatial module as it is obsolete

[Nicholas Knize (JIRA)]

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

Nicholas Knize edited comment on LUCENE-8369 at 8/14/19 9:50 PM:
-

Sounds good to me. Thanks [~mikemccand] and [~simonw]

 [~dsmiley] I think we're good to go on this patch then to remove the spatial 
module? I'll handle refactoring {{LatLonShape}} and {{XYShape}} classes to 
{{core}} in LUCENE-8621


was (Author: nknize):
Sounds good to me. Thanks [~mikemccand] and [~simonw]

 [~dsmiley] I think we're good to go on this patch then to remove the spatial 
module? I'll handle refactoring {{LatLonShape}} and {{XYShape}} classes to 
{{core}} in a separate issue.

> Remove the spatial module as it is obsolete
> ---
>
> Key: LUCENE-8369
> URL: https://issues.apache.org/jira/browse/LUCENE-8369
> Project: Lucene - Core
>  Issue Type: Task
>  Components: modules/spatial
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Major
> Attachments: LUCENE-8369.patch
>
>
> The "spatial" module is at this juncture nearly empty with only a couple 
> utilities that aren't used by anything in the entire codebase -- 
> GeoRelationUtils, and MortonEncoder.  Perhaps it should have been removed 
> earlier in LUCENE-7664 which was the removal of GeoPointField which was 
> essentially why the module existed.  Better late than never.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Updated] (LUCENE-8621) Move LatLonShape and XYShape out of sandbox

[Nicholas Knize (JIRA)]

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

Nicholas Knize updated LUCENE-8621:
---
Summary: Move LatLonShape and XYShape out of sandbox  (was: Move 
LatLonShape out of sandbox)

> Move LatLonShape and XYShape out of sandbox
> ---
>
> Key: LUCENE-8621
> URL: https://issues.apache.org/jira/browse/LUCENE-8621
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Adrien Grand
>Priority: Minor
>
> LatLonShape has matured a lot over the last months, I'd like to start 
> thinking about moving it out of sandbox so that it doesn't stay there for too 
> long like what happened to LatLonPoint. I am pretty happy with the current 
> encoding. To my knowledge, we might just need to do a minor modification 
> because of 
> LUCENE-8620.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Commented] (LUCENE-8369) Remove the spatial module as it is obsolete

[Nicholas Knize (JIRA)]

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

Nicholas Knize commented on LUCENE-8369:


Sounds good to me. Thanks [~mikemccand] and [~simonw]

 [~dsmiley] I think we're good to go on this patch then to remove the spatial 
module? I'll handle refactoring {{LatLonShape}} and {{XYShape}} classes to 
{{core}} in a separate issue.

> Remove the spatial module as it is obsolete
> ---
>
> Key: LUCENE-8369
> URL: https://issues.apache.org/jira/browse/LUCENE-8369
> Project: Lucene - Core
>  Issue Type: Task
>  Components: modules/spatial
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Major
> Attachments: LUCENE-8369.patch
>
>
> The "spatial" module is at this juncture nearly empty with only a couple 
> utilities that aren't used by anything in the entire codebase -- 
> GeoRelationUtils, and MortonEncoder.  Perhaps it should have been removed 
> earlier in LUCENE-7664 which was the removal of GeoPointField which was 
> essentially why the module existed.  Better late than never.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Commented] (SOLR-13696) DimensionalRoutedAliasUpdateProcessorTest / RoutedAliasUpdateProcessorTest failures due commitWithin/openSearcher delays

[Hoss Man (JIRA)]

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

Hoss Man commented on SOLR-13696:
-

Gus: can you please take a look at this?

based on my assessment, here's the crucial bits of the log..
{noformat}
hossman@tray:~/tmp/jenkins/DimensionalRoutedAliasUpdateProcessorTest$ grep 
testTimeCat__TRA__2019-07-05__CRA__calico 
thetaphi_Lucene-Solr-8.x-MacOSX_272.log.txt | egrep '(Opening 
\[Searcher|add=\[21|fq=cat_s:calico|\{\!terms\+f%3Did}21,20.*hits=2)'
   [junit4]   2> 4476175 INFO  (qtp759508539-75005) [n:127.0.0.1:55915_solr 
c:testTimeCat__TRA__2019-07-05__CRA__calico s:shard1 r:core_node5 
x:testTimeCat__TRA__2019-07-05__CRA__calico_shard1_replica_n2 ] 
o.a.s.s.SolrIndexSearcher Opening 
[Searcher@9bc49f7[testTimeCat__TRA__2019-07-05__CRA__calico_shard1_replica_n2] 
main]
   [junit4]   2> 4476176 INFO  (qtp1536738594-75022) [n:127.0.0.1:55916_solr 
c:testTimeCat__TRA__2019-07-05__CRA__calico s:shard1 r:core_node3 
x:testTimeCat__TRA__2019-07-05__CRA__calico_shard1_replica_n1 ] 
o.a.s.s.SolrIndexSearcher Opening 
[Searcher@5547583d[testTimeCat__TRA__2019-07-05__CRA__calico_shard1_replica_n1] 
main]
   [junit4]   2> 4476186 INFO  (qtp1998715126-75500) [n:127.0.0.1:55917_solr 
c:testTimeCat__TRA__2019-07-05__CRA__calico s:shard2 r:core_node8 
x:testTimeCat__TRA__2019-07-05__CRA__calico_shard2_replica_n7 ] 
o.a.s.s.SolrIndexSearcher Opening 
[Searcher@3d40f0e1[testTimeCat__TRA__2019-07-05__CRA__calico_shard2_replica_n7] 
main]
   [junit4]   2> 4476195 INFO  (qtp927691752-75020) [n:127.0.0.1:55918_solr 
c:testTimeCat__TRA__2019-07-05__CRA__calico s:shard2 r:core_node6 
x:testTimeCat__TRA__2019-07-05__CRA__calico_shard2_replica_n4 ] 
o.a.s.s.SolrIndexSearcher Opening 
[Searcher@18c82bc1[testTimeCat__TRA__2019-07-05__CRA__calico_shard2_replica_n4] 
main]
   [junit4]   2> 4477375 INFO  (qtp1998715126-75016) [n:127.0.0.1:55917_solr 
c:testTimeCat__TRA__2019-07-05__CRA__calico s:shard2 r:core_node8 
x:testTimeCat__TRA__2019-07-05__CRA__calico_shard2_replica_n7 ] 
o.a.s.u.p.LogUpdateProcessorFactory 
[testTimeCat__TRA__2019-07-05__CRA__calico_shard2_replica_n7]  webapp=/solr 
path=/update 
params={update.distrib=FROMLEADER=http://127.0.0.1:55918/solr/testTimeCat__TRA__2019-07-05__CRA__calico_shard2_replica_n4/=javabin=2}{add=[21
 (1641811095092985856)]} 0 2
   [junit4]   2> 4477960 INFO  (qtp927691752-75506) [n:127.0.0.1:55918_solr 
c:testTimeCat__TRA__2019-07-05__CRA__calico s:shard2 r:core_node6 
x:testTimeCat__TRA__2019-07-05__CRA__calico_shard2_replica_n4 ] 
o.a.s.u.p.LogUpdateProcessorFactory 
[testTimeCat__TRA__2019-07-05__CRA__calico_shard2_replica_n4]  webapp=/solr 
path=/update 
params={update.distrib=NONE=_text_=TOLEADER=http://127.0.0.1:55918/solr/testTimeCat__TRA__2019-07-02__CRA__calico_shard2_replica_n6/=javabin=2=inc}{add=[21
 (1641811095092985856)]} 0 590
   [junit4]   2> 4477962 INFO  (commitScheduler-24384-thread-1) [ ] 
o.a.s.s.SolrIndexSearcher Opening 
[Searcher@745b6c94[testTimeCat__TRA__2019-07-05__CRA__calico_shard2_replica_n4] 
main]
   [junit4]   2> 4478213 INFO  (qtp1998715126-75501) [n:127.0.0.1:55917_solr 
c:testTimeCat__TRA__2019-07-05__CRA__calico s:shard2 r:core_node8 
x:testTimeCat__TRA__2019-07-05__CRA__calico_shard2_replica_n7 ] 
o.a.s.c.S.Request [testTimeCat__TRA__2019-07-05__CRA__calico_shard2_replica_n7] 
 webapp=/solr path=/select 
params={q={!terms+f%3Did}21,20=0=javabin=2} hits=2 status=0 
QTime=13
   [junit4]   2> 4478408 INFO  (qtp1998715126-75016) [n:127.0.0.1:55917_solr 
c:testTimeCat__TRA__2019-07-05__CRA__calico s:shard2 r:core_node8 
x:testTimeCat__TRA__2019-07-05__CRA__calico_shard2_replica_n7 ] 
o.a.s.c.S.Request [testTimeCat__TRA__2019-07-05__CRA__calico_shard2_replica_n7] 
 webapp=/solr path=/select 
params={df=_text_=false=id=score=516=0=true=cat_s:calico=http://127.0.0.1:55917/solr/testTimeCat__TRA__2019-07-05__CRA__calico_shard2_replica_n7/|http://127.0.0.1:55918/solr/testTimeCat__TRA__2019-07-05__CRA__calico_shard2_replica_n4/=0=2=*:*=true=false=1565753074817=true=javabin=timestamp_dt}
 hits=0 status=0 QTime=0
   [junit4]   2> 4478408 INFO  (qtp1536738594-75032) [n:127.0.0.1:55916_solr 
c:testTimeCat__TRA__2019-07-05__CRA__calico s:shard1 r:core_node3 
x:testTimeCat__TRA__2019-07-05__CRA__calico_shard1_replica_n1 ] 
o.a.s.c.S.Request [testTimeCat__TRA__2019-07-05__CRA__calico_shard1_replica_n1] 
 webapp=/solr path=/select 
params={df=_text_=false=id=score=516=0=true=cat_s:calico=http://127.0.0.1:55916/solr/testTimeCat__TRA__2019-07-05__CRA__calico_shard1_replica_n1/|http://127.0.0.1:55915/solr/testTimeCat__TRA__2019-07-05__CRA__calico_shard1_replica_n2/=0=2=*:*=true=false=1565753074817=true=javabin=timestamp_dt}
 hits=0 status=0 QTime=0
   [junit4]   2> 4478408 INFO  (qtp1536738594-75031) [n:127.0.0.1:55916_solr 
c:testTimeCat__TRA__2019-07-05__CRA__calico s:shard1 r:core_node3 

[jira] [Created] (SOLR-13696) DimensionalRoutedAliasUpdateProcessorTest / RoutedAliasUpdateProcessorTest failures due commitWithin/openSearcher delays

[Hoss Man (JIRA)]

Hoss Man created SOLR-13696:
---

 Summary: DimensionalRoutedAliasUpdateProcessorTest / 
RoutedAliasUpdateProcessorTest failures due commitWithin/openSearcher delays
 Key: SOLR-13696
 URL: https://issues.apache.org/jira/browse/SOLR-13696
 Project: Solr
  Issue Type: Test
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Hoss Man
Assignee: Gus Heck
 Attachments: thetaphi_Lucene-Solr-8.x-MacOSX_272.log.txt

Recent jenkins failure...
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-8.x-MacOSX/272/
Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseParallelGC
{noformat}
Stack Trace:
java.lang.AssertionError: expected:<16> but was:<15>
at 
__randomizedtesting.SeedInfo.seed([DB6DC28D5560B1D2:E295833E1541FDB9]: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.update.processor.DimensionalRoutedAliasUpdateProcessorTest.assertCatTimeInvariants(DimensionalRoutedAliasUpdateProcessorTest.java:677
)
at 
org.apache.solr.update.processor.DimensionalRoutedAliasUpdateProcessorTest.testTimeCat(DimensionalRoutedAliasUpdateProcessorTest.java:282)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
{noformat}

Digging into the logs, the problem appears to be in the way the test 
verifies/assumes docs have been committed.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[JENKINS-EA] Lucene-Solr-master-Windows (64bit/jdk-14-ea+9) - Build # 8087 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/8087/
Java: 64bit/jdk-14-ea+9 -XX:+UseCompressedOops -XX:+UseG1GC

9 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.cloud.TestCloudSearcherWarming

Error Message:
27 threads leaked from SUITE scope at 
org.apache.solr.cloud.TestCloudSearcherWarming: 1) Thread[id=717, 
name=MetricsHistoryHandler-157-thread-1, state=TIMED_WAITING, 
group=TGRP-TestCloudSearcherWarming] at 
java.base@14-ea/jdk.internal.misc.Unsafe.park(Native Method) at 
java.base@14-ea/java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:235)
 at 
java.base@14-ea/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2123)
 at 
java.base@14-ea/java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1182)
 at 
java.base@14-ea/java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:899)
 at 
java.base@14-ea/java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1054)
 at 
java.base@14-ea/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1114)
 at 
java.base@14-ea/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
 at java.base@14-ea/java.lang.Thread.run(Thread.java:830)2) 
Thread[id=588, name=NIOWorkerThread-5, state=WAITING, 
group=TGRP-TestCloudSearcherWarming] at 
java.base@14-ea/jdk.internal.misc.Unsafe.park(Native Method) at 
java.base@14-ea/java.util.concurrent.locks.LockSupport.park(LockSupport.java:194)
 at 
java.base@14-ea/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2081)
 at 
java.base@14-ea/java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:433)
 at 
java.base@14-ea/java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1054)
 at 
java.base@14-ea/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1114)
 at 
java.base@14-ea/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
 at java.base@14-ea/java.lang.Thread.run(Thread.java:830)3) 
Thread[id=579, name=SyncThread:0, state=WAITING, 
group=TGRP-TestCloudSearcherWarming] at 
java.base@14-ea/jdk.internal.misc.Unsafe.park(Native Method) at 
java.base@14-ea/java.util.concurrent.locks.LockSupport.park(LockSupport.java:194)
 at 
java.base@14-ea/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2081)
 at 
java.base@14-ea/java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:433)
 at 
app//org.apache.zookeeper.server.SyncRequestProcessor.run(SyncRequestProcessor.java:109)
4) Thread[id=682, 
name=qtp752311399-682-acceptor-0@553b310-ServerConnector@39531ed2{ssl,[ssl, 
alpn, http/1.1, h2]}{127.0.0.1:54417}, state=RUNNABLE, 
group=TGRP-TestCloudSearcherWarming] at 
java.base@14-ea/sun.nio.ch.Net.accept(Native Method) at 
java.base@14-ea/sun.nio.ch.ServerSocketChannelImpl.accept(ServerSocketChannelImpl.java:276)
 at 
app//org.eclipse.jetty.server.ServerConnector.accept(ServerConnector.java:385)  
   at 
app//org.eclipse.jetty.server.AbstractConnector$Acceptor.run(AbstractConnector.java:648)
 at 
app//org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:781)
 at 
app//org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:917)
 at java.base@14-ea/java.lang.Thread.run(Thread.java:830)5) 
Thread[id=581, name=NIOWorkerThread-1, state=WAITING, 
group=TGRP-TestCloudSearcherWarming] at 
java.base@14-ea/jdk.internal.misc.Unsafe.park(Native Method) at 
java.base@14-ea/java.util.concurrent.locks.LockSupport.park(LockSupport.java:194)
 at 
java.base@14-ea/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2081)
 at 
java.base@14-ea/java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:433)
 at 
java.base@14-ea/java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1054)
 at 
java.base@14-ea/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1114)
 at 
java.base@14-ea/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
 at java.base@14-ea/java.lang.Thread.run(Thread.java:830)6) 
Thread[id=681, name=qtp752311399-681, state=RUNNABLE, 
group=TGRP-TestCloudSearcherWarming] at 
java.base@14-ea/sun.nio.ch.WindowsSelectorImpl$SubSelector.poll0(Native Method) 
at 
java.base@14-ea/sun.nio.ch.WindowsSelectorImpl$SubSelector.poll(WindowsSelectorImpl.java:339)
 

[jira] [Commented] (SOLR-13663) XML Query Parser to Support SpanPositionRangeQuery

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev commented on SOLR-13663:
-

Sorry.
* master 
https://gitbox.apache.org/repos/asf?p=lucene-solr.git;a=commit;h=70162d3fb1a03b1ecd14135aec79cd1ccb481636
 
* branch_8x  
https://gitbox.apache.org/repos/asf?p=lucene-solr.git;a=commit;h=ea8f921e71e628e2334ea2fdf2f3c95c6fe427a8

> XML Query Parser to Support SpanPositionRangeQuery
> --
>
> Key: SOLR-13663
> URL: https://issues.apache.org/jira/browse/SOLR-13663
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: query parsers
>Affects Versions: 8.2
>Reporter: Alessandro Benedetti
>Priority: Major
> Attachments: SOLR-13663.patch, SOLR-13663.patch
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> Currently the XML Query Parser support a vast array of span queries, 
> including the SpanFirstQuery, but it doesn't support the generic 
> SpanPositionRangeQuery.
> < SpanPositionRange start="2" end="3">
>  prejudice
>  
>  
> Scope of this issue is to introduce the related builder and allow the 
> possibility to build such queries.
>  



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Updated] (SOLR-13663) XML Query Parser to Support SpanPositionRangeQuery

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev updated SOLR-13663:

   Resolution: Fixed
Fix Version/s: 8.3
   Status: Resolved  (was: Patch Available)

> XML Query Parser to Support SpanPositionRangeQuery
> --
>
> Key: SOLR-13663
> URL: https://issues.apache.org/jira/browse/SOLR-13663
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: query parsers
>Affects Versions: 8.2
>Reporter: Alessandro Benedetti
>Assignee: Mikhail Khludnev
>Priority: Major
> Fix For: 8.3
>
> Attachments: SOLR-13663.patch, SOLR-13663.patch
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> Currently the XML Query Parser support a vast array of span queries, 
> including the SpanFirstQuery, but it doesn't support the generic 
> SpanPositionRangeQuery.
> < SpanPositionRange start="2" end="3">
>  prejudice
>  
>  
> Scope of this issue is to introduce the related builder and allow the 
> possibility to build such queries.
>  



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Assigned] (SOLR-13663) XML Query Parser to Support SpanPositionRangeQuery

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev reassigned SOLR-13663:
---

Assignee: Mikhail Khludnev

> XML Query Parser to Support SpanPositionRangeQuery
> --
>
> Key: SOLR-13663
> URL: https://issues.apache.org/jira/browse/SOLR-13663
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: query parsers
>Affects Versions: 8.2
>Reporter: Alessandro Benedetti
>Assignee: Mikhail Khludnev
>Priority: Major
> Attachments: SOLR-13663.patch, SOLR-13663.patch
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> Currently the XML Query Parser support a vast array of span queries, 
> including the SpanFirstQuery, but it doesn't support the generic 
> SpanPositionRangeQuery.
> < SpanPositionRange start="2" end="3">
>  prejudice
>  
>  
> Scope of this issue is to introduce the related builder and allow the 
> possibility to build such queries.
>  



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[JENKINS] Lucene-Solr-BadApples-Tests-master - Build # 445 - Unstable

[Apache Jenkins Server]

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

1 tests failed.
FAILED:  org.apache.lucene.index.TestIndexFileDeleter.testExcInDecRef

Error Message:
ReaderPool is already closed

Stack Trace:
org.apache.lucene.store.AlreadyClosedException: ReaderPool is already closed
at 
__randomizedtesting.SeedInfo.seed([7DACC6365B2441E1:9431B1042DEDA61C]:0)
at org.apache.lucene.index.ReaderPool.get(ReaderPool.java:369)
at 
org.apache.lucene.index.IndexWriter.writeReaderPool(IndexWriter.java:3301)
at org.apache.lucene.index.IndexWriter.doFlush(IndexWriter.java:3601)
at org.apache.lucene.index.IndexWriter.flush(IndexWriter.java:3549)
at org.apache.lucene.index.IndexWriter.forceMerge(IndexWriter.java:1943)
at org.apache.lucene.index.IndexWriter.forceMerge(IndexWriter.java:1923)
at 
org.apache.lucene.index.RandomIndexWriter.doRandomForceMerge(RandomIndexWriter.java:408)
at 
org.apache.lucene.index.RandomIndexWriter.getReader(RandomIndexWriter.java:432)
at 
org.apache.lucene.index.RandomIndexWriter.getReader(RandomIndexWriter.java:376)
at 
org.apache.lucene.index.TestIndexFileDeleter.testExcInDecRef(TestIndexFileDeleter.java:465)
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)




Build Log:
[...truncated 1411 lines...]
   [junit4] Suite: 

[jira] [Commented] (SOLR-13695) SPLITSHARD (link), followed by DELETESHARD of parent shard causes data loss

[Yonik Seeley (JIRA)]

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

Yonik Seeley commented on SOLR-13695:
-

Was the SPLITSHARD asynchronous?  I'm wondering if maybe the DELETESHARD 
happened before the SPLITSHARD completed.

> SPLITSHARD (link), followed by DELETESHARD of parent shard causes data loss
> ---
>
> Key: SOLR-13695
> URL: https://issues.apache.org/jira/browse/SOLR-13695
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Ishan Chattopadhyaya
>Assignee: Ishan Chattopadhyaya
>Priority: Critical
>
> One of my clients experienced data loss with the following sequence of 
> operations:
> 1) SPLITSHARD with method as "link".
> 2) DELETESHARD of the parent (inactive) shard.
> 3) Query for documents in the subshards, seems like both subshards have 0 
> documents.
> Proposing a fix (after offline discussion with [~noble.paul]) based on 
> running FORCEMERGE after SPLITSHARD (such that segments are rewritten), and 
> not letting DELETESHARD delete the data directory until the FORCEMERGE 
> operations finish.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[GitHub] [lucene-solr] jtibshirani opened a new pull request #832: LUCENE-8952: Use a sort key instead of true distance in NearestNeighbors.

[GitBox]

jtibshirani opened a new pull request #832: LUCENE-8952: Use a sort key instead 
of true distance in NearestNeighbors.
URL: https://github.com/apache/lucene-solr/pull/832
 
 
   This commit addresses a TODO in NearestNeighbors around switching to
   `SloppyMath.haversinSortKey`. When comparing candidate hits, we now only 
compute
   a distance sort key. The sort key is converted to a true distance only when 
returning
   the final set of `FieldDocs` and when calculating the bbox for the current 
search area.
   


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] [Created] (LUCENE-8952) Use a sort key instead of true distance in NearestNeighbors.

[Julie Tibshirani (JIRA)]

Julie Tibshirani created LUCENE-8952:


 Summary: Use a sort key instead of true distance in 
NearestNeighbors.
 Key: LUCENE-8952
 URL: https://issues.apache.org/jira/browse/LUCENE-8952
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Julie Tibshirani


The NearestNeighbors class contains a TODO to switch to 
SloppyMath.haversinSortKey when comparing candidate nearest neighbors. This 
change is not high priority, but could be a nice way to get more familiar with 
the kNN search implementation.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

-
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 # 266 - Still Unstable!

[Policeman Jenkins Server]

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

1 tests failed.
FAILED:  
org.apache.solr.cloud.TestSolrCloudWithDelegationTokens.testDelegationTokenRenew

Error Message:
expected:<200> but was:<403>

Stack Trace:
java.lang.AssertionError: expected:<200> but was:<403>
at 
__randomizedtesting.SeedInfo.seed([61EB2273E740ABB5:5670D66DDF8C7611]: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.cloud.TestSolrCloudWithDelegationTokens.renewDelegationToken(TestSolrCloudWithDelegationTokens.java:135)
at 
org.apache.solr.cloud.TestSolrCloudWithDelegationTokens.verifyDelegationTokenRenew(TestSolrCloudWithDelegationTokens.java:320)
at 
org.apache.solr.cloud.TestSolrCloudWithDelegationTokens.testDelegationTokenRenew(TestSolrCloudWithDelegationTokens.java:338)
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 

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

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/24544/
Java: 64bit/jdk-12.0.1 -XX:+UseCompressedOops -XX:+UseG1GC

4 tests failed.
FAILED:  org.apache.lucene.document.TestFeatureSort.testDuelFloat

Error Message:
Hit 1 docnumbers don't match Hits length1=10 length2=10 hit=0: doc75=NaN 
shardIndex=-1,  doc75=NaN shardIndex=-1 hit=1: doc278=NaN shardIndex=-1,  
doc119=NaN shardIndex=-1 hit=2: doc119=NaN shardIndex=-1,  doc278=NaN 
shardIndex=-1 hit=3: doc241=NaN shardIndex=-1,  doc241=NaN shardIndex=-1 hit=4: 
doc251=NaN shardIndex=-1,  doc251=NaN shardIndex=-1 hit=5: doc175=NaN 
shardIndex=-1,  doc175=NaN shardIndex=-1 hit=6: doc231=NaN shardIndex=-1,  
doc231=NaN shardIndex=-1 hit=7: doc112=NaN shardIndex=-1,  doc112=NaN 
shardIndex=-1 hit=8: doc196=NaN shardIndex=-1,  doc196=NaN shardIndex=-1 hit=9: 
doc86=NaN shardIndex=-1,  doc86=NaN shardIndex=-1 for query:*:*

Stack Trace:
junit.framework.AssertionFailedError: Hit 1 docnumbers don't match
Hits length1=10 length2=10
hit=0: doc75=NaN shardIndex=-1,  doc75=NaN shardIndex=-1
hit=1: doc278=NaN shardIndex=-1, doc119=NaN shardIndex=-1
hit=2: doc119=NaN shardIndex=-1, doc278=NaN shardIndex=-1
hit=3: doc241=NaN shardIndex=-1, doc241=NaN shardIndex=-1
hit=4: doc251=NaN shardIndex=-1, doc251=NaN shardIndex=-1
hit=5: doc175=NaN shardIndex=-1, doc175=NaN shardIndex=-1
hit=6: doc231=NaN shardIndex=-1, doc231=NaN shardIndex=-1
hit=7: doc112=NaN shardIndex=-1, doc112=NaN shardIndex=-1
hit=8: doc196=NaN shardIndex=-1, doc196=NaN shardIndex=-1
hit=9: doc86=NaN shardIndex=-1,  doc86=NaN shardIndex=-1
for query:*:*
at 
__randomizedtesting.SeedInfo.seed([A40814F874F2E088:2C5A16D30A74A31A]:0)
at junit.framework.Assert.fail(Assert.java:57)
at org.apache.lucene.search.CheckHits.checkEqual(CheckHits.java:205)
at 
org.apache.lucene.document.TestFeatureSort.testDuelFloat(TestFeatureSort.java:263)
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 
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 

[jira] [Commented] (SOLR-13694) IndexSizeEstimator NullPointerException

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-13694:


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

SOLR-13694: IndexSizeEstimator NullPointerException.


> IndexSizeEstimator NullPointerException
> ---
>
> Key: SOLR-13694
> URL: https://issues.apache.org/jira/browse/SOLR-13694
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Assignee: Andrzej Bialecki 
>Priority: Major
> Attachments: SOLR-13694.patch
>
>
> Jenkins found a reproducible seed for trigging an NPE in 
> IndexSizeEstimatorTest
> Based on a little experimental tracing i did, this might be a real bug in 
> IndexSizeEstimator? ... it's calling close on StoredFieldsReader instances it 
> gets from the CodecReader -- but AFAICT from the docs/code i'm not certain if 
> it should be doing this.  It appears the expectation is that this is direct 
> access to the internal state, that will automatically be closed when the 
> CodecReader is closed.
> ie: IndexSizeEstimator is closing StoredFieldsReader pre-maturely, causing it 
> to be unusbale on the next iteration.
> (I didn't dig in far enough to guess if there are other places in the 
> IndexSizeEstimator code that are closing CodecReader internals prematurely as 
> well, or just in this situation ... it's also not clear if this only causes 
> failures because this seed uses SimpleTextCodec, and other codecs are more 
> forgiving -- or if something else about the index(es) generated for this seed 
> are what cause the problem to manifest)
> http://fucit.org/solr-jenkins-reports/job-data/apache/Lucene-Solr-NightlyTests-master/1928
> {noformat}
> hossman@tray:~/lucene/dev/solr/core [j11] [master] $ git rev-parse HEAD
> 0291db44bc8e092f7cb2f577f0ac8ab6fa6a5fd7
> hossman@tray:~/lucene/dev/solr/core [j11] [master] $ ant test  
> -Dtestcase=IndexSizeEstimatorTest -Dtests.method=testEstimator 
> -Dtests.seed=23F60434E13D8FD4 -Dtests.multiplier=2 -Dtests.nightly=true 
> -Dtests.slow=true  -Dtests.locale=eo -Dtests.timezone=Atlantic/Madeira 
> -Dtests.asserts=true -Dtests.file.encoding=UTF-8
> ...
>[junit4]   2> NOTE: reproduce with: ant test  
> -Dtestcase=IndexSizeEstimatorTest -Dtests.method=testEstimator 
> -Dtests.seed=23F60434E13D8FD4 -Dtests.multiplier=2 -Dtests.nightly=true 
> -Dtests.slow=true -Dtests.badapples=true -Dtests.locale=eo 
> -Dtests.timezone=Atlantic/Madeira -Dtests.asserts=true 
> -Dtests.file.encoding=UTF-8
>[junit4] ERROR   0.88s | IndexSizeEstimatorTest.testEstimator <<<
>[junit4]> Throwable #1: java.lang.NullPointerException
>[junit4]>at 
> __randomizedtesting.SeedInfo.seed([23F60434E13D8FD4:EC2B6B666D451E64]:0)
>[junit4]>at 
> org.apache.lucene.codecs.simpletext.SimpleTextStoredFieldsReader.visitDocument(SimpleTextStoredFieldsReader.java:109)
>[junit4]>at 
> org.apache.solr.handler.admin.IndexSizeEstimator.estimateStoredFields(IndexSizeEstimator.java:513)
>[junit4]>at 
> org.apache.solr.handler.admin.IndexSizeEstimator.estimate(IndexSizeEstimator.java:198)
>[junit4]>at 
> org.apache.solr.handler.admin.IndexSizeEstimatorTest.testEstimator(IndexSizeEstimatorTest.java:117)
>[junit4]>at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>[junit4]>at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>[junit4]>at 
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>[junit4]>at 
> java.base/java.lang.reflect.Method.invoke(Method.java:566)
>[junit4]>at java.base/java.lang.Thread.run(Thread.java:834)
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Commented] (SOLR-13695) SPLITSHARD (link), followed by DELETESHARD of parent shard causes data loss

[Ishan Chattopadhyaya (JIRA)]

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

Ishan Chattopadhyaya commented on SOLR-13695:
-

Happened on 7.7.1. I don't have the logs now, but I can try to reproduce on 
master or 8.2 and attach logs.

> SPLITSHARD (link), followed by DELETESHARD of parent shard causes data loss
> ---
>
> Key: SOLR-13695
> URL: https://issues.apache.org/jira/browse/SOLR-13695
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Ishan Chattopadhyaya
>Assignee: Ishan Chattopadhyaya
>Priority: Critical
>
> One of my clients experienced data loss with the following sequence of 
> operations:
> 1) SPLITSHARD with method as "link".
> 2) DELETESHARD of the parent (inactive) shard.
> 3) Query for documents in the subshards, seems like both subshards have 0 
> documents.
> Proposing a fix (after offline discussion with [~noble.paul]) based on 
> running FORCEMERGE after SPLITSHARD (such that segments are rewritten), and 
> not letting DELETESHARD delete the data directory until the FORCEMERGE 
> operations finish.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Commented] (SOLR-13694) IndexSizeEstimator NullPointerException

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-13694:


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

SOLR-13694: IndexSizeEstimator NullPointerException.


> IndexSizeEstimator NullPointerException
> ---
>
> Key: SOLR-13694
> URL: https://issues.apache.org/jira/browse/SOLR-13694
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Assignee: Andrzej Bialecki 
>Priority: Major
> Attachments: SOLR-13694.patch
>
>
> Jenkins found a reproducible seed for trigging an NPE in 
> IndexSizeEstimatorTest
> Based on a little experimental tracing i did, this might be a real bug in 
> IndexSizeEstimator? ... it's calling close on StoredFieldsReader instances it 
> gets from the CodecReader -- but AFAICT from the docs/code i'm not certain if 
> it should be doing this.  It appears the expectation is that this is direct 
> access to the internal state, that will automatically be closed when the 
> CodecReader is closed.
> ie: IndexSizeEstimator is closing StoredFieldsReader pre-maturely, causing it 
> to be unusbale on the next iteration.
> (I didn't dig in far enough to guess if there are other places in the 
> IndexSizeEstimator code that are closing CodecReader internals prematurely as 
> well, or just in this situation ... it's also not clear if this only causes 
> failures because this seed uses SimpleTextCodec, and other codecs are more 
> forgiving -- or if something else about the index(es) generated for this seed 
> are what cause the problem to manifest)
> http://fucit.org/solr-jenkins-reports/job-data/apache/Lucene-Solr-NightlyTests-master/1928
> {noformat}
> hossman@tray:~/lucene/dev/solr/core [j11] [master] $ git rev-parse HEAD
> 0291db44bc8e092f7cb2f577f0ac8ab6fa6a5fd7
> hossman@tray:~/lucene/dev/solr/core [j11] [master] $ ant test  
> -Dtestcase=IndexSizeEstimatorTest -Dtests.method=testEstimator 
> -Dtests.seed=23F60434E13D8FD4 -Dtests.multiplier=2 -Dtests.nightly=true 
> -Dtests.slow=true  -Dtests.locale=eo -Dtests.timezone=Atlantic/Madeira 
> -Dtests.asserts=true -Dtests.file.encoding=UTF-8
> ...
>[junit4]   2> NOTE: reproduce with: ant test  
> -Dtestcase=IndexSizeEstimatorTest -Dtests.method=testEstimator 
> -Dtests.seed=23F60434E13D8FD4 -Dtests.multiplier=2 -Dtests.nightly=true 
> -Dtests.slow=true -Dtests.badapples=true -Dtests.locale=eo 
> -Dtests.timezone=Atlantic/Madeira -Dtests.asserts=true 
> -Dtests.file.encoding=UTF-8
>[junit4] ERROR   0.88s | IndexSizeEstimatorTest.testEstimator <<<
>[junit4]> Throwable #1: java.lang.NullPointerException
>[junit4]>at 
> __randomizedtesting.SeedInfo.seed([23F60434E13D8FD4:EC2B6B666D451E64]:0)
>[junit4]>at 
> org.apache.lucene.codecs.simpletext.SimpleTextStoredFieldsReader.visitDocument(SimpleTextStoredFieldsReader.java:109)
>[junit4]>at 
> org.apache.solr.handler.admin.IndexSizeEstimator.estimateStoredFields(IndexSizeEstimator.java:513)
>[junit4]>at 
> org.apache.solr.handler.admin.IndexSizeEstimator.estimate(IndexSizeEstimator.java:198)
>[junit4]>at 
> org.apache.solr.handler.admin.IndexSizeEstimatorTest.testEstimator(IndexSizeEstimatorTest.java:117)
>[junit4]>at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>[junit4]>at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>[junit4]>at 
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>[junit4]>at 
> java.base/java.lang.reflect.Method.invoke(Method.java:566)
>[junit4]>at java.base/java.lang.Thread.run(Thread.java:834)
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Commented] (LUCENE-8884) Add Directory wrapper to track per-query IO counters

[Robert Muir (JIRA)]

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

Robert Muir commented on LUCENE-8884:
-

are threadlocals really needed? must you call get on every op vs once in the 
ctor? after all thats why we have clone? ( should not have thread issues ). 
readint has a second spurious call.

> Add Directory wrapper to track per-query IO counters
> 
>
> Key: LUCENE-8884
> URL: https://issues.apache.org/jira/browse/LUCENE-8884
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/store
>Reporter: Michael McCandless
>Assignee: Michael McCandless
>Priority: Minor
> Attachments: LUCENE-8884.patch
>
>
> Lucene's IO abstractions ({{Directory, IndexInput/Output}}) make it really 
> easy to track counters of how many IOPs and net bytes are read for each 
> query, which is a useful metric to track/aggregate/alarm on in production or 
> dev benchmarks.
> At my day job we use these wrappers in our nightly benchmarks to catch any 
> accidental performance regressions.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[GitHub] [lucene-solr] uschindler commented on a change in pull request #758: LUCENE-8833: Add a #load() method to IndexInput to allow preloading file content into physical memory

[GitBox]

uschindler commented on a change in pull request #758: LUCENE-8833: Add a 
#load() method to IndexInput to allow preloading file content into physical 
memory
URL: https://github.com/apache/lucene-solr/pull/758#discussion_r313964577
 
 

 ##
 File path: solr/core/src/java/org/apache/solr/core/MMapDirectoryFactory.java
 ##
 @@ -61,13 +64,23 @@ public void init(NamedList args) {
   @Override
   protected Directory create(String path, LockFactory lockFactory, DirContext 
dirContext) throws IOException {
 // we pass NoLockFactory, because the real lock factory is set later by 
injectLockFactory:
-MMapDirectory mapDirectory = new MMapDirectory(new File(path).toPath(), 
lockFactory, maxChunk);
+final boolean preloadIndexInput = this.preload;
+MMapDirectory mapDirectory = new MMapDirectory(new File(path).toPath(), 
lockFactory, maxChunk) {
 
 Review comment:
   I know you don't care about Solr, but this seems to change the system 
information to show a strange class name instead of the current MMapDirectory 
output in the system info page of Solr. I have to investigate this, but as said 
before, I tend to not remove the setPreload() method.


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

[GitHub] [lucene-solr] uschindler commented on a change in pull request #758: LUCENE-8833: Add a #load() method to IndexInput to allow preloading file content into physical memory

[GitBox]

uschindler commented on a change in pull request #758: LUCENE-8833: Add a 
#load() method to IndexInput to allow preloading file content into physical 
memory
URL: https://github.com/apache/lucene-solr/pull/758#discussion_r313962652
 
 

 ##
 File path: lucene/core/src/java/org/apache/lucene/store/MMapDirectory.java
 ##
 @@ -202,24 +201,6 @@ public boolean getUseUnmap() {
 return useUnmapHack;
   }
   
-  /**
-   * Set to {@code true} to ask mapped pages to be loaded
-   * into physical memory on init. The behavior is best-effort 
-   * and operating system dependent.
-   * @see MappedByteBuffer#load
-   */
-  public void setPreload(boolean preload) {
 
 Review comment:
   I tend to keep the "always preload method", just deprecate it for now. I 
know many people that use this globally. It has the side-effect of setting 
madvise to "WILL_NEED" for the whole buffer (in addition to load it), so it is 
a bit more sticky as it's marked to the kernel as "i will need it soon".


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] [Updated] (SOLR-13693) Use strongly-typed setters for cache parameters

[Andrzej Bialecki (JIRA)]

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

Andrzej Bialecki  updated SOLR-13693:
-
Resolution: Fixed
Status: Resolved  (was: Patch Available)

> Use strongly-typed setters for cache parameters
> ---
>
> Key: SOLR-13693
> URL: https://issues.apache.org/jira/browse/SOLR-13693
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 8.3
>Reporter: Andrzej Bialecki 
>Assignee: Andrzej Bialecki 
>Priority: Major
> Fix For: 8.3
>
> Attachments: SOLR-13693.patch
>
>
> SOLR-13558 added ability to modify cache parameters on the fly. It uses an 
> API similar to the originally proposed API in SOLR-13579. After several 
> iterations of that patch it became clear that the originally proposed 
> weakly-typed API should be replaced with a strongly-typed one.
> Since it's a new API in 8.3 there are no back-compat considerations.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Commented] (SOLR-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-13452:


Commit c4c273e71d1b8492ee70c01603ef2be9e7e2fbcc in lucene-solr's branch 
refs/heads/jira/SOLR-13452_gradle_5 from Mark Robert Miller
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=c4c273e ]

SOLR-13452: Variety of small tweaks and improvements.


> Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
> -
>
> Key: SOLR-13452
> URL: https://issues.apache.org/jira/browse/SOLR-13452
> Project: Solr
>  Issue Type: Improvement
>  Components: Build
>Reporter: Mark Miller
>Assignee: Mark Miller
>Priority: Major
> Fix For: master (9.0)
>
> Attachments: gradle-build.pdf
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> I took some things from the great work that Dat did in 
> [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a 
> little further.
>  
> When working with gradle in sub modules directly, I recommend 
> [https://github.com/dougborg/gdub]
> This gradle branch uses the following plugin for version locking, version 
> configuration and version consistency across modules: 
> [https://github.com/palantir/gradle-consistent-versions]
>  
> https://github.com/apache/lucene-solr/tree/jira/SOLR-13452_gradle_5



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Commented] (SOLR-13695) SPLITSHARD (link), followed by DELETESHARD of parent shard causes data loss

[Andrzej Bialecki (JIRA)]

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

Andrzej Bialecki  commented on SOLR-13695:
--

Also, what version of Solr is this? Any pertinent logs?

> SPLITSHARD (link), followed by DELETESHARD of parent shard causes data loss
> ---
>
> Key: SOLR-13695
> URL: https://issues.apache.org/jira/browse/SOLR-13695
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Ishan Chattopadhyaya
>Assignee: Ishan Chattopadhyaya
>Priority: Critical
>
> One of my clients experienced data loss with the following sequence of 
> operations:
> 1) SPLITSHARD with method as "link".
> 2) DELETESHARD of the parent (inactive) shard.
> 3) Query for documents in the subshards, seems like both subshards have 0 
> documents.
> Proposing a fix (after offline discussion with [~noble.paul]) based on 
> running FORCEMERGE after SPLITSHARD (such that segments are rewritten), and 
> not letting DELETESHARD delete the data directory until the FORCEMERGE 
> operations finish.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Commented] (SOLR-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-13452:


Commit c892a9c8c12611649eb0984825d90b6bc4003439 in lucene-solr's branch 
refs/heads/jira/SOLR-13452_gradle_5 from Mark Robert Miller
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=c892a9c ]

SOLR-13452: Fix two other JdepsReport method calls.


> Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
> -
>
> Key: SOLR-13452
> URL: https://issues.apache.org/jira/browse/SOLR-13452
> Project: Solr
>  Issue Type: Improvement
>  Components: Build
>Reporter: Mark Miller
>Assignee: Mark Miller
>Priority: Major
> Fix For: master (9.0)
>
> Attachments: gradle-build.pdf
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> I took some things from the great work that Dat did in 
> [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a 
> little further.
>  
> When working with gradle in sub modules directly, I recommend 
> [https://github.com/dougborg/gdub]
> This gradle branch uses the following plugin for version locking, version 
> configuration and version consistency across modules: 
> [https://github.com/palantir/gradle-consistent-versions]
>  
> https://github.com/apache/lucene-solr/tree/jira/SOLR-13452_gradle_5



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Comment Edited] (SOLR-13695) SPLITSHARD (link), followed by DELETESHARD of parent shard causes data loss

[Andrzej Bialecki (JIRA)]

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

Andrzej Bialecki  edited comment on SOLR-13695 at 8/14/19 3:47 PM:
---

Theoretically this should not happen... the index files of the sub-shards are 
hard-linked to the original shard BUT they are located in a different directory 
so deleting the parent shard should simply delete those directory entries 
(decrementing the number of existing links to the FS inodes).

I'll try to reproduce this. The proposed fix is a temporary workaround at best 
because it defeats the whole point of {{splitMethod=link}}, which is to avoid 
rewriting segments - you could just specify {{splitMethod=rewrite}} and it 
would have the same effect.


was (Author: ab):
Theoretically this should not happen... the index files of the sub-shards are 
hard-linked to the original shard BUT they are located in a different directory 
so deleting the parent shard should simply delete those directory entries 
(decrementing the number of existing links to the FS inodes).

I'll try to reproduce this. The proposed fix is a temporary workaround at best 
because it defeats the whole point of {{splitMethod=link}}, which is to avoid 
rewriting segments.

> SPLITSHARD (link), followed by DELETESHARD of parent shard causes data loss
> ---
>
> Key: SOLR-13695
> URL: https://issues.apache.org/jira/browse/SOLR-13695
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Ishan Chattopadhyaya
>Assignee: Ishan Chattopadhyaya
>Priority: Critical
>
> One of my clients experienced data loss with the following sequence of 
> operations:
> 1) SPLITSHARD with method as "link".
> 2) DELETESHARD of the parent (inactive) shard.
> 3) Query for documents in the subshards, seems like both subshards have 0 
> documents.
> Proposing a fix (after offline discussion with [~noble.paul]) based on 
> running FORCEMERGE after SPLITSHARD (such that segments are rewritten), and 
> not letting DELETESHARD delete the data directory until the FORCEMERGE 
> operations finish.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Commented] (SOLR-13695) SPLITSHARD (link), followed by DELETESHARD of parent shard causes data loss

[Andrzej Bialecki (JIRA)]

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

Andrzej Bialecki  commented on SOLR-13695:
--

Theoretically this should not happen... the index files of the sub-shards are 
hard-linked to the original shard BUT they are located in a different directory 
so deleting the parent shard should simply delete those directory entries 
(decrementing the number of existing links to the FS inodes).

I'll try to reproduce this. The proposed fix is a temporary workaround at best 
because it defeats the whole point of {{splitMethod=link}}, which is to avoid 
rewriting segments.

> SPLITSHARD (link), followed by DELETESHARD of parent shard causes data loss
> ---
>
> Key: SOLR-13695
> URL: https://issues.apache.org/jira/browse/SOLR-13695
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Ishan Chattopadhyaya
>Assignee: Ishan Chattopadhyaya
>Priority: Critical
>
> One of my clients experienced data loss with the following sequence of 
> operations:
> 1) SPLITSHARD with method as "link".
> 2) DELETESHARD of the parent (inactive) shard.
> 3) Query for documents in the subshards, seems like both subshards have 0 
> documents.
> Proposing a fix (after offline discussion with [~noble.paul]) based on 
> running FORCEMERGE after SPLITSHARD (such that segments are rewritten), and 
> not letting DELETESHARD delete the data directory until the FORCEMERGE 
> operations finish.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

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

[Apache Jenkins Server]

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

1 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([638C0E8B85D66540:7C5B92A7F6DD9C0B]: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:303)
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 14647 lines...]
   [junit4] Suite: org.apache.solr.cloud.AliasIntegrationTest
   [junit4]   2> 2471346 INFO  
(SUITE-AliasIntegrationTest-seed#[638C0E8B85D66540]-worker) [ ] 
o.a.s.SolrTestCaseJ4 Created dataDir: 

[jira] [Commented] (LUCENE-8884) Add Directory wrapper to track per-query IO counters

[Michael McCandless (JIRA)]

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

Michael McCandless commented on LUCENE-8884:


I plan to push this soon ... just adds this new directory wrapper to {{misc}} 
module.

> Add Directory wrapper to track per-query IO counters
> 
>
> Key: LUCENE-8884
> URL: https://issues.apache.org/jira/browse/LUCENE-8884
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/store
>Reporter: Michael McCandless
>Assignee: Michael McCandless
>Priority: Minor
> Attachments: LUCENE-8884.patch
>
>
> Lucene's IO abstractions ({{Directory, IndexInput/Output}}) make it really 
> easy to track counters of how many IOPs and net bytes are read for each 
> query, which is a useful metric to track/aggregate/alarm on in production or 
> dev benchmarks.
> At my day job we use these wrappers in our nightly benchmarks to catch any 
> accidental performance regressions.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Commented] (LUCENE-8947) Indexing fails with "too many tokens for field" when using custom term frequencies

[Michael McCandless (JIRA)]

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

Michael McCandless commented on LUCENE-8947:


Indeed we disable norms ... that’s a good idea to skip length accumulation when 
norms are disabled.  I’ll give that a shot.

> Indexing fails with "too many tokens for field" when using custom term 
> frequencies
> --
>
> Key: LUCENE-8947
> URL: https://issues.apache.org/jira/browse/LUCENE-8947
> Project: Lucene - Core
>  Issue Type: Improvement
>Affects Versions: 7.5
>Reporter: Michael McCandless
>Priority: Major
>
> We are using custom term frequencies (LUCENE-7854) to index per-token scoring 
> signals, however for one document that had many tokens and those tokens had 
> fairly large (~998,000) scoring signals, we hit this exception:
> {noformat}
> 2019-08-05T21:32:37,048 [ERROR] (LuceneIndexing-3-thread-3) 
> com.amazon.lucene.index.IndexGCRDocument: Failed to index doc: 
> java.lang.IllegalArgumentException: too many tokens for field "foobar"
> at 
> org.apache.lucene.index.DefaultIndexingChain$PerField.invert(DefaultIndexingChain.java:825)
> at 
> org.apache.lucene.index.DefaultIndexingChain.processField(DefaultIndexingChain.java:430)
> at 
> org.apache.lucene.index.DefaultIndexingChain.processDocument(DefaultIndexingChain.java:394)
> at 
> org.apache.lucene.index.DocumentsWriterPerThread.updateDocuments(DocumentsWriterPerThread.java:297)
> at 
> org.apache.lucene.index.DocumentsWriter.updateDocuments(DocumentsWriter.java:450)
> at org.apache.lucene.index.IndexWriter.updateDocuments(IndexWriter.java:1291)
> at org.apache.lucene.index.IndexWriter.addDocuments(IndexWriter.java:1264)
> {noformat}
> This is happening in this code in {{DefaultIndexingChain.java}}:
> {noformat}
>   try {
> invertState.length = Math.addExact(invertState.length, 
> invertState.termFreqAttribute.getTermFrequency());
>   } catch (ArithmeticException ae) {
> throw new IllegalArgumentException("too many tokens for field \"" + 
> field.name() + "\"");
>   }{noformat}
> Where Lucene is accumulating the total length (number of tokens) for the 
> field.  But total length doesn't really make sense if you are using custom 
> term frequencies to hold arbitrary scoring signals?  Or, maybe it does make 
> sense, if user is using this as simple boosting, but maybe we should allow 
> this length to be a {{long}}?



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[JENKINS] Lucene-Solr-master-Linux (64bit/jdk-12.0.1) - Build # 24543 - Failure!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/24543/
Java: 64bit/jdk-12.0.1 -XX:+UseCompressedOops -XX:+UseSerialGC

All tests passed

Build Log:
[...truncated 5102 lines...]
   [junit4] JVM J1: stdout was not empty, see: 
/home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/build/backward-codecs/test/temp/junit4-J1-20190814_144915_26213915127782056805534.sysout
   [junit4] >>> JVM J1 emitted unexpected output (verbatim) 
   [junit4] #
   [junit4] # A fatal error has been detected by the Java Runtime Environment:
   [junit4] #
   [junit4] #  SIGSEGV (0xb) at pc=0x7f9d68afe7ac, pid=16397, tid=17977
   [junit4] #
   [junit4] # JRE version: OpenJDK Runtime Environment (12.0.1+12) (build 
12.0.1+12)
   [junit4] # Java VM: OpenJDK 64-Bit Server VM (12.0.1+12, mixed mode, 
sharing, tiered, compressed oops, serial gc, linux-amd64)
   [junit4] # Problematic frame:
   [junit4] # V  [libjvm.so+0xe387ac]  PhaseIdealLoop::split_up(Node*, Node*, 
Node*) [clone .part.38]+0x47c
   [junit4] #
   [junit4] # No core dump will be written. Core dumps have been disabled. To 
enable core dumping, try "ulimit -c unlimited" before starting Java again
   [junit4] #
   [junit4] # An error report file with more information is saved as:
   [junit4] # 
/home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/build/backward-codecs/test/J1/hs_err_pid16397.log
   [junit4] #
   [junit4] # Compiler replay data is saved as:
   [junit4] # 
/home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/build/backward-codecs/test/J1/replay_pid16397.log
   [junit4] #
   [junit4] # If you would like to submit a bug report, please visit:
   [junit4] #   https://github.com/AdoptOpenJDK/openjdk-build/issues
   [junit4] #
   [junit4] <<< JVM J1: EOF 

[...truncated 3 lines...]
   [junit4] ERROR: JVM J1 ended with an exception, command line: 
/home/jenkins/tools/java/64bit/jdk-12.0.1/bin/java -XX:+UseCompressedOops 
-XX:+UseSerialGC -XX:+HeapDumpOnOutOfMemoryError 
-XX:HeapDumpPath=/home/jenkins/workspace/Lucene-Solr-master-Linux/heapdumps -ea 
-esa --illegal-access=deny -Dtests.prefix=tests -Dtests.seed=462BA03A9A605C9B 
-Xmx512M -Dtests.iters= -Dtests.verbose=false -Dtests.infostream=false 
-Dtests.codec=random -Dtests.postingsformat=random 
-Dtests.docvaluesformat=random -Dtests.locale=random -Dtests.timezone=random 
-Dtests.directory=random -Dtests.linedocsfile=europarl.lines.txt.gz 
-Dtests.luceneMatchVersion=9.0.0 -Dtests.cleanthreads=perMethod 
-Djava.util.logging.config.file=/home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/tools/junit4/logging.properties
 -Dtests.nightly=false -Dtests.weekly=false -Dtests.monster=false 
-Dtests.slow=true -Dtests.asserts=true -Dtests.multiplier=3 -DtempDir=./temp 
-Djava.io.tmpdir=./temp 
-Dcommon.dir=/home/jenkins/workspace/Lucene-Solr-master-Linux/lucene 
-Dclover.db.dir=/home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/build/clover/db
 
-Djava.security.policy=/home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/tools/junit4/tests.policy
 -Dtests.LUCENE_VERSION=9.0.0 -Djetty.testMode=1 -Djetty.insecurerandom=1 
-Dsolr.directoryFactory=org.apache.solr.core.MockDirectoryFactory 
-Djava.awt.headless=true -Djdk.map.althashing.threshold=0 
-Dtests.src.home=/home/jenkins/workspace/Lucene-Solr-master-Linux 
-Djava.security.egd=file:/dev/./urandom 
-Djunit4.childvm.cwd=/home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/build/backward-codecs/test/J1
 
-Djunit4.tempDir=/home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/build/backward-codecs/test/temp
 -Djunit4.childvm.id=1 -Djunit4.childvm.count=3 -Dfile.encoding=ISO-8859-1 
-Djava.security.manager=org.apache.lucene.util.TestSecurityManager 
-Dtests.filterstacks=true -Dtests.leaveTemporary=false -Dtests.badapples=false 
-classpath 

[jira] [Commented] (SOLR-13693) Use strongly-typed setters for cache parameters

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-13693:


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

SOLR-13693: Use strongly-typed setters for cache parameters.


> Use strongly-typed setters for cache parameters
> ---
>
> Key: SOLR-13693
> URL: https://issues.apache.org/jira/browse/SOLR-13693
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 8.3
>Reporter: Andrzej Bialecki 
>Assignee: Andrzej Bialecki 
>Priority: Major
> Fix For: 8.3
>
> Attachments: SOLR-13693.patch
>
>
> SOLR-13558 added ability to modify cache parameters on the fly. It uses an 
> API similar to the originally proposed API in SOLR-13579. After several 
> iterations of that patch it became clear that the originally proposed 
> weakly-typed API should be replaced with a strongly-typed one.
> Since it's a new API in 8.3 there are no back-compat considerations.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Created] (SOLR-13695) SPLITSHARD (link), followed by DELETESHARD of parent shard causes data loss

[Ishan Chattopadhyaya (JIRA)]

Ishan Chattopadhyaya created SOLR-13695:
---

 Summary: SPLITSHARD (link), followed by DELETESHARD of parent 
shard causes data loss
 Key: SOLR-13695
 URL: https://issues.apache.org/jira/browse/SOLR-13695
 Project: Solr
  Issue Type: Improvement
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Ishan Chattopadhyaya
Assignee: Ishan Chattopadhyaya


One of my clients experienced data loss with the following sequence of 
operations:
1) SPLITSHARD with method as "link".
2) DELETESHARD of the parent (inactive) shard.
3) Query for documents in the subshards, seems like both subshards have 0 
documents.

Proposing a fix (after offline discussion with [~noble.paul]) based on running 
FORCEMERGE after SPLITSHARD (such that segments are rewritten), and not letting 
DELETESHARD delete the data directory until the FORCEMERGE operations finish.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Commented] (SOLR-13693) Use strongly-typed setters for cache parameters

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-13693:


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

SOLR-13693: Use strongly-typed setters for cache parameters.


> Use strongly-typed setters for cache parameters
> ---
>
> Key: SOLR-13693
> URL: https://issues.apache.org/jira/browse/SOLR-13693
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 8.3
>Reporter: Andrzej Bialecki 
>Assignee: Andrzej Bialecki 
>Priority: Major
> Fix For: 8.3
>
> Attachments: SOLR-13693.patch
>
>
> SOLR-13558 added ability to modify cache parameters on the fly. It uses an 
> API similar to the originally proposed API in SOLR-13579. After several 
> iterations of that patch it became clear that the originally proposed 
> weakly-typed API should be replaced with a strongly-typed one.
> Since it's a new API in 8.3 there are no back-compat considerations.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Closed] (SOLR-9894) Tokenizer work randomly

[Alexandre Rafalovitch (JIRA)]

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

Alexandre Rafalovitch closed SOLR-9894.
---

> Tokenizer work randomly
> ---
>
> Key: SOLR-9894
> URL: https://issues.apache.org/jira/browse/SOLR-9894
> Project: Solr
>  Issue Type: Bug
>  Components: query parsers
>Affects Versions: 6.2.1
> Environment: solrcloud 6.2.1(3 solr nodes)
> OS:linux
> RAM:8G
>Reporter: 王海涛
>Priority: Critical
>  Labels: patch
> Attachments: step1.png, step2.png, step3.png, step4.png
>
>
> my schema.xml has a fieldType as folow:
> 
>   
>class="org.wltea.analyzer.lucene.IKTokenizerFactory" useSmart="false"/>
>class="org.wltea.pinyin.solr5.PinyinTokenFilterFactory" pinyinAll="true" 
> minTermLength="2"/> 
>   
>   
>   
>class="org.wltea.analyzer.lucene.IKTokenizerFactory" useSmart="true"/>
>  
>   
>   
> Attention:
>   index tokenzier useSmart is false
>   query tokenzier useSmart is true
> But when I send query request with parameter q ,
> the query tokenziner sometimes useSmart equals true
> sometimes useSmart equal false.
> That is so terrible!
> I guess the problem may be caught by tokenizer cache.
> when I query ,the tokenizer should use true as the useSmart's value,
> but it had cache the wrong tokenizer result which created by indexWriter who 
> use false as useSmart's value.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Commented] (SOLR-13693) Use strongly-typed setters for cache parameters

[Lucene/Solr QA (JIRA)]

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

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

| (/) *{color:green}+1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green}  0m 
 0s{color} | {color:green} The patch appears to include 3 new or modified test 
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  2m  
9s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  2m  
0s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green}  2m  
0s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Release audit (RAT) {color} | 
{color:green}  2m  0s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Check forbidden APIs {color} | 
{color:green}  2m  0s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Validate source patterns {color} | 
{color:green}  2m  0s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 31m 
29s{color} | {color:green} core in the patch passed. {color} |
| {color:black}{color} | {color:black} {color} | {color:black} 38m 48s{color} | 
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | SOLR-13693 |
| JIRA Patch URL | 
https://issues.apache.org/jira/secure/attachment/12977595/SOLR-13693.patch |
| Optional Tests |  compile  javac  unit  ratsources  checkforbiddenapis  
validatesourcepatterns  |
| uname | Linux lucene1-us-west 4.15.0-54-generic #58-Ubuntu SMP Mon Jun 24 
10:55:24 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | ant |
| Personality | 
/home/jenkins/jenkins-slave/workspace/PreCommit-SOLR-Build/sourcedir/dev-tools/test-patch/lucene-solr-yetus-personality.sh
 |
| git revision | master / cdeb294236 |
| ant | version: Apache Ant(TM) version 1.10.5 compiled on March 28 2019 |
| Default Java | LTS |
|  Test Results | 
https://builds.apache.org/job/PreCommit-SOLR-Build/530/testReport/ |
| modules | C: solr solr/core U: solr |
| Console output | 
https://builds.apache.org/job/PreCommit-SOLR-Build/530/console |
| Powered by | Apache Yetus 0.7.0   http://yetus.apache.org |


This message was automatically generated.



> Use strongly-typed setters for cache parameters
> ---
>
> Key: SOLR-13693
> URL: https://issues.apache.org/jira/browse/SOLR-13693
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 8.3
>Reporter: Andrzej Bialecki 
>Assignee: Andrzej Bialecki 
>Priority: Major
> Fix For: 8.3
>
> Attachments: SOLR-13693.patch
>
>
> SOLR-13558 added ability to modify cache parameters on the fly. It uses an 
> API similar to the originally proposed API in SOLR-13579. After several 
> iterations of that patch it became clear that the originally proposed 
> weakly-typed API should be replaced with a strongly-typed one.
> Since it's a new API in 8.3 there are no back-compat considerations.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Commented] (SOLR-13663) XML Query Parser to Support SpanPositionRangeQuery

[Lucene/Solr QA (JIRA)]

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

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

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


This message was automatically generated.



> XML Query Parser to Support SpanPositionRangeQuery
> --
>
> Key: SOLR-13663
> URL: https://issues.apache.org/jira/browse/SOLR-13663
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: query parsers
>Affects Versions: 8.2
>Reporter: Alessandro Benedetti
>Priority: Major
> Attachments: SOLR-13663.patch, SOLR-13663.patch
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> Currently the XML Query Parser support a vast array of span queries, 
> including the SpanFirstQuery, but it doesn't support the generic 
> SpanPositionRangeQuery.
> < SpanPositionRange start="2" end="3">
>  prejudice
>  
>  
> Scope of this issue is to introduce the related builder and allow the 
> possibility to build such queries.
>  



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[GitHub] [lucene-solr] s1monw commented on issue #758: LUCENE-8833: Add a #load() method to IndexInput to allow preloading file content into physical memory

[GitBox]

s1monw commented on issue #758: LUCENE-8833: Add a #load() method to IndexInput 
to allow preloading file content into physical memory
URL: https://github.com/apache/lucene-solr/pull/758#issuecomment-521222121
 
 
   ping @uschindler again


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-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-13452:


Commit 78427be5e617704aed756e1ea7d5306f161ffc22 in lucene-solr's branch 
refs/heads/jira/SOLR-13452_gradle_5 from Mark Robert Miller
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=78427be ]

SOLR-13452: Fix JdepsReport method call.


> Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
> -
>
> Key: SOLR-13452
> URL: https://issues.apache.org/jira/browse/SOLR-13452
> Project: Solr
>  Issue Type: Improvement
>  Components: Build
>Reporter: Mark Miller
>Assignee: Mark Miller
>Priority: Major
> Fix For: master (9.0)
>
> Attachments: gradle-build.pdf
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> I took some things from the great work that Dat did in 
> [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a 
> little further.
>  
> When working with gradle in sub modules directly, I recommend 
> [https://github.com/dougborg/gdub]
> This gradle branch uses the following plugin for version locking, version 
> configuration and version consistency across modules: 
> [https://github.com/palantir/gradle-consistent-versions]
>  
> https://github.com/apache/lucene-solr/tree/jira/SOLR-13452_gradle_5



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[JENKINS] Lucene-Solr-8.x-Windows (64bit/jdk-11.0.3) - Build # 399 - Still unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-8.x-Windows/399/
Java: 64bit/jdk-11.0.3 -XX:-UseCompressedOops -XX:+UseParallelGC

7 tests failed.
FAILED:  
org.apache.solr.cloud.LegacyCloudClusterPropTest.testCreateCollectionSwitchLegacyCloud

Error Message:
IOException occurred when talking to server at: https://127.0.0.1:51164/solr

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: IOException occurred when 
talking to server at: https://127.0.0.1:51164/solr
at 
__randomizedtesting.SeedInfo.seed([C98C58AE5B758C23:188BAA2BFF7A0711]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:670)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:262)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:245)
at 
org.apache.solr.client.solrj.impl.LBSolrClient.doRequest(LBSolrClient.java:368)
at 
org.apache.solr.client.solrj.impl.LBSolrClient.request(LBSolrClient.java:296)
at 
org.apache.solr.client.solrj.impl.BaseCloudSolrClient.sendRequest(BaseCloudSolrClient.java:1128)
at 
org.apache.solr.client.solrj.impl.BaseCloudSolrClient.requestWithRetryOnStaleState(BaseCloudSolrClient.java:897)
at 
org.apache.solr.client.solrj.impl.BaseCloudSolrClient.request(BaseCloudSolrClient.java:829)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:211)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:228)
at 
org.apache.solr.cloud.MiniSolrCloudCluster.deleteAllCollections(MiniSolrCloudCluster.java:547)
at 
org.apache.solr.cloud.LegacyCloudClusterPropTest.afterTest(LegacyCloudClusterPropTest.java:58)
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$10.evaluate(RandomizedRunner.java:996)
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 

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

[Apache Jenkins Server]

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

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

Error Message:
Timeout occurred while waiting response from server at: http://127.0.0.1:35566

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: Timeout occurred while 
waiting response from server at: http://127.0.0.1:35566
at 
__randomizedtesting.SeedInfo.seed([A5ED0AF2DD8E5802:2DB93528737235FA]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:667)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:262)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:245)
at 
org.apache.solr.client.solrj.impl.LBSolrClient.doRequest(LBSolrClient.java:368)
at 
org.apache.solr.client.solrj.impl.LBSolrClient.request(LBSolrClient.java:296)
at 
org.apache.solr.client.solrj.impl.BaseCloudSolrClient.sendRequest(BaseCloudSolrClient.java:1128)
at 
org.apache.solr.client.solrj.impl.BaseCloudSolrClient.requestWithRetryOnStaleState(BaseCloudSolrClient.java:897)
at 
org.apache.solr.client.solrj.impl.BaseCloudSolrClient.request(BaseCloudSolrClient.java:829)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:211)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:228)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.createServers(AbstractFullDistribZkTestBase.java:338)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:1080)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:1054)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:947)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 

[jira] [Commented] (SOLR-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-13452:


Commit b6adfcbc3d9737f4d5d59dccd4808722682f442a in lucene-solr's branch 
refs/heads/jira/SOLR-13452_gradle_5 from Mark Robert Miller
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=b6adfcb ]

SOLR-13452: Enable the test security manager and add some more missing sys 
props for setting up tests.


> Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
> -
>
> Key: SOLR-13452
> URL: https://issues.apache.org/jira/browse/SOLR-13452
> Project: Solr
>  Issue Type: Improvement
>  Components: Build
>Reporter: Mark Miller
>Assignee: Mark Miller
>Priority: Major
> Fix For: master (9.0)
>
> Attachments: gradle-build.pdf
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> I took some things from the great work that Dat did in 
> [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a 
> little further.
>  
> When working with gradle in sub modules directly, I recommend 
> [https://github.com/dougborg/gdub]
> This gradle branch uses the following plugin for version locking, version 
> configuration and version consistency across modules: 
> [https://github.com/palantir/gradle-consistent-versions]
>  
> https://github.com/apache/lucene-solr/tree/jira/SOLR-13452_gradle_5



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Updated] (SOLR-13693) Use strongly-typed setters for cache parameters

[Andrzej Bialecki (JIRA)]

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

Andrzej Bialecki  updated SOLR-13693:
-
Attachment: SOLR-13693.patch

> Use strongly-typed setters for cache parameters
> ---
>
> Key: SOLR-13693
> URL: https://issues.apache.org/jira/browse/SOLR-13693
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 8.3
>Reporter: Andrzej Bialecki 
>Assignee: Andrzej Bialecki 
>Priority: Major
> Fix For: 8.3
>
> Attachments: SOLR-13693.patch
>
>
> SOLR-13558 added ability to modify cache parameters on the fly. It uses an 
> API similar to the originally proposed API in SOLR-13579. After several 
> iterations of that patch it became clear that the originally proposed 
> weakly-typed API should be replaced with a strongly-typed one.
> Since it's a new API in 8.3 there are no back-compat considerations.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Updated] (SOLR-13693) Use strongly-typed setters for cache parameters

[Andrzej Bialecki (JIRA)]

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

Andrzej Bialecki  updated SOLR-13693:
-
Attachment: (was: SOLR-13693.patch)

> Use strongly-typed setters for cache parameters
> ---
>
> Key: SOLR-13693
> URL: https://issues.apache.org/jira/browse/SOLR-13693
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 8.3
>Reporter: Andrzej Bialecki 
>Assignee: Andrzej Bialecki 
>Priority: Major
> Fix For: 8.3
>
> Attachments: SOLR-13693.patch
>
>
> SOLR-13558 added ability to modify cache parameters on the fly. It uses an 
> API similar to the originally proposed API in SOLR-13579. After several 
> iterations of that patch it became clear that the originally proposed 
> weakly-typed API should be replaced with a strongly-typed one.
> Since it's a new API in 8.3 there are no back-compat considerations.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Updated] (SOLR-13663) XML Query Parser to Support SpanPositionRangeQuery

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev updated SOLR-13663:

Attachment: SOLR-13663.patch

> XML Query Parser to Support SpanPositionRangeQuery
> --
>
> Key: SOLR-13663
> URL: https://issues.apache.org/jira/browse/SOLR-13663
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: query parsers
>Affects Versions: 8.2
>Reporter: Alessandro Benedetti
>Priority: Major
> Attachments: SOLR-13663.patch, SOLR-13663.patch
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> Currently the XML Query Parser support a vast array of span queries, 
> including the SpanFirstQuery, but it doesn't support the generic 
> SpanPositionRangeQuery.
> < SpanPositionRange start="2" end="3">
>  prejudice
>  
>  
> Scope of this issue is to introduce the related builder and allow the 
> possibility to build such queries.
>  



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Commented] (LUCENE-8950) FieldComparators Should Not Maintain Implicit PQs

[Atri Sharma (JIRA)]

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

Atri Sharma commented on LUCENE-8950:
-

{quote}you would like to introduce a sub class of FieldComparator that hides 
the fact that it maintains an implicit PQ, and make simple comparators extend 
this sub class instead of FieldComparator directly?
{quote}
Yes, exactly.

 

Thanks for validating – I will work on a PR now.

> FieldComparators Should Not Maintain Implicit PQs
> -
>
> Key: LUCENE-8950
> URL: https://issues.apache.org/jira/browse/LUCENE-8950
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Atri Sharma
>Priority: Major
>
> While doing some perf tests, I realised that FieldComparators inherently 
> maintain implicit priority queues for maintaining the sorted order of 
> documents for the given sort order. This is wasteful especially in the case 
> of a multi feature sort order and a large number of hits requested.
>  
> We should change this to have FieldComparators maintain only the top and 
> bottom values, and use them as barriers to compare



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Commented] (LUCENE-8950) FieldComparators Should Not Maintain Implicit PQs

[Adrien Grand (JIRA)]

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

Adrien Grand commented on LUCENE-8950:
--

OK I got confused with the notion of deprecation, which suggests to me that we 
need to find a replacement, but reading your last message, my understanding is 
that you would like to introduce a sub class of FieldComparator that hides the 
fact that it maintains an implicit PQ, and make simple comparators extend this 
sub class instead of FieldComparator directly? I would be +1 to giving it a try 
and making the change if the perf hit is negligible.

> FieldComparators Should Not Maintain Implicit PQs
> -
>
> Key: LUCENE-8950
> URL: https://issues.apache.org/jira/browse/LUCENE-8950
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Atri Sharma
>Priority: Major
>
> While doing some perf tests, I realised that FieldComparators inherently 
> maintain implicit priority queues for maintaining the sorted order of 
> documents for the given sort order. This is wasteful especially in the case 
> of a multi feature sort order and a large number of hits requested.
>  
> We should change this to have FieldComparators maintain only the top and 
> bottom values, and use them as barriers to compare



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Commented] (LUCENE-8947) Indexing fails with "too many tokens for field" when using custom term frequencies

[Adrien Grand (JIRA)]

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

Adrien Grand commented on LUCENE-8947:
--

Changing it to a long might be challenging for norms, since the current 
encoding relies on the fact that the length is an integer. Are you using norms, 
I guess not? Maybe we could skip computing the field length when norms are 
disabled?

> Indexing fails with "too many tokens for field" when using custom term 
> frequencies
> --
>
> Key: LUCENE-8947
> URL: https://issues.apache.org/jira/browse/LUCENE-8947
> Project: Lucene - Core
>  Issue Type: Improvement
>Affects Versions: 7.5
>Reporter: Michael McCandless
>Priority: Major
>
> We are using custom term frequencies (LUCENE-7854) to index per-token scoring 
> signals, however for one document that had many tokens and those tokens had 
> fairly large (~998,000) scoring signals, we hit this exception:
> {noformat}
> 2019-08-05T21:32:37,048 [ERROR] (LuceneIndexing-3-thread-3) 
> com.amazon.lucene.index.IndexGCRDocument: Failed to index doc: 
> java.lang.IllegalArgumentException: too many tokens for field "foobar"
> at 
> org.apache.lucene.index.DefaultIndexingChain$PerField.invert(DefaultIndexingChain.java:825)
> at 
> org.apache.lucene.index.DefaultIndexingChain.processField(DefaultIndexingChain.java:430)
> at 
> org.apache.lucene.index.DefaultIndexingChain.processDocument(DefaultIndexingChain.java:394)
> at 
> org.apache.lucene.index.DocumentsWriterPerThread.updateDocuments(DocumentsWriterPerThread.java:297)
> at 
> org.apache.lucene.index.DocumentsWriter.updateDocuments(DocumentsWriter.java:450)
> at org.apache.lucene.index.IndexWriter.updateDocuments(IndexWriter.java:1291)
> at org.apache.lucene.index.IndexWriter.addDocuments(IndexWriter.java:1264)
> {noformat}
> This is happening in this code in {{DefaultIndexingChain.java}}:
> {noformat}
>   try {
> invertState.length = Math.addExact(invertState.length, 
> invertState.termFreqAttribute.getTermFrequency());
>   } catch (ArithmeticException ae) {
> throw new IllegalArgumentException("too many tokens for field \"" + 
> field.name() + "\"");
>   }{noformat}
> Where Lucene is accumulating the total length (number of tokens) for the 
> field.  But total length doesn't really make sense if you are using custom 
> term frequencies to hold arbitrary scoring signals?  Or, maybe it does make 
> sense, if user is using this as simple boosting, but maybe we should allow 
> this length to be a {{long}}?



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Commented] (LUCENE-8950) FieldComparators Should Not Maintain Implicit PQs

[Atri Sharma (JIRA)]

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

Atri Sharma commented on LUCENE-8950:
-

{quote}This looks like a duplicate of LUCENE-8878?
{quote}
Not necessarily – 8878 targets refactoring the API to be simpler, whereas this 
Jira only targets removing the necessary condition that FieldComparators 
maintain their own priority queues. I believe this Jira compliments 8878.
{quote}I think all of us agree on the fact that it would be nice to have a 
simpler FieldComparator API. The challenge is that we don't want to trade too 
much efficiency. For instance the API you are proposing wouldn't work well with 
geo-distance sorting since it would require computing the actual distance for 
every new document, while the current implementation tries to be smart to first 
check a bounding box, and then compute a sort key that compares like the actual 
distance but is much cheaper to compute
{quote}
Agreed, that is precisely why I suggested deprecating compare (slot, slot) 
instead of removing it completely. The idea is that comparators that require 
access to an internal PQ for whatever reasons are free to do so, but it should 
not be mandatory, and future comparators should not take on this dependency 
without understanding the tradeoffs

> FieldComparators Should Not Maintain Implicit PQs
> -
>
> Key: LUCENE-8950
> URL: https://issues.apache.org/jira/browse/LUCENE-8950
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Atri Sharma
>Priority: Major
>
> While doing some perf tests, I realised that FieldComparators inherently 
> maintain implicit priority queues for maintaining the sorted order of 
> documents for the given sort order. This is wasteful especially in the case 
> of a multi feature sort order and a large number of hits requested.
>  
> We should change this to have FieldComparators maintain only the top and 
> bottom values, and use them as barriers to compare



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Commented] (LUCENE-8950) FieldComparators Should Not Maintain Implicit PQs

[Adrien Grand (JIRA)]

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

Adrien Grand commented on LUCENE-8950:
--

This looks like a duplicate of LUCENE-8878?

I think all of us agree on the fact that it would be nice to have a simpler 
FieldComparator API. The challenge is that we don't want to trade too much 
efficiency. For instance the API you are proposing wouldn't work well with 
geo-distance sorting since it would require computing the actual distance for 
every new document, while the current implementation tries to be smart to first 
check a bounding box, and then compute a sort key that compares like the actual 
distance but is much cheaper to compute (see discussion on LUCENE-8878 for more 
details).

> FieldComparators Should Not Maintain Implicit PQs
> -
>
> Key: LUCENE-8950
> URL: https://issues.apache.org/jira/browse/LUCENE-8950
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Atri Sharma
>Priority: Major
>
> While doing some perf tests, I realised that FieldComparators inherently 
> maintain implicit priority queues for maintaining the sorted order of 
> documents for the given sort order. This is wasteful especially in the case 
> of a multi feature sort order and a large number of hits requested.
>  
> We should change this to have FieldComparators maintain only the top and 
> bottom values, and use them as barriers to compare



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[JENKINS-EA] Lucene-Solr-master-Windows (64bit/jdk-14-ea+9) - Build # 8086 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/8086/
Java: 64bit/jdk-14-ea+9 -XX:+UseCompressedOops -XX:+UseG1GC

17 tests failed.
FAILED:  
org.apache.solr.ltr.store.rest.TestModelManagerPersistence.testWrapperModelPersistence

Error Message:
An established connection was aborted by the software in your host machine

Stack Trace:
javax.net.ssl.SSLException: An established connection was aborted by the 
software in your host machine
at 
__randomizedtesting.SeedInfo.seed([EE83440A6D3AB7C0:9BE937D4D2C6CE85]:0)
at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:127)
at 
java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:324)
at 
java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:267)
at 
java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:262)
at 
java.base/sun.security.ssl.SSLSocketImpl.handleException(SSLSocketImpl.java:1652)
at 
java.base/sun.security.ssl.SSLSocketImpl$AppInputStream.read(SSLSocketImpl.java:1038)
at 
org.apache.http.impl.io.SessionInputBufferImpl.streamRead(SessionInputBufferImpl.java:137)
at 
org.apache.http.impl.io.SessionInputBufferImpl.fillBuffer(SessionInputBufferImpl.java:153)
at 
org.apache.http.impl.io.SessionInputBufferImpl.readLine(SessionInputBufferImpl.java:282)
at 
org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:138)
at 
org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:56)
at 
org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:259)
at 
org.apache.http.impl.DefaultBHttpClientConnection.receiveResponseHeader(DefaultBHttpClientConnection.java:163)
at 
org.apache.http.impl.conn.CPoolProxy.receiveResponseHeader(CPoolProxy.java:165)
at 
org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequestExecutor.java:273)
at 
org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:125)
at 
org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:272)
at 
org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:185)
at org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:89)
at 
org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:110)
at 
org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:185)
at 
org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:83)
at 
org.apache.solr.util.RestTestHarness.getResponse(RestTestHarness.java:215)
at org.apache.solr.util.RestTestHarness.query(RestTestHarness.java:107)
at org.apache.solr.util.RestTestBase.assertJQ(RestTestBase.java:226)
at org.apache.solr.util.RestTestBase.assertJQ(RestTestBase.java:192)
at 
org.apache.solr.ltr.store.rest.TestModelManagerPersistence.doWrapperModelPersistenceChecks(TestModelManagerPersistence.java:202)
at 
org.apache.solr.ltr.store.rest.TestModelManagerPersistence.testWrapperModelPersistence(TestModelManagerPersistence.java:255)
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:565)
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 

[jira] [Commented] (SOLR-13663) XML Query Parser to Support SpanPositionRangeQuery

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev commented on SOLR-13663:
-

It touches only Lucene codebase, shouldn't it go into Lucene project? 

> XML Query Parser to Support SpanPositionRangeQuery
> --
>
> Key: SOLR-13663
> URL: https://issues.apache.org/jira/browse/SOLR-13663
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: query parsers
>Affects Versions: 8.2
>Reporter: Alessandro Benedetti
>Priority: Major
> Attachments: SOLR-13663.patch
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> Currently the XML Query Parser support a vast array of span queries, 
> including the SpanFirstQuery, but it doesn't support the generic 
> SpanPositionRangeQuery.
> < SpanPositionRange start="2" end="3">
>  prejudice
>  
>  
> Scope of this issue is to introduce the related builder and allow the 
> possibility to build such queries.
>  



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Commented] (LUCENE-8951) Create issues@ and builds@ lists and update notifications

[JIRA]

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

Jan Høydahl commented on LUCENE-8951:
-

List of addresses that should be whitelisted for posting (please fill in) :
{noformat}
issues@:
g...@apache.org
j...@apache.org

builds@:
jenk...@builds.apache.org
jenk...@thetaphi.de{noformat}

> Create issues@ and builds@ lists and update notifications
> -
>
> Key: LUCENE-8951
> URL: https://issues.apache.org/jira/browse/LUCENE-8951
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>Priority: Major
>
> Issue to plan and execute decision from dev mailing list 
> [https://lists.apache.org/thread.html/762d72a9045642dc488dc7a2fd0a525707e5fa5671ac0648a3604c9b@%3Cdev.lucene.apache.org%3E]
>  # Create mailing lists as an announce only list
>  # Subscribe all emails that will be allowed to post
>  # Update websites with info about the new lists
>  # Announce to dev@ list that the change will happen
>  # Modify Jira and Github bots to post to issues@ list instead of dev@
>  # Modify Jenkins (including Policeman and other) to post to builds@
>  # Announce to dev@ list that the change is effective



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Assigned] (LUCENE-8951) Create issues@ and builds@ lists and update notifications

[JIRA]

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

Jan Høydahl reassigned LUCENE-8951:
---

Assignee: Jan Høydahl

> Create issues@ and builds@ lists and update notifications
> -
>
> Key: LUCENE-8951
> URL: https://issues.apache.org/jira/browse/LUCENE-8951
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>Priority: Major
>
> Issue to plan and execute decision from dev mailing list 
> [https://lists.apache.org/thread.html/762d72a9045642dc488dc7a2fd0a525707e5fa5671ac0648a3604c9b@%3Cdev.lucene.apache.org%3E]
>  # Create mailing lists as an announce only list
>  # Subscribe all emails that will be allowed to post
>  # Update websites with info about the new lists
>  # Announce to dev@ list that the change will happen
>  # Modify Jira and Github bots to post to issues@ list instead of dev@
>  # Modify Jenkins (including Policeman and other) to post to builds@
>  # Announce to dev@ list that the change is effective



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Commented] (LUCENE-8951) Create issues@ and builds@ lists and update notifications

[JIRA]

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

Jan Høydahl commented on LUCENE-8951:
-

I'm starting with step 1. Who wants to be moderators for the lists? There will 
be no real message moderation but you will have karma for whitelisting posters 
like bots etc.

> Create issues@ and builds@ lists and update notifications
> -
>
> Key: LUCENE-8951
> URL: https://issues.apache.org/jira/browse/LUCENE-8951
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Jan Høydahl
>Priority: Major
>
> Issue to plan and execute decision from dev mailing list 
> [https://lists.apache.org/thread.html/762d72a9045642dc488dc7a2fd0a525707e5fa5671ac0648a3604c9b@%3Cdev.lucene.apache.org%3E]
>  # Create mailing lists as an announce only list
>  # Subscribe all emails that will be allowed to post
>  # Update websites with info about the new lists
>  # Announce to dev@ list that the change will happen
>  # Modify Jira and Github bots to post to issues@ list instead of dev@
>  # Modify Jenkins (including Policeman and other) to post to builds@
>  # Announce to dev@ list that the change is effective



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[JENKINS] Lucene-Solr-NightlyTests-master - Build # 1929 - Still Unstable

[Apache Jenkins Server]

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

1 tests failed.
FAILED:  
org.apache.solr.cloud.cdcr.CdcrBootstrapTest.testBootstrapWithMultipleReplicas

Error Message:
leader followers didnt' match

Stack Trace:
java.lang.AssertionError: leader followers didnt' match
at 
__randomizedtesting.SeedInfo.seed([96A238940BD62894:5F369476909ED6]:0)
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.assertTrue(Assert.java:41)
at 
org.apache.solr.cloud.cdcr.CdcrBootstrapTest.testBootstrapWithMultipleReplicas(CdcrBootstrapTest.java:286)
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 
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:834)




Build Log:
[...truncated 13869 lines...]
   [junit4] Suite: org.apache.solr.cloud.cdcr.CdcrBootstrapTest
   [junit4]   2> 831027 INFO  
(SUITE-CdcrBootstrapTest-seed#[96A238940BD62894]-worker) [ ] 
o.a.s.SolrTestCaseJ4 Created dataDir: 

[jira] [Created] (LUCENE-8951) Create issues@ and builds@ lists and update notifications

[JIRA]

Jan Høydahl created LUCENE-8951:
---

 Summary: Create issues@ and builds@ lists and update notifications
 Key: LUCENE-8951
 URL: https://issues.apache.org/jira/browse/LUCENE-8951
 Project: Lucene - Core
  Issue Type: Task
Reporter: Jan Høydahl


Issue to plan and execute decision from dev mailing list 
[https://lists.apache.org/thread.html/762d72a9045642dc488dc7a2fd0a525707e5fa5671ac0648a3604c9b@%3Cdev.lucene.apache.org%3E]
 # Create mailing lists as an announce only list
 # Subscribe all emails that will be allowed to post
 # Update websites with info about the new lists
 # Announce to dev@ list that the change will happen
 # Modify Jira and Github bots to post to issues@ list instead of dev@
 # Modify Jenkins (including Policeman and other) to post to builds@
 # Announce to dev@ list that the change is effective



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

Re: Separate dev mailing list for automated mails?

[Jan Høydahl]

Ok, time to execute on this, please engage in 
https://issues.apache.org/jira/browse/LUCENE-8951 if you want to contribute!

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

> 9. aug. 2019 kl. 01:08 skrev Namgyu Kim :
> 
> +1 for issues@ and builds@
> Thanks Jan :)
> 
> 
> 2019년 8월 9일 (금) 오전 3:02, Jan Høydahl  >님이 작성:
> We already have commits@, so let’s go with issues@ and builds@
> 
> Jan Høydahl
> 
> 8. aug. 2019 kl. 18:32 skrev Namgyu Kim  >:
> 
>> +1 to Jan's idea :D
>> I think it's better to split the mailing list.
>> 
>> But I have a little opinion about the name.
>> Which one is better, the singular(build-issue) or the plural(builds-issues)?
>> Personally, "build-issue" looks better because names of the our mailing list 
>> are used as a singular. (not jave-users but java-user)
>> 
>> What do you think about this?
>> 
>> 2019년 8월 8일 (목) 오후 9:42, Jan Høydahl > >님이 작성:
>> I'll let this email topic run over the weekend to attract more eyeballs. 
>> Even if it's not a VOTE thread, feel free to add your +1 or -1's, and if 
>> others also seem in favour of this idea then I'll start working on it next 
>> week. To sum up what I believe to be the current consensus:
>> 
>> A new issues@ list (announce only) for JIRA and Github notifications
>> A new build@ list (announce only) for Jenkins notifications
>> 
>> Whether [Created|Resolved] mails for JIRA/PR should also go to Dev list is 
>> still an open question. To help decide, here's the expected volume for those 
>> (from reporter.apache.org :
>> 357 issues opened in JIRA, past quarter, 270 issues closed in JIRA, past 
>> quarter, 155 PRs opened on GitHub, past quarter, 143 PRs closed on GitHub, 
>> past quarter
>> …which sums up to about 300/month or 10/day.
>> An alternative to this could be some script that runs once a day and emits 
>> ONE email per day with a digest with links to new/closed JIRAs and PRs last 
>> 24h.
>> 
>> --
>> Jan Høydahl, search solution architect
>> Cominvent AS - www.cominvent.com 
>> 
>>> 8. aug. 2019 kl. 14:15 skrev Erick Erickson >> >:
>>> 
>>> +1 to Jan’s idea of the bot-originated lists be announce only…..
>>> 
>>> Personally I’ve been able to make some sense out of the messages by
>>> 
>>> 1> switching to the mac mail client (not an option for others, I know). It 
>>> threads pretty well and for those topics where there are 10 replies I only 
>>> have to glance at one to see if I’m interested enough to pursue.
>>> 
>>> 2> I have a _lot_ of filters set up.
>>> 
>>> I have to admit that one of the motivations for moving to the mail program 
>>> on the mac was because gmail’s filters are such a disaster. Or I just 
>>> totally missed how to configure them. For instance, changing the order of 
>>> execution was impossible, so when I wanted to make a new filter execute 
>>> first I had to redefine the entire list…..
>>> 
 On Aug 8, 2019, at 5:31 AM, Alexandre Rafalovitch >>> > wrote:
 
 I apply the following (gmail) rules, just in case it helps somebody.
 With this combination, I am able to track human conversations
 reasonably well.
 
 Human conversation:
 Matches: from:(-g...@apache.org ) 
 subject:(-[jira]) list:>>> >
 Do this: Skip Inbox, Apply label "ML/Lucene-dev"
 
 All JIRA issues, regardless of other filters
 Matches: subject:([jira] {SOLR- LUCENE-}) list:"dev.lucene.apache.org 
 "
 Do this: Skip Inbox, Apply label "ML/Lucene-jira", Never send it to Spam
 
 New JIRA issues (that I check to see if I want to track/comment before
 I remove the label)
 Matches: subject:("[Created]") list:(>>> >)
 Do this: Skip Inbox, Apply label "ML/Lucene-Jira-Interesting", Never
 send it to Spam
 
 Updates on JIRA issues from me (I already know them)
 Matches: from:(Alexandre Rafalovitch (JIRA) >>> >)
 Do this: Skip Inbox, Mark as read, Star it, Apply label "Solr-Jiras"
 
 All JIRA issues I am involved in or marked to track
 Matches: from:(j...@apache.org ) 
 to:(arafa...@gmail.com )
 Do this: Skip Inbox, Apply label "Solr-Jiras"
 
 Delete JENKINS stuff, as I am currently not contributing
 Matches: subject:([JENKINS]) list:(>>> >)
 Do this: Delete it
 
 Git emails that I am not really tracking right now, but do keep
 Matches: from:(g...@apache.org ) 
 list:(http://dev.lucene.apache.org/>>)
 Do this: Skip Inbox, Mark as read, Apply label "ML/Lucene-GitBox",
 Never send it to Spam
 
 Moderation emails I help 

[jira] [Commented] (SOLR-13500) Vector Search with Solr

[Dr Oleg Savrasov (JIRA)]

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

Dr Oleg Savrasov commented on SOLR-13500:
-

At first glance this looks like duplicate of 
https://issues.apache.org/jira/browse/SOLR-12890

> Vector Search with Solr
> ---
>
> Key: SOLR-13500
> URL: https://issues.apache.org/jira/browse/SOLR-13500
> Project: Solr
>  Issue Type: New Feature
>Reporter: Dr Oleg Savrasov
>Priority: Major
>
> In machine learning problems we usually need to find nearest neighbors in 
> dense high dimensional vector space. Often, this retrieval had to be 
> augmented with traditional Boolean retrieval.
> While no efficient KNN implementation is available in Solr yet, in practice 
> people are using brute-force vector distance sorting after Boolean retrieval 
> limits number of candidate vectors.
> It's proposed to add a clear way to implement such a solution with Solr.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Commented] (SOLR-13647) default solr.in.sh contains uncommented lines

[JIRA]

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

Jan Høydahl commented on SOLR-13647:


Announcement published to solr-user@ and website news section

> default solr.in.sh contains uncommented lines
> -
>
> Key: SOLR-13647
> URL: https://issues.apache.org/jira/browse/SOLR-13647
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 8.1.1
>Reporter: John
>Assignee: Jan Høydahl
>Priority: Trivial
> Fix For: 8.3
>
>  Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
> default version of this file should be completely commented
> ENABLE_REMOTE_JMX_OPTS had defaults



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Commented] (LUCENE-8950) FieldComparators Should Not Maintain Implicit PQs

[Atri Sharma (JIRA)]

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

Atri Sharma commented on LUCENE-8950:
-

I confess I do not have a very clean idea as to how this can be implemented: 
the typical usages of FieldComparator mandate that the user maintain a list of 
slots into the FieldComparator, which can implicitly be as bad in terms of size 
as the queue itself. FieldComparator provides a convenient API to allow 
comparisons between two values of the type maintained in the queue, which can 
form the basis of this observation.

 

Here is the first cut of proposal that I have in mind:

1) Deprecate compare(slot, slot) so that new implementations do not depend on 
this method, but rather use compare(T val, T val).

2) Start with some comparators (Numeric comparators?), get rid of the implicit 
priority queue and make the user maintain those values.

3) Make Numeric comparators track only the top and bottom values, as needed.

 

Note that I am treating NumericComparators as the starting point/example, but 
the approach should extend for other comparators as well.

 

With [https://github.com/apache/lucene-solr/pull/831,] getting values out of 
leaf comparators should be easy, so the logical step after this PR is to depend 
on compare (val, val) more than we rely on compare (slot, slot).

 

Happy to receive feedback and alternate proposals

> FieldComparators Should Not Maintain Implicit PQs
> -
>
> Key: LUCENE-8950
> URL: https://issues.apache.org/jira/browse/LUCENE-8950
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Atri Sharma
>Priority: Major
>
> While doing some perf tests, I realised that FieldComparators inherently 
> maintain implicit priority queues for maintaining the sorted order of 
> documents for the given sort order. This is wasteful especially in the case 
> of a multi feature sort order and a large number of hits requested.
>  
> We should change this to have FieldComparators maintain only the top and 
> bottom values, and use them as barriers to compare



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[GitHub] [lucene-solr] sigram commented on a change in pull request #825: SOLR-13677 All Metrics Gauges should be unregistered by the objects that registered them

[GitBox]

sigram commented on a change in pull request #825: SOLR-13677 All Metrics 
Gauges should be unregistered by the objects that registered them
URL: https://github.com/apache/lucene-solr/pull/825#discussion_r313738188
 
 

 ##
 File path: solr/core/src/java/org/apache/solr/metrics/SolrMetricProducer.java
 ##
 @@ -19,17 +19,58 @@
 /**
  * Used by objects that expose metrics through {@link SolrCoreMetricManager}.
  */
-public interface SolrMetricProducer {
+public interface SolrMetricProducer extends AutoCloseable {
+
+  /**
+   * Unique metric name is in the format of A/B/C
+   * A is the parent of B is the parent of C and so on.
+   * If object "B" is unregistered , C also must get unregistered.
+   * If object "A" is unregistered ,  B , C also must get unregistered.
+   *
+   * @param parentName
+   */
+  default String getUniqueMetricTag(String parentName) {
+String name = getClass().getSimpleName() + "@" + 
Integer.toHexString(hashCode());
+return parentName == null ?
+name :
+parentName + "/" + name;
+  }
+
+  default void close() throws Exception{
+
+  }
+
 
   /**
* Initializes metrics specific to this producer
-   * @param manager an instance of {@link SolrMetricManager}
+   *
+   * @param manager  an instance of {@link SolrMetricManager}
* @param registry registry name where metrics are registered
-   * @param tag a symbolic tag that represents this instance of the producer,
-   * or a group of related instances that have the same life-cycle. This tag is
-   * used when managing life-cycle of some metrics and is set when
-   * {@link #initializeMetrics(SolrMetricManager, String, String, String)} is 
called.
-   * @param scope scope of the metrics (eg. handler name) to separate metrics 
of
+   * @param tag  a symbolic tag that represents this instance of the 
producer,
+   * or a group of related instances that have the same 
life-cycle. This tag is
+   * used when managing life-cycle of some metrics and is set 
when
+   * {@link #initializeMetrics(SolrMetricManager, String, 
String, String)} is called.
+   * @param scopescope of the metrics (eg. handler name) to separate 
metrics of
*/
   void initializeMetrics(SolrMetricManager manager, String registry, String 
tag, String scope);
+
+  class MetricsInfo {
 
 Review comment:
   Maybe `MetricsContext`?


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

[GitHub] [lucene-solr] sigram commented on a change in pull request #825: SOLR-13677 All Metrics Gauges should be unregistered by the objects that registered them

[GitBox]

sigram commented on a change in pull request #825: SOLR-13677 All Metrics 
Gauges should be unregistered by the objects that registered them
URL: https://github.com/apache/lucene-solr/pull/825#discussion_r313737953
 
 

 ##
 File path: solr/core/src/java/org/apache/solr/handler/RequestHandlerBase.java
 ##
 @@ -145,8 +145,14 @@ public void init(NamedList args) {
 
   }
 
+  protected MetricsInfo metricsInfo;
+
+
   @Override
   public void initializeMetrics(SolrMetricManager manager, String 
registryName, String tag, final String scope) {
+metricsInfo = new MetricsInfo(manager, registryName, 
getUniqueMetricTag(tag)) ;
+tag = metricsInfo.getTag();
 
 Review comment:
   We can change it in 9.0 - how about this for 8x, in `SolrMetricProducer`:
   ```
   default void initializeMetrics(MetricsInfo info, scope) {
 initializeMetrics(info.manager, info.registry, info.tag, scope);
   }
   ```
   Then we can change the components that we know about to use the new API (and 
create the tags not in the component itself but in the parent), and still 
preserve back-compat for third-party components.


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] [Updated] (SOLR-13694) IndexSizeEstimator NullPointerException

[Andrzej Bialecki (JIRA)]

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

Andrzej Bialecki  updated SOLR-13694:
-
Attachment: (was: SOLR-13694.patch)

> IndexSizeEstimator NullPointerException
> ---
>
> Key: SOLR-13694
> URL: https://issues.apache.org/jira/browse/SOLR-13694
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Assignee: Andrzej Bialecki 
>Priority: Major
> Attachments: SOLR-13694.patch
>
>
> Jenkins found a reproducible seed for trigging an NPE in 
> IndexSizeEstimatorTest
> Based on a little experimental tracing i did, this might be a real bug in 
> IndexSizeEstimator? ... it's calling close on StoredFieldsReader instances it 
> gets from the CodecReader -- but AFAICT from the docs/code i'm not certain if 
> it should be doing this.  It appears the expectation is that this is direct 
> access to the internal state, that will automatically be closed when the 
> CodecReader is closed.
> ie: IndexSizeEstimator is closing StoredFieldsReader pre-maturely, causing it 
> to be unusbale on the next iteration.
> (I didn't dig in far enough to guess if there are other places in the 
> IndexSizeEstimator code that are closing CodecReader internals prematurely as 
> well, or just in this situation ... it's also not clear if this only causes 
> failures because this seed uses SimpleTextCodec, and other codecs are more 
> forgiving -- or if something else about the index(es) generated for this seed 
> are what cause the problem to manifest)
> http://fucit.org/solr-jenkins-reports/job-data/apache/Lucene-Solr-NightlyTests-master/1928
> {noformat}
> hossman@tray:~/lucene/dev/solr/core [j11] [master] $ git rev-parse HEAD
> 0291db44bc8e092f7cb2f577f0ac8ab6fa6a5fd7
> hossman@tray:~/lucene/dev/solr/core [j11] [master] $ ant test  
> -Dtestcase=IndexSizeEstimatorTest -Dtests.method=testEstimator 
> -Dtests.seed=23F60434E13D8FD4 -Dtests.multiplier=2 -Dtests.nightly=true 
> -Dtests.slow=true  -Dtests.locale=eo -Dtests.timezone=Atlantic/Madeira 
> -Dtests.asserts=true -Dtests.file.encoding=UTF-8
> ...
>[junit4]   2> NOTE: reproduce with: ant test  
> -Dtestcase=IndexSizeEstimatorTest -Dtests.method=testEstimator 
> -Dtests.seed=23F60434E13D8FD4 -Dtests.multiplier=2 -Dtests.nightly=true 
> -Dtests.slow=true -Dtests.badapples=true -Dtests.locale=eo 
> -Dtests.timezone=Atlantic/Madeira -Dtests.asserts=true 
> -Dtests.file.encoding=UTF-8
>[junit4] ERROR   0.88s | IndexSizeEstimatorTest.testEstimator <<<
>[junit4]> Throwable #1: java.lang.NullPointerException
>[junit4]>at 
> __randomizedtesting.SeedInfo.seed([23F60434E13D8FD4:EC2B6B666D451E64]:0)
>[junit4]>at 
> org.apache.lucene.codecs.simpletext.SimpleTextStoredFieldsReader.visitDocument(SimpleTextStoredFieldsReader.java:109)
>[junit4]>at 
> org.apache.solr.handler.admin.IndexSizeEstimator.estimateStoredFields(IndexSizeEstimator.java:513)
>[junit4]>at 
> org.apache.solr.handler.admin.IndexSizeEstimator.estimate(IndexSizeEstimator.java:198)
>[junit4]>at 
> org.apache.solr.handler.admin.IndexSizeEstimatorTest.testEstimator(IndexSizeEstimatorTest.java:117)
>[junit4]>at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>[junit4]>at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>[junit4]>at 
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>[junit4]>at 
> java.base/java.lang.reflect.Method.invoke(Method.java:566)
>[junit4]>at java.base/java.lang.Thread.run(Thread.java:834)
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Updated] (SOLR-13694) IndexSizeEstimator NullPointerException

[Andrzej Bialecki (JIRA)]

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

Andrzej Bialecki  updated SOLR-13694:
-
Attachment: SOLR-13694.patch

> IndexSizeEstimator NullPointerException
> ---
>
> Key: SOLR-13694
> URL: https://issues.apache.org/jira/browse/SOLR-13694
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Assignee: Andrzej Bialecki 
>Priority: Major
> Attachments: SOLR-13694.patch
>
>
> Jenkins found a reproducible seed for trigging an NPE in 
> IndexSizeEstimatorTest
> Based on a little experimental tracing i did, this might be a real bug in 
> IndexSizeEstimator? ... it's calling close on StoredFieldsReader instances it 
> gets from the CodecReader -- but AFAICT from the docs/code i'm not certain if 
> it should be doing this.  It appears the expectation is that this is direct 
> access to the internal state, that will automatically be closed when the 
> CodecReader is closed.
> ie: IndexSizeEstimator is closing StoredFieldsReader pre-maturely, causing it 
> to be unusbale on the next iteration.
> (I didn't dig in far enough to guess if there are other places in the 
> IndexSizeEstimator code that are closing CodecReader internals prematurely as 
> well, or just in this situation ... it's also not clear if this only causes 
> failures because this seed uses SimpleTextCodec, and other codecs are more 
> forgiving -- or if something else about the index(es) generated for this seed 
> are what cause the problem to manifest)
> http://fucit.org/solr-jenkins-reports/job-data/apache/Lucene-Solr-NightlyTests-master/1928
> {noformat}
> hossman@tray:~/lucene/dev/solr/core [j11] [master] $ git rev-parse HEAD
> 0291db44bc8e092f7cb2f577f0ac8ab6fa6a5fd7
> hossman@tray:~/lucene/dev/solr/core [j11] [master] $ ant test  
> -Dtestcase=IndexSizeEstimatorTest -Dtests.method=testEstimator 
> -Dtests.seed=23F60434E13D8FD4 -Dtests.multiplier=2 -Dtests.nightly=true 
> -Dtests.slow=true  -Dtests.locale=eo -Dtests.timezone=Atlantic/Madeira 
> -Dtests.asserts=true -Dtests.file.encoding=UTF-8
> ...
>[junit4]   2> NOTE: reproduce with: ant test  
> -Dtestcase=IndexSizeEstimatorTest -Dtests.method=testEstimator 
> -Dtests.seed=23F60434E13D8FD4 -Dtests.multiplier=2 -Dtests.nightly=true 
> -Dtests.slow=true -Dtests.badapples=true -Dtests.locale=eo 
> -Dtests.timezone=Atlantic/Madeira -Dtests.asserts=true 
> -Dtests.file.encoding=UTF-8
>[junit4] ERROR   0.88s | IndexSizeEstimatorTest.testEstimator <<<
>[junit4]> Throwable #1: java.lang.NullPointerException
>[junit4]>at 
> __randomizedtesting.SeedInfo.seed([23F60434E13D8FD4:EC2B6B666D451E64]:0)
>[junit4]>at 
> org.apache.lucene.codecs.simpletext.SimpleTextStoredFieldsReader.visitDocument(SimpleTextStoredFieldsReader.java:109)
>[junit4]>at 
> org.apache.solr.handler.admin.IndexSizeEstimator.estimateStoredFields(IndexSizeEstimator.java:513)
>[junit4]>at 
> org.apache.solr.handler.admin.IndexSizeEstimator.estimate(IndexSizeEstimator.java:198)
>[junit4]>at 
> org.apache.solr.handler.admin.IndexSizeEstimatorTest.testEstimator(IndexSizeEstimatorTest.java:117)
>[junit4]>at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>[junit4]>at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>[junit4]>at 
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>[junit4]>at 
> java.base/java.lang.reflect.Method.invoke(Method.java:566)
>[junit4]>at java.base/java.lang.Thread.run(Thread.java:834)
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Comment Edited] (SOLR-13694) IndexSizeEstimator NullPointerException

[Andrzej Bialecki (JIRA)]

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

Andrzej Bialecki  edited comment on SOLR-13694 at 8/14/19 7:21 AM:
---

Indeed, it's a bug in {{IndexSizeEstimator}} - it appears that the 
{{StoredFieldsReader}} is not supposed to be closed other than from within 
CodecReader.close().

SimpleTextCodec / SimpleTextStoreFieldsReader doesn't override 
getMergeInstance(), which means it returns itself, unlike all other codecs 
which return a clone of the stream in a new instance of {{StoredFieldsReader}}.

Still, I'm not sure if the new instance should be closed? Closing a clone of a 
stream doesn't close the original stream so I _think_ that the merge instance, 
when different from the original, still should be closed.


was (Author: ab):
Indeed, it's a bug in {{IndexSizeEstimator}} - the {{StoredFieldsReader}} is 
not supposed to be closed other than from within CodecReader.close(). I'll fix 
it in a moment.

(SimpleTextCodec / SimpleTextStoreFieldsReader doesn't override 
getMergeInstance(), which means it returns itself, unlike all other codecs 
which return a clone).

> IndexSizeEstimator NullPointerException
> ---
>
> Key: SOLR-13694
> URL: https://issues.apache.org/jira/browse/SOLR-13694
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Assignee: Andrzej Bialecki 
>Priority: Major
> Attachments: SOLR-13694.patch
>
>
> Jenkins found a reproducible seed for trigging an NPE in 
> IndexSizeEstimatorTest
> Based on a little experimental tracing i did, this might be a real bug in 
> IndexSizeEstimator? ... it's calling close on StoredFieldsReader instances it 
> gets from the CodecReader -- but AFAICT from the docs/code i'm not certain if 
> it should be doing this.  It appears the expectation is that this is direct 
> access to the internal state, that will automatically be closed when the 
> CodecReader is closed.
> ie: IndexSizeEstimator is closing StoredFieldsReader pre-maturely, causing it 
> to be unusbale on the next iteration.
> (I didn't dig in far enough to guess if there are other places in the 
> IndexSizeEstimator code that are closing CodecReader internals prematurely as 
> well, or just in this situation ... it's also not clear if this only causes 
> failures because this seed uses SimpleTextCodec, and other codecs are more 
> forgiving -- or if something else about the index(es) generated for this seed 
> are what cause the problem to manifest)
> http://fucit.org/solr-jenkins-reports/job-data/apache/Lucene-Solr-NightlyTests-master/1928
> {noformat}
> hossman@tray:~/lucene/dev/solr/core [j11] [master] $ git rev-parse HEAD
> 0291db44bc8e092f7cb2f577f0ac8ab6fa6a5fd7
> hossman@tray:~/lucene/dev/solr/core [j11] [master] $ ant test  
> -Dtestcase=IndexSizeEstimatorTest -Dtests.method=testEstimator 
> -Dtests.seed=23F60434E13D8FD4 -Dtests.multiplier=2 -Dtests.nightly=true 
> -Dtests.slow=true  -Dtests.locale=eo -Dtests.timezone=Atlantic/Madeira 
> -Dtests.asserts=true -Dtests.file.encoding=UTF-8
> ...
>[junit4]   2> NOTE: reproduce with: ant test  
> -Dtestcase=IndexSizeEstimatorTest -Dtests.method=testEstimator 
> -Dtests.seed=23F60434E13D8FD4 -Dtests.multiplier=2 -Dtests.nightly=true 
> -Dtests.slow=true -Dtests.badapples=true -Dtests.locale=eo 
> -Dtests.timezone=Atlantic/Madeira -Dtests.asserts=true 
> -Dtests.file.encoding=UTF-8
>[junit4] ERROR   0.88s | IndexSizeEstimatorTest.testEstimator <<<
>[junit4]> Throwable #1: java.lang.NullPointerException
>[junit4]>at 
> __randomizedtesting.SeedInfo.seed([23F60434E13D8FD4:EC2B6B666D451E64]:0)
>[junit4]>at 
> org.apache.lucene.codecs.simpletext.SimpleTextStoredFieldsReader.visitDocument(SimpleTextStoredFieldsReader.java:109)
>[junit4]>at 
> org.apache.solr.handler.admin.IndexSizeEstimator.estimateStoredFields(IndexSizeEstimator.java:513)
>[junit4]>at 
> org.apache.solr.handler.admin.IndexSizeEstimator.estimate(IndexSizeEstimator.java:198)
>[junit4]>at 
> org.apache.solr.handler.admin.IndexSizeEstimatorTest.testEstimator(IndexSizeEstimatorTest.java:117)
>[junit4]>at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>[junit4]>at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>[junit4]>at 
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>[junit4]>at 
> java.base/java.lang.reflect.Method.invoke(Method.java:566)
>[junit4]>at 

[jira] [Created] (LUCENE-8950) FieldComparators Should Not Maintain Implicit PQs

[Atri Sharma (JIRA)]

Atri Sharma created LUCENE-8950:
---

 Summary: FieldComparators Should Not Maintain Implicit PQs
 Key: LUCENE-8950
 URL: https://issues.apache.org/jira/browse/LUCENE-8950
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Atri Sharma


While doing some perf tests, I realised that FieldComparators inherently 
maintain implicit priority queues for maintaining the sorted order of documents 
for the given sort order. This is wasteful especially in the case of a multi 
feature sort order and a large number of hits requested.

 

We should change this to have FieldComparators maintain only the top and bottom 
values, and use them as barriers to compare



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[GitHub] [lucene-solr] atris opened a new pull request #831: LUCENE-8949: Allow LeafFieldComparators to publish Feature Values

[GitBox]

atris opened a new pull request #831: LUCENE-8949: Allow LeafFieldComparators 
to publish Feature Values
URL: https://github.com/apache/lucene-solr/pull/831
 
 
   


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

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

[Policeman Jenkins Server]

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

1 tests failed.
FAILED:  
org.apache.lucene.index.TestIndexWriterWithThreads.testIOExceptionDuringAbortWithThreads

Error Message:
MockDirectoryWrapper: cannot close: there are still 4 open files: {_0.cfs=1, 
_2.cfs=1, _1.cfs=1, _3.cfs=1}

Stack Trace:
java.lang.RuntimeException: MockDirectoryWrapper: cannot close: there are still 
4 open files: {_0.cfs=1, _2.cfs=1, _1.cfs=1, _3.cfs=1}
at 
__randomizedtesting.SeedInfo.seed([8A4C77E7CC808387:EBE17F6810AE003B]:0)
at 
org.apache.lucene.store.MockDirectoryWrapper.close(MockDirectoryWrapper.java:838)
at 
org.apache.lucene.index.TestIndexWriterWithThreads._testMultipleThreadsFailure(TestIndexWriterWithThreads.java:341)
at 
org.apache.lucene.index.TestIndexWriterWithThreads.testIOExceptionDuringAbortWithThreads(TestIndexWriterWithThreads.java:458)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988)
at 
org.apache.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 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:748)
Caused by: java.lang.RuntimeException: unclosed IndexInput: _3.cfs
at 
org.apache.lucene.store.MockDirectoryWrapper.addFileHandle(MockDirectoryWrapper.java:730)
at 
org.apache.lucene.store.MockDirectoryWrapper.openInput(MockDirectoryWrapper.java:773)
at