[jira] [Commented] (SOLR-13593) Allow to specify analyzer components by their SPI names in schema definition

[Tomoko Uchida (JIRA)]

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

Tomoko Uchida commented on SOLR-13593:
--

I've opened a draft pull request: 
[https://github.com/apache/lucene-solr/pull/761]. (Not yet tested.) I'm new to 
Solr schema handling, please feel free to add comments if I missed something.

This accepts SPI names when loading bundled managed-schema and calling REST API.

managed-schema example:
{code:xml}











{code}
REST API example:
{code:java}
curl -X POST -H 'Content-type:application/json' --data-binary '{
  "add-field-type" : {
 "name":"myNewTxtField",
 "class":"solr.TextField",
 "positionIncrementGap":"100",
 "analyzer" : {
"charFilters":[{
   "spi":"htmlStrip"
}],
"tokenizer":{
   "spi":"whitespace" },
"filters":[{
   "spi":"lowercase"
}]}}
}' http://localhost:8983/solr/techproducts/schema
{code}

> Allow to specify analyzer components by their SPI names in schema definition
> 
>
> Key: SOLR-13593
> URL: https://issues.apache.org/jira/browse/SOLR-13593
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Schema and Analysis
>Reporter: Tomoko Uchida
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Now each analysis factory has explicitely documented SPI name which is stored 
> in the static "NAME" field (LUCENE-8778).
>  Solr uses factories' simple class name in schema definition (like 
> class="solr.WhitespaceTokenizerFactory"), but we should be able to also use 
> more concise SPI names (like name="whitespace").
> e.g.:
> {code:xml}
> 
>   
> 
>  />
> 
>   
> 
> {code}
> would be
> {code:xml}
> 
>   
> 
> 
> 
>   
> 
> {code}



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

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

[GitHub] [lucene-solr] jpountz commented on a change in pull request #747: LUCENE-8888: Improve distribution of points with data dimension in BKD tree leaves

[GitBox]

jpountz commented on a change in pull request #747: LUCENE-: Improve 
distribution of points with data dimension in BKD tree leaves
URL: https://github.com/apache/lucene-solr/pull/747#discussion_r300244789
 
 

 ##
 File path: 
lucene/core/src/java/org/apache/lucene/util/bkd/BKDRadixSelector.java
 ##
 @@ -324,23 +337,22 @@ protected int byteAt(int i, int k) {
 assert k >= 0 : "negative prefix " + k;
 if (k  < dimCmpBytes) {
   // dim bytes
-  return points.block[i * packedBytesLength + offset + k] & 0xff;
+  return points.block[i * packedBytesDocIDLength + dimOffset + k] & 
0xff;
 } else {
-  // doc id
-  int s = 3 - (k - dimCmpBytes);
-  return (points.docIDs[i] >>> (s * 8)) & 0xff;
+  // data bytes
+  return points.block[i * packedBytesDocIDLength + dataOffset + k] & 
0xff;
 }
   }
 
   @Override
   protected Selector getFallbackSelector(int d) {
-int skypedBytes = d + commonPrefix;
-final int start = dim * bytesPerDim + skypedBytes;
-final int end =  dim * bytesPerDim + bytesPerDim;
+final int skypedBytes = d + commonPrefixLength;
+final int dimStart = dim * bytesPerDim + skypedBytes;
+final int dimEnd =  dim * bytesPerDim + bytesPerDim;
+final int dataOffset = numIndexDims * bytesPerDim;
+final int dataLength = (numDataDims - numIndexDims) * bytesPerDim + 
Integer.BYTES;
 
 Review comment:
   I'm assuming the Integer.BYTES is about the doc ID, maybe add a comment to 
clarify since the variable name doesn't imply that this includes the doc ID?


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] mocobeta opened a new pull request #761: SOLR-13593: Allow to use analyzer SPI names in schema definition.

[GitBox]

mocobeta opened a new pull request #761: SOLR-13593: Allow to use analyzer SPI 
names in schema definition.
URL: https://github.com/apache/lucene-solr/pull/761
 
 
   # Description
   
   Please see the issue description: 
https://issues.apache.org/jira/browse/SOLR-13593
   
   # Solution
   
   - Allow to load tokenizer/charFilter/tokenFilter factories via SPI name 
("spi" attribute) in `FieldTypePluginLoader`. If both two attributes ("class" 
and "spi") are defined, "class" is preferred.
   - For `add-field-type` REST API, accept a field type definition if either 
"class" or "spi" property is defined.
   
   # Tests
   
   TBD
   
   # Checklist
   
   Please review the following and check all that apply:
   
   - [x] I have reviewed the guidelines for [How to 
Contribute](https://wiki.apache.org/solr/HowToContribute) and my code conforms 
to the standards described there to the best of my ability.
   - [x] I have created a Jira issue and added the issue ID to my pull request 
title.
   - [x] I am authorized to contribute this code to the ASF and have removed 
any code I do not have a license to distribute.
   - [x] I have developed this patch against the `master` branch.
   - [] I have run `ant precommit` and the appropriate test suite.
   - [] I have added tests for my changes.
   - [] I have added documentation for the Ref Guide (for Solr changes only).
   


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

Re: 8.1.2 bug fix release

[Uwe Schindler]

No,

Running with Java 9 is optional. You have to tell smoker to do this, otherwise 
it enforces Java 8 only.

Uwe

Am July 4, 2019 2:22:40 AM UTC schrieb "Đạt Cao Mạnh" :
>Thanks Uwe, Steve
>
>I'm not familiar with the pipeline of smoker-release but I assumpt that
>the
>same pipeline will be run during release process in my machine and
>anyone
>who do the vote. So It won't be a blocker for this release and I can
>continue with the release process, is that correct?

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

[JENKINS] Lucene-Solr-BadApples-Tests-master - Build # 404 - Failure

[Apache Jenkins Server]

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

All tests passed

Build Log:
[...truncated 64667 lines...]
-ecj-javadoc-lint-src:
[mkdir] Created dir: /tmp/ecj1622079830
 [ecj-lint] Compiling 69 source files to /tmp/ecj1622079830
 [ecj-lint] invalid Class-Path header in manifest of jar file: 
/x1/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: 
/x1/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 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-BadApples-Tests-master/solr/contrib/dataimporthandler/src/java/org/apache/solr/handler/dataimport/JdbcDataSource.java
 (at line 28)
 [ecj-lint] import javax.naming.InitialContext;
 [ecj-lint]^^^
 [ecj-lint] The type javax.naming.InitialContext is not accessible
 [ecj-lint] --
 [ecj-lint] 2. ERROR in 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-BadApples-Tests-master/solr/contrib/dataimporthandler/src/java/org/apache/solr/handler/dataimport/JdbcDataSource.java
 (at line 29)
 [ecj-lint] import javax.naming.NamingException;
 [ecj-lint]
 [ecj-lint] The type javax.naming.NamingException is not accessible
 [ecj-lint] --
 [ecj-lint] 3. ERROR in 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-BadApples-Tests-master/solr/contrib/dataimporthandler/src/java/org/apache/solr/handler/dataimport/JdbcDataSource.java
 (at line 182)
 [ecj-lint] c = getFromJndi(initProps, jndiName);
 [ecj-lint] ^^^
 [ecj-lint] The method getFromJndi(Properties, String) from the type new 
Callable(){} refers to the missing type NamingException
 [ecj-lint] --
 [ecj-lint] 4. ERROR in 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-BadApples-Tests-master/solr/contrib/dataimporthandler/src/java/org/apache/solr/handler/dataimport/JdbcDataSource.java
 (at line 245)
 [ecj-lint] private Connection getFromJndi(final Properties initProps, 
final String jndiName) throws NamingException,
 [ecj-lint] 
 ^^^
 [ecj-lint] NamingException cannot be resolved to a type
 [ecj-lint] --
 [ecj-lint] 5. ERROR in 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-BadApples-Tests-master/solr/contrib/dataimporthandler/src/java/org/apache/solr/handler/dataimport/JdbcDataSource.java
 (at line 249)
 [ecj-lint] InitialContext ctx =  new InitialContext();
 [ecj-lint] ^^
 [ecj-lint] InitialContext cannot be resolved to a type
 [ecj-lint] --
 [ecj-lint] 6. ERROR in 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-BadApples-Tests-master/solr/contrib/dataimporthandler/src/java/org/apache/solr/handler/dataimport/JdbcDataSource.java
 (at line 249)
 [ecj-lint] InitialContext ctx =  new InitialContext();
 [ecj-lint]   ^^
 [ecj-lint] InitialContext cannot be resolved to a type
 [ecj-lint] --
 [ecj-lint] 6 problems (6 errors)

BUILD FAILED
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-BadApples-Tests-master/build.xml:643:
 The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-BadApples-Tests-master/build.xml:101:
 The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-BadApples-Tests-master/solr/build.xml:651:
 The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-BadApples-Tests-master/solr/common-build.xml:479:
 The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-BadApples-Tests-master/lucene/common-build.xml:2009:
 The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-BadApples-Tests-master/lucene/common-build.xml:2048:
 Compile failed; see the compiler error output for details.

Total time: 94 minutes 39 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
Recording test results
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any

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

Re: [JENKINS] Lucene-Solr-8.x-Linux (64bit/jdk-12.0.1) - Build # 811 - Unstable!

[Tomoko Uchida]

Sure, will do so!

2019年7月4日(木) 11:00 David Smiley :
>
> Also; try and run tests before committing :-)
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley
>
>
> On Wed, Jul 3, 2019 at 11:18 AM Tomoko Uchida  
> wrote:
>>
>> I forgot to update _default schema file for tests. The schema was fixed.
>> Thanks @ab for letting me know.
>>
>> Tomoko
>>
>> 2019年7月3日(水) 23:17 Policeman Jenkins Server :
>> >
>> > Build: https://jenkins.thetaphi.de/job/Lucene-Solr-8.x-Linux/811/
>> > Java: 64bit/jdk-12.0.1 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC
>> >
>> > 4 tests failed.
>> > FAILED:  
>> > org.apache.solr.cloud.TestConfigSetsAPI.testUserAndTestDefaultConfigsetsAreSame
>> >
>> > Error Message:
>> > Mismatch in files expected:<..._es.txt, stopwords_e[t.txt, 
>> > stopwords_e]u.txt, stopwords_fa> but was:<..._es.txt, 
>> > stopwords_e[]u.txt, stopwords_fa>
>> >
>> > Stack Trace:
>> > org.junit.ComparisonFailure: Mismatch in files expected:<..._es.txt, 
>> > stopwords_e[t.txt, stopwords_e]u.txt, stopwords_fa> but 
>> > was:<..._es.txt, stopwords_e[]u.txt, stopwords_fa>
>> > at 
>> > __randomizedtesting.SeedInfo.seed([AE0C276FE5A8AE44:A49E7EB38D070CE7]:0)
>> > at org.junit.Assert.assertEquals(Assert.java:115)
>> > at 
>> > org.apache.solr.cloud.TestConfigSetsAPI$1.preVisitDirectory(TestConfigSetsAPI.java:720)
>> > at 
>> > org.apache.solr.cloud.TestConfigSetsAPI$1.preVisitDirectory(TestConfigSetsAPI.java:710)
>> > at java.base/java.nio.file.Files.walkFileTree(Files.java:2808)
>> > at java.base/java.nio.file.Files.walkFileTree(Files.java:2873)
>> > at 
>> > org.apache.solr.cloud.TestConfigSetsAPI.compareDirectories(TestConfigSetsAPI.java:710)
>> > at 
>> > org.apache.solr.cloud.TestConfigSetsAPI.testUserAndTestDefaultConfigsetsAreSame(TestConfigSetsAPI.java:701)
>> > at 
>> > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native 
>> > Method)
>> > at 
>> > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>> > at 
>> > java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>> > at java.base/java.lang.reflect.Method.invoke(Method.java:567)
>> > at 
>> > com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750)
>> > at 
>> > com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938)
>> > at 
>> > com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974)
>> > at 
>> > com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988)
>> > at 
>> > com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
>> > at 
>> > org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
>> > at 
>> > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
>> > at 
>> > org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
>> > at 
>> > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
>> > at 
>> > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
>> > at 
>> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
>> > at 
>> > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
>> > at 
>> > com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
>> > at 
>> > com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
>> > at 
>> > com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:947)
>> > at 
>> > com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832)
>> > at 
>> > com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883)
>> > at 
>> > com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894)
>> > at 
>> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
>> > at 
>> > com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
>> > at 
>> > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
>> > at 
>> > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
>> > at 
>> > org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRu

[jira] [Resolved] (SOLR-13583) Impossible to delete a collection with the same name as an existing alias

[Andrzej Bialecki (JIRA)]

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

Andrzej Bialecki  resolved SOLR-13583.
--
Resolution: Fixed

> Impossible to delete a collection with the same name as an existing alias
> -
>
> Key: SOLR-13583
> URL: https://issues.apache.org/jira/browse/SOLR-13583
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 8.1, 8.1.1
>Reporter: Andrzej Bialecki 
>Assignee: Andrzej Bialecki 
>Priority: Blocker
> Fix For: 8.1.2
>
> Attachments: SOLR-13583.patch, SOLR-13583.patch
>
>
> SOLR-13262 changed the behavior of most collection admin commands so that 
> they always resolve aliases by default. In most cases this is desireable 
> behavior but it also prevents executing commands on the collections that have 
> the same name as an existing alias (which usually points to a different 
> collection).
> This behavior also breaks the REINDEXCOLLECTION command with 
> {{removeSource=true,}} which can also lead to data loss.
> This issue can be resolved by adding either an opt-in or opt-out flag to the 
> collection admin commands that specifies whether the command should attempt 
> resolving the provided name as an alias first. From the point of view of ease 
> of use this could be an opt-out option, from the point of view of data safety 
> this could be an opt-in option.



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

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

[jira] [Commented] (SOLR-13593) Allow to specify analyzer components by their SPI names in schema definition

[Tomoko Uchida (JIRA)]

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

Tomoko Uchida commented on SOLR-13593:
--

I started playing with {{FieldTypePluginLoader}} and noticed that the "name" 
attribute is reserved as Solr's plugin name. Instead of messing up the code, I 
would like to introduce new attribute "spi" (there could be more appropriate 
one?).
{code:xml}

  



  

{code}
Other than that, it seems straightforward to load the factories via the SPI 
names - add a new method to {{AbstractPluginLoader}} to create the new plugin 
instance by spi name, and override it in 
{{FieldTypePluginLoader#readAnalyzer(Node)}}.

> Allow to specify analyzer components by their SPI names in schema definition
> 
>
> Key: SOLR-13593
> URL: https://issues.apache.org/jira/browse/SOLR-13593
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Schema and Analysis
>Reporter: Tomoko Uchida
>Priority: Major
>
> Now each analysis factory has explicitely documented SPI name which is stored 
> in the static "NAME" field (LUCENE-8778).
>  Solr uses factories' simple class name in schema definition (like 
> class="solr.WhitespaceTokenizerFactory"), but we should be able to also use 
> more concise SPI names (like name="whitespace").
> e.g.:
> {code:xml}
> 
>   
> 
>  />
> 
>   
> 
> {code}
> would be
> {code:xml}
> 
>   
> 
> 
> 
>   
> 
> {code}



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

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

[JENKINS] Lucene-Solr-8.x-Windows (64bit/jdk-12.0.1) - Build # 347 - Still Unstable!

[Policeman Jenkins Server]

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

11 tests failed.
FAILED:  
org.apache.solr.ltr.store.rest.TestModelManagerPersistence.testFilePersistence

Error Message:
Software caused connection abort: recv failed

Stack Trace:
javax.net.ssl.SSLException: Software caused connection abort: recv failed
at 
__randomizedtesting.SeedInfo.seed([CAB11432803D6608:E810704F2551004D]:0)
at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:127)
at 
java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:320)
at 
java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:263)
at 
java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:258)
at 
java.base/sun.security.ssl.SSLSocketImpl.handleException(SSLSocketImpl.java:1342)
at 
java.base/sun.security.ssl.SSLSocketImpl$AppInputStream.read(SSLSocketImpl.java:844)
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.testFilePersistence(TestModelManagerPersistence.java:168)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:567)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSin

[jira] [Commented] (SOLR-8169) Need LockFactory impl that uses ZooKeeper as replacement for HdfsLockFactory

[tinswzy (JIRA)]

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

tinswzy commented on SOLR-8169:
---

[~markrmil...@gmail.com] Any patch available now?  

> Need LockFactory impl that uses ZooKeeper as replacement for HdfsLockFactory
> 
>
> Key: SOLR-8169
> URL: https://issues.apache.org/jira/browse/SOLR-8169
> Project: Solr
>  Issue Type: New Feature
>  Components: Hadoop Integration, hdfs
>Reporter: Timothy Potter
>Priority: Major
>
> It would be good to have an option to use a ZooKeeper backed LockFactory 
> implementation as a replacement for the HdfsLockFactory. FWIW - I've seen 
> instances in Solr on YARN environments where the lock file doesn't get 
> cleaned up correctly, which prevents using the index w/o some manual 
> intervention.



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

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

[jira] [Commented] (SOLR-13583) Impossible to delete a collection with the same name as an existing alias

[Cao Manh Dat (JIRA)]

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

Cao Manh Dat commented on SOLR-13583:
-

[~ab] Should it be closed now?

> Impossible to delete a collection with the same name as an existing alias
> -
>
> Key: SOLR-13583
> URL: https://issues.apache.org/jira/browse/SOLR-13583
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 8.1, 8.1.1
>Reporter: Andrzej Bialecki 
>Assignee: Andrzej Bialecki 
>Priority: Blocker
> Fix For: 8.1.2
>
> Attachments: SOLR-13583.patch, SOLR-13583.patch
>
>
> SOLR-13262 changed the behavior of most collection admin commands so that 
> they always resolve aliases by default. In most cases this is desireable 
> behavior but it also prevents executing commands on the collections that have 
> the same name as an existing alias (which usually points to a different 
> collection).
> This behavior also breaks the REINDEXCOLLECTION command with 
> {{removeSource=true,}} which can also lead to data loss.
> This issue can be resolved by adding either an opt-in or opt-out flag to the 
> collection admin commands that specifies whether the command should attempt 
> resolving the provided name as an alias first. From the point of view of ease 
> of use this could be an opt-out option, from the point of view of data safety 
> this could be an opt-in option.



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

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

Re: 8.1.2 bug fix release

[Đạt Cao Mạnh]

Thanks Uwe, Steve

I'm not familiar with the pipeline of smoker-release but I assumpt that the
same pipeline will be run during release process in my machine and anyone
who do the vote. So It won't be a blocker for this release and I can
continue with the release process, is that correct?

Re: 8.1.2 bug fix release

[Đạt Cao Mạnh]

Hi Anshum,

I kinda think we should not do that since 8.1.2 is a bug fix only release.

On Wed, Jul 3, 2019 at 11:56 PM Anshum Gupta  wrote:

> Hi Dat,
>
> Can we also get SOLR-13507
>  in for 8.1.2 ?
>
> On Wed, Jul 3, 2019 at 4:55 AM Đạt Cao Mạnh 
> wrote:
>
>> Thanks Andrzej!
>>
>> On Wed, Jul 3, 2019 at 6:41 PM Andrzej Białecki  wrote:
>>
>>> Dat,
>>>
>>> The fix for SOLR-13583 has been committed to branch_8_1.
>>>
>>> On 3 Jul 2019, at 04:56, Đạt Cao Mạnh  wrote:
>>>
>>> Hi Steve,
>>>
>>> I'm seeing this failure
>>>
>>> [smoker] subprocess.CalledProcessError: Command 'export
>>> JAVA_HOME="/home/jenkins/tools/java/latest1.9"
>>> PATH="/home/jenkins/tools/java/latest1.9/bin:$PATH"
>>> JAVACMD="/home/jenkins/tools/java/latest1.9/bin/java"; java -version'
>>> returned non-zero exit status 127
>>> on
>>>
>>> https://builds.apache.org/view/L/view/Lucene/job/Lucene-Solr-SmokeRelease-8.1/49/console
>>>
>>> It seems that the /home/jenkins/tools/java/latest1.9/bin does not
>>> present in the system. Can you work on this, if that is not possible can
>>> you show me how I can connect to that jenkins box?
>>>
>>> Thanks a lot!
>>>
>>> On Wed, Jul 3, 2019 at 9:52 AM Đạt Cao Mạnh 
>>> wrote:
>>>
 Hi guys,

 I'm seeing several Lucene test failures for branch_8_1. Should they be
 marked as badApples?

 https://builds.apache.org/view/L/view/Lucene/job/Lucene-Solr-Tests-8.1/73/

 https://builds.apache.org/view/L/view/Lucene/job/Lucene-Solr-NightlyTests-8.1/49/


 On Fri, Jun 28, 2019 at 11:28 PM Ignacio Vera 
 wrote:

> Thanks! it is done.
>
> On Fri, Jun 28, 2019 at 5:19 PM Đạt Cao Mạnh 
> wrote:
>
>> Ok, I'm hoping these two are these last ones.
>>
>

 --
 *Best regards,*
 *Cao Mạnh Đạt*
 *E-mail: caomanhdat...@gmail.com *

>>>
>>>
>>> --
>>> *Best regards,*
>>> *Cao Mạnh Đạt*
>>> *E-mail: caomanhdat...@gmail.com *
>>>
>>>
>>>
>>
>> --
>> *Best regards,*
>> *Cao Mạnh Đạt*
>> *E-mail: caomanhdat...@gmail.com *
>>
>
>
> --
> Anshum Gupta
>


-- 
*Best regards,*
*Cao Mạnh Đạt*
*E-mail: caomanhdat...@gmail.com *

[jira] [Commented] (SOLR-13605) HttpSolrClient.Builder.withHttpClient() is useless for the purpose of setting client scoped so/connect timeouts

[David Smiley (JIRA)]

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

David Smiley commented on SOLR-13605:
-

Thorough analysis Hoss; well researched!

> HttpSolrClient.Builder.withHttpClient() is useless for the purpose of setting 
> client scoped so/connect timeouts
> ---
>
> Key: SOLR-13605
> URL: https://issues.apache.org/jira/browse/SOLR-13605
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Priority: Major
>
> TL;DR: trying to use {{HttpSolrClient.Builder.withHttpClient}} is useless for 
> the the purpose of specifying an {{HttpClient}} with the default "timeouts" 
> you want to use on all requests, because of how {{HttpSolrClient.Builder}} 
> and {{HttpClientUtil.createDefaultRequestConfigBuilder()}} hardcode values 
> thta get set on every {{HttpRequest}}.
> This internally affects code that uses things like 
> {{UpdateShardHandler.getDefaultHttpClient()}}, 
> {{UpdateShardHandler.getUpdateOnlyHttpClient()}} 
> {{UpdateShardHandler.getRecoveryOnlyHttpClient()}}, etc...
> 
> While looking into the patch in SOLR-13532, I realized that the way 
> {{HttpSolrClient.Builder}} and it's super class {{SolrClientBuilder}} work, 
> the following code doesn't do what a reasonable person would expect...
> {code:java}
> SolrParams clientParams = params(HttpClientUtil.PROP_SO_TIMEOUT, 12345,
>  HttpClientUtil.PROP_CONNECTION_TIMEOUT, 
> 67890);
> HttpClient httpClient = HttpClientUtil.createClient(clientParams);
> HttpSolrClient solrClient = new HttpSolrClient.Builder(ANY_BASE_SOLR_URL)
> .withHttpClient(httpClient)
> .build();
> {code}
> When {{solrClient}} is used to execute a request, neither of the properties 
> passed to {{HttpClientUtil.createClient(...)}} will matter - the 
> {{HttpSolrClient.Builder}} (via inheritence from {{SolrClientBuilder}} has 
> the following hardcoded values...
> {code:java}
>   // SolrClientBuilder
>   protected Integer connectionTimeoutMillis = 15000;
>   protected Integer socketTimeoutMillis = 12;
> {code}
> ...which unless overridden by calls to {{withConnectionTimeout()}} and 
> {{withSocketTimeout()}} will get set on the {{HttpSolrClient}} object, and 
> used on every request...
> {code:java}
> // protected HttpSolrClient constructor
> this.connectionTimeout = builder.connectionTimeoutMillis;
> this.soTimeout = builder.socketTimeoutMillis;
> {code}
> It would be tempting to try and do something like this to work around the 
> problem...
> {code:java}
> SolrParams clientParams = params(HttpClientUtil.PROP_SO_TIMEOUT, 12345,
>  HttpClientUtil.PROP_CONNECTION_TIMEOUT, 
> 67890);
> HttpClient httpClient = HttpClientUtil.createClient(clientParams);
> HttpSolrClient solrClient = new HttpSolrClient.Builder(ANY_BASE_SOLR_URL)
> .withHttpClient(httpClient)
> .withSocketTimeout(null)
> .withConnectionTimeout(null)
> .build();
> {code}
> ...except for 2 problems:
>  # In {{HttpSolrClient.executeMethod}}, if the values of 
> {{this.connectionTimeout}} or {{this.soTimeout}} are null, then the values 
> from {{HttpClientUtil.createDefaultRequestConfigBuilder();}} get used, which 
> has it's own hardcoded defaults.
>  # {{withSocketTimeout}} and {{withConnectionTimeout}} take an int, not a 
> (nullable) Integer.
> So then maybe something like this would work? - particularly since at the 
> {{HttpClient}} / {{HttpRequest}} / {{RequestConfig}} level, a "-1" set on the 
> {{HttpRequest}}'s {{RequestConfig}} is suppose to mean "use the (client) 
> default" ...
> {code:java}
> SolrParams clientParams = params(HttpClientUtil.PROP_SO_TIMEOUT, 12345,
>  HttpClientUtil.PROP_CONNECTION_TIMEOUT, 
> 67890);
> HttpClient httpClient = HttpClientUtil.createClient(clientParams);
> HttpSolrClient client = new HttpSolrClient.Builder(ANY_BASE_SOLR_URL)
> .withHttpClient(httpClient)
> .withSocketTimeout(-1)
> .withConnectionTimeout(-1)
> .build();
> {code}
> ...except that if we do *that* we get an IllegalArgumentException...
> {code:java}
>   // SolrClientBuilder
>   public B withConnectionTimeout(int connectionTimeoutMillis) {
> if (connectionTimeoutMillis < 0) {
>   throw new IllegalArgumentException("connectionTimeoutMillis must be a 
> non-negative integer.");
> }
> {code}
> This is madness, and eliminates most/all of the known value of using 
> {{.withHttpClient}}



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

-
To uns

[jira] [Commented] (LUCENE-8895) Switch all FSTs to use direct addressing optimization

[ASF subversion and git services (JIRA)]

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

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

Commit 792871c480673f1ed936e2592d6d08922a28b977 in lucene-solr's branch 
refs/heads/branch_8x from Michael Sokolov
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=792871c ]

LUCENE-8895: deprecate the other util.fst.Util.getByOutput override, too


> Switch all FSTs to use direct addressing optimization
> -
>
> Key: LUCENE-8895
> URL: https://issues.apache.org/jira/browse/LUCENE-8895
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Mike Sokolov
>Priority: Major
> Fix For: 8.2
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> See discussion in LUCENE-8781 about turning on array-with-gaps encoding 
> everywhere. Let's conduct any further discussion here so we can use an open 
> issue.



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

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

[jira] [Commented] (LUCENE-8895) Switch all FSTs to use direct addressing optimization

[ASF subversion and git services (JIRA)]

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

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

Commit 8bf5e8be64f5afbc4bd22675c9c36da0fd4b8ffd in lucene-solr's branch 
refs/heads/master from Michael Sokolov
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=8bf5e8b ]

LUCENE-8895: deprecate the other util.fst.Util.getByOutput override, too


> Switch all FSTs to use direct addressing optimization
> -
>
> Key: LUCENE-8895
> URL: https://issues.apache.org/jira/browse/LUCENE-8895
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Mike Sokolov
>Priority: Major
> Fix For: 8.2
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> See discussion in LUCENE-8781 about turning on array-with-gaps encoding 
> everywhere. Let's conduct any further discussion here so we can use an open 
> issue.



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

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

[JENKINS] Lucene-Solr-master-Windows (64bit/jdk-11.0.3) - Build # 8033 - Still unstable!

[Policeman Jenkins Server]

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

10 tests failed.
FAILED:  
org.apache.solr.ltr.store.rest.TestModelManagerPersistence.testFilePersistence

Error Message:
Software caused connection abort: recv failed

Stack Trace:
javax.net.ssl.SSLException: Software caused connection abort: recv failed
at 
__randomizedtesting.SeedInfo.seed([24D41513309EA375:675716E95F2C530]:0)
at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:127)
at 
java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:321)
at 
java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:264)
at 
java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:259)
at 
java.base/sun.security.ssl.SSLSocketImpl.handleException(SSLSocketImpl.java:1314)
at 
java.base/sun.security.ssl.SSLSocketImpl$AppInputStream.read(SSLSocketImpl.java:839)
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.testFilePersistence(TestModelManagerPersistence.java:168)
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.runSingle

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

[Policeman Jenkins Server]

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

7 tests failed.
FAILED:  
org.apache.solr.cloud.autoscaling.TestPolicyCloud.testCreateCollectionAddReplica

Error Message:
Timeout occurred while waiting response from server at: 
https://127.0.0.1:39665/solr

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: Timeout occurred while 
waiting response from server at: https://127.0.0.1:39665/solr
at 
__randomizedtesting.SeedInfo.seed([FC791A014047989C:7C597F2F5104703A]: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.MiniSolrCloudCluster.deleteAllCollections(MiniSolrCloudCluster.java:547)
at 
org.apache.solr.cloud.autoscaling.TestPolicyCloud.after(TestPolicyCloud.java:87)
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$10.evaluate(RandomizedRunner.java:996)
at 
org.junit.rules.ExpectedException$ExpectedExceptionStatement.evaluate(ExpectedException.java:239)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:947)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
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)

[jira] [Updated] (SOLR-13532) Unable to start core recovery due to timeout in ping request

[Hoss Man (JIRA)]

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

Hoss Man updated SOLR-13532:

Status: Patch Available  (was: Open)

> Unable to start core recovery due to timeout in ping request
> 
>
> Key: SOLR-13532
> URL: https://issues.apache.org/jira/browse/SOLR-13532
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Affects Versions: 7.6
>Reporter: Suril Shah
>Priority: Major
> Attachments: SOLR-13532.patch
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> Discovered following issue with the core recovery:
>  * Core recovery is not being initialized and throwing following exception 
> message :
> {code:java}
> 2019-06-07 00:53:12.436 INFO  
> (recoveryExecutor-4-thread-1-processing-n::8983_solr 
> x:_shard41_replica_n2777 c: s:shard41 
> r:core_node2778) x:_shard41_replica_n2777 
> o.a.s.c.RecoveryStrategy Failed to connect leader http://:8983/solr 
> on recovery, try again{code}
>  * Above error occurs when ping request takes time more than a timeout period 
> which is hard-coded to one second in solr source code. However In a general 
> production setting it is common to have ping time more than one second, 
> hence, the core recovery never starts and exception is thrown.
>  * Also the other major concern is that this exception is logged as an info 
> message, hence it is very difficult to identify the error if info logging is 
> not enabled.
>  * Please refer to following code snippet from the [source 
> code|https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/cloud/RecoveryStrategy.java#L789-L803]
>  to understand the above issue.
> {code:java}
>   try (HttpSolrClient httpSolrClient = new 
> HttpSolrClient.Builder(leaderReplica.getCoreUrl())
>   .withSocketTimeout(1000)
>   .withConnectionTimeout(1000)
>   
> .withHttpClient(cc.getUpdateShardHandler().getRecoveryOnlyHttpClient())
>   .build()) {
> SolrPingResponse resp = httpSolrClient.ping();
> return leaderReplica;
>   } catch (IOException e) {
> log.info("Failed to connect leader {} on recovery, try again", 
> leaderReplica.getBaseUrl());
> Thread.sleep(500);
>   } catch (Exception e) {
> if (e.getCause() instanceof IOException) {
>   log.info("Failed to connect leader {} on recovery, try again", 
> leaderReplica.getBaseUrl());
>   Thread.sleep(500);
> } else {
>   return leaderReplica;
> }
>   }
> {code}
> The above issue will have high impact in production level clusters, since 
> cores not being able to recover may lead to data loss.
> Following improvements would be really helpful:
>  1. The [timeout for ping 
> request|https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/cloud/RecoveryStrategy.java#L790-L791]
>  in *RecoveryStrategy.java* should be configurable and the defaults set to 
> high values like 15seconds.
>  2. The exception message in [line 
> 797|https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/cloud/RecoveryStrategy.java#L797]
>  and [line 
> 801|https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/cloud/RecoveryStrategy.java#L801]
>  in *RecoveryStrategy.java* should be logged as *error* messages instead of 
> *info* messages



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

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

[jira] [Updated] (SOLR-13532) Unable to start core recovery due to timeout in ping request

[Hoss Man (JIRA)]

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

Hoss Man updated SOLR-13532:

Attachment: SOLR-13532.patch
Status: Open  (was: Open)

bq. The other alternative to this would be to update the {{RecoveryStrategy}} 
code to use something like {{cc.getConfig().getUpdateShardHandlerConfig()}} ...

Here's a variant of Suril's patch along those lines, with some refactoring to 
put the logic into a helper method.

I don't love it -- but i don't hate it either.

I'm still running tests to make sure i didn't break anything, but in the 
meantime what do folks think? ... can anyone see any problems with this 
approach?

([~surilshah]: does this patch -- and the usage of the solr.xml configures 
values instead of hardcoded magic constants -- solvethe problems you're seeing?)

> Unable to start core recovery due to timeout in ping request
> 
>
> Key: SOLR-13532
> URL: https://issues.apache.org/jira/browse/SOLR-13532
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Affects Versions: 7.6
>Reporter: Suril Shah
>Priority: Major
> Attachments: SOLR-13532.patch
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> Discovered following issue with the core recovery:
>  * Core recovery is not being initialized and throwing following exception 
> message :
> {code:java}
> 2019-06-07 00:53:12.436 INFO  
> (recoveryExecutor-4-thread-1-processing-n::8983_solr 
> x:_shard41_replica_n2777 c: s:shard41 
> r:core_node2778) x:_shard41_replica_n2777 
> o.a.s.c.RecoveryStrategy Failed to connect leader http://:8983/solr 
> on recovery, try again{code}
>  * Above error occurs when ping request takes time more than a timeout period 
> which is hard-coded to one second in solr source code. However In a general 
> production setting it is common to have ping time more than one second, 
> hence, the core recovery never starts and exception is thrown.
>  * Also the other major concern is that this exception is logged as an info 
> message, hence it is very difficult to identify the error if info logging is 
> not enabled.
>  * Please refer to following code snippet from the [source 
> code|https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/cloud/RecoveryStrategy.java#L789-L803]
>  to understand the above issue.
> {code:java}
>   try (HttpSolrClient httpSolrClient = new 
> HttpSolrClient.Builder(leaderReplica.getCoreUrl())
>   .withSocketTimeout(1000)
>   .withConnectionTimeout(1000)
>   
> .withHttpClient(cc.getUpdateShardHandler().getRecoveryOnlyHttpClient())
>   .build()) {
> SolrPingResponse resp = httpSolrClient.ping();
> return leaderReplica;
>   } catch (IOException e) {
> log.info("Failed to connect leader {} on recovery, try again", 
> leaderReplica.getBaseUrl());
> Thread.sleep(500);
>   } catch (Exception e) {
> if (e.getCause() instanceof IOException) {
>   log.info("Failed to connect leader {} on recovery, try again", 
> leaderReplica.getBaseUrl());
>   Thread.sleep(500);
> } else {
>   return leaderReplica;
> }
>   }
> {code}
> The above issue will have high impact in production level clusters, since 
> cores not being able to recover may lead to data loss.
> Following improvements would be really helpful:
>  1. The [timeout for ping 
> request|https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/cloud/RecoveryStrategy.java#L790-L791]
>  in *RecoveryStrategy.java* should be configurable and the defaults set to 
> high values like 15seconds.
>  2. The exception message in [line 
> 797|https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/cloud/RecoveryStrategy.java#L797]
>  and [line 
> 801|https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/cloud/RecoveryStrategy.java#L801]
>  in *RecoveryStrategy.java* should be logged as *error* messages instead of 
> *info* messages



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

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

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

[Apache Jenkins Server]

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

1 tests failed.
FAILED:  
org.apache.solr.ltr.model.TestWrapperModel.testMethodOverridesAndDelegation

Error Message:
class org.apache.solr.ltr.model.WrapperModel needs to override 'public long 
org.apache.solr.ltr.model.LTRScoringModel.ramBytesUsed()'

Stack Trace:
java.lang.AssertionError: class org.apache.solr.ltr.model.WrapperModel needs to 
override 'public long org.apache.solr.ltr.model.LTRScoringModel.ramBytesUsed()'
at 
__randomizedtesting.SeedInfo.seed([E4967A940ACD9FBD:E169A634B705DAF4]:0)
at org.junit.Assert.fail(Assert.java:88)
at 
org.apache.solr.ltr.model.TestWrapperModel.testOverwrittenMethods(TestWrapperModel.java:205)
at 
org.apache.solr.ltr.model.TestWrapperModel.testMethodOverridesAndDelegation(TestWrapperModel.java:169)
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 24428 lines...]
   [junit4] Suite: org

[JENKINS] Lucene-Solr-8.x-Linux (64bit/jdk-12.0.1) - Build # 813 - Still Unstable!

[Policeman Jenkins Server]

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

18 tests failed.
FAILED:  
org.apache.solr.cloud.autoscaling.TestPolicyCloud.testCreateCollectionAddReplica

Error Message:
Timeout occurred while waiting response from server at: 
https://127.0.0.1:46075/solr

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: Timeout occurred while 
waiting response from server at: https://127.0.0.1:46075/solr
at 
__randomizedtesting.SeedInfo.seed([BE3550DC4B41FD2B:3E1535F25A02158D]: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.MiniSolrCloudCluster.deleteAllCollections(MiniSolrCloudCluster.java:547)
at 
org.apache.solr.cloud.autoscaling.TestPolicyCloud.after(TestPolicyCloud.java:87)
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$10.evaluate(RandomizedRunner.java:996)
at 
org.junit.rules.ExpectedException$ExpectedExceptionStatement.evaluate(ExpectedException.java:239)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:947)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
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)
   

[jira] [Commented] (SOLR-13457) Managing Timeout values in Solr

[Hoss Man (JIRA)]

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

Hoss Man commented on SOLR-13457:
-

SOLR-13605 shows some more of the madness involved in how these settings are 
borked -- even if you just focus on the the SolrJ APIs for specifying things 
(notably {{HttpSolrClient.Builder.withHttpClient}}) w/o even considering how 
*solr* should use those SolrJ APIs based on the things like {{solr.xml}}

> Managing Timeout values in Solr
> ---
>
> Key: SOLR-13457
> URL: https://issues.apache.org/jira/browse/SOLR-13457
> Project: Solr
>  Issue Type: Improvement
>Affects Versions: master (9.0)
>Reporter: Gus Heck
>Priority: Major
>
> Presently, Solr has a variety of timeouts for various connections or 
> operations. These timeouts have been added, tweaked and refined and in some 
> cases made configurable in an ad-hoc manner by the contributors of individual 
> features. Throughout the history of the project. This is all well and good 
> until one experiences a timeout during an otherwise valid use case and needs 
> to adjust it.
> This has also made managing timeouts in unit tests "interesting" as noted in 
> SOLR-13389.
> Probably nobody has the spare time to do a tour de force through the code and 
> coordinate every single timeout, so in this ticket I'd like to establish a 
> framework for categorizing time outs, a standard for how we make each 
> category configurable, and then add sub-tickets to address individual 
> timeouts.
> The intention is that eventually, there will be no "magic number" timeout 
> values in code, and one can predict where to find the configuration for a 
> timeout by determining it's category.
> Initial strawman categories (feel free to knock down or suggest alternatives):
>  # *Feature-Instance Timeout*: Timeouts that relate to a particular 
> instantiation of a feature, for example a database connection timeout for a 
> connection to a particular database by DIH. These should be set in the 
> configuration of that instance.
>  # *Optional Feature Timeout*: A timeout that only has meaning in the context 
> of a particular feature that is not required for solr to function... i.e. 
> something that can be turned on or off. Perhaps a timeout for communication 
> with an external ldap for authentication purposes. These should be configured 
> in the same configuration that enables this feature.
>  # *Global System Timeout*: A timeout that will always be an active part of 
> Solr these should be configured in a new  section of solr.xml. For 
> example the Jetty thread idle timeout, or the default timeout for http calls 
> between nodes.
>  # *Node Specific Timeout*: A timeout which may differ on different nodes. I 
> don't know of any of these, but I'll grant the possibility. These (and only 
> these) should be set by setting system properties. If we don't have any of 
> these, that's just fine :).
>  # *Client Timeout*: These are timeouts in solrj code that are active in code 
> running outside the server. They should be configurable via java api, and via 
> a config file of some sort from a single location defined in a sysprop or 
> sourced from classpath (in that order). When run on the server, the solrj 
> code should look for a *Global System Timeout* setting before consulting 
> sysprops or classpath.
> *Note that in no case is a hard-coded value the correct solution.*
> If we get a consensus on categories and their locations, then the next step 
> is to begin adding sub tickets to bring specific timeouts into compliance. 
> Every such ticket should include an update to the section of the ref guide 
> documenting the configuration to which the timeout has been added (e.g. docs 
> for solr.xml for Global System Timeouts) describing what exactly is affected 
> by the timeout, the maximum allowed value and how zero and negative numbers 
> are handled.
> It is of course true that some of these values will have the potential to 
> destroy system performance or integrity, and that should be mentioned in the 
> update to documentation.



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

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

[jira] [Created] (SOLR-13606) DateTimeFormatter Exception on Create Core

[Joseph Krauss (JIRA)]

Joseph Krauss created SOLR-13606:


 Summary: DateTimeFormatter Exception on Create Core
 Key: SOLR-13606
 URL: https://issues.apache.org/jira/browse/SOLR-13606
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
  Components: Server
Affects Versions: 8.1.1
 Environment: Red Hat 8.0

Java 11

Solr 8.1.1
Reporter: Joseph Krauss


I have a fresh install of RH 8.0 with Java 11 JDK and I've run into an issue 
with Solr 8.0.0 and 8.1.1 when attempting to create a core. I'm guessing here, 
but the error appears to be an issue with the date format. From what I've read 
Java date parser is expecting a period between seconds and milliseconds? 
Hopefully, there's something simple I overlooked when I configured the 
environment for solr. 
Caused by: java.time.format.DateTimeParseException: Text 
'2019-07-03T20:00:{color:#FF}00.050Z{color}'
Oracle Corporation OpenJDK 64-Bit Server VM 11.0.3 11.0.3+7-LTS
org.apache.solr.common.SolrException: Error CREATEing SolrCore 'testarms': 
Unable to create core [testarms] Caused by: null
at org.apache.solr.core.CoreContainer.create(CoreContainer.java:1187)
at 
org.apache.solr.handler.admin.CoreAdminOperation.lambda$static$0(CoreAdminOperation.java:92)
at 
org.apache.solr.handler.admin.CoreAdminOperation.execute(CoreAdminOperation.java:360)
at 
org.apache.solr.handler.admin.CoreAdminHandler$CallInfo.call(CoreAdminHandler.java:396)
at 
org.apache.solr.handler.admin.CoreAdminHandler.handleRequestBody(CoreAdminHandler.java:180)
at 
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:199)
at 
org.apache.solr.servlet.HttpSolrCall.handleAdmin(HttpSolrCall.java:796)
at 
org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:762)
at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:522)
at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:397)
at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:343)
at 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1602)
at 
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:540)
at 
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:146)
at 
org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)
at 
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)
at 
org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:257)
at 
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1588)
at 
org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255)
at 
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1345)
at 
org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:203)
at 
org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:480)
at 
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1557)
at 
org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:201)
at 
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1247)
at 
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:144)
at 
org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:220)
at 
org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:126)
at 
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)
at 
org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:335)
at 
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)
at org.eclipse.jetty.server.Server.handle(Server.java:502)
at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:364)
at 
org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:260)
at 
org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:305)
at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103)
at org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:118)
at 
org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:333)
at 
org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:310)
at 
org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:168)
at 
org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:12

[jira] [Commented] (SOLR-13532) Unable to start core recovery due to timeout in ping request

[Hoss Man (JIRA)]

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

Hoss Man commented on SOLR-13532:
-

My first impression on seeing this patch was that I _really_ dislike the idea 
of "fixing" a hardcoded timeout by changing it to a _different_ hardcoded 
timeout – I would really much rather we use the existing {{solr.xml}} 
configured timeouts for this sort of thing.

So then I went poking around the code to refresh my memory about how/where the 
SO & CONNECT timeouts config options for intranode requests get populated in 
the code to propose an alternative patch that uses them, and realized that we 
already have an {{UpdateShardHandler.getRecoveryOnlyHttpClient()}} method that 
returns an HttpClient pre-configured with the correct timeout values ... and 
then I realized that this is already used in the code in question via 
{{withHttpClient(...)}}...
{code:java}
  // existing, pre-patch, code in RecoveryStrategy
  try (HttpSolrClient httpSolrClient = new 
HttpSolrClient.Builder(leaderReplica.getCoreUrl())
  .withSocketTimeout(1000)
  .withConnectionTimeout(1000)
  
.withHttpClient(cc.getUpdateShardHandler().getRecoveryOnlyHttpClient())
{code}
This {{UpdateShardHandler.getRecoveryOnlyHttpClient()}} concept, and that 
corresponding {{withHttpClient()}} call, was introduced *after* the original 
recovery code was written (with those hardcoed timeouts) ... In theory if we 
just remove the {{withSocketTimeout}} and {{withConnectionTimeout}} completely 
from this class, then the cluster's {{solr.xml}} configuration options should 
start getting used.

But then I dug deeper and discovered that the way HttpSolrClient & it's Builder 
works is really silly and frustrating and causes the hardcoded values 
{{SolrClientBuilder.connectionTimeoutMillis = 15000}} and 
{{SolrClientBuilder.socketTimeoutMillis = 12}} to get used at the request 
level, even when {{withHttpClient}} has been called to set an {{HttpClient}} 
that already has the settings we want ... basically defeating a huge part of 
the value in {{withHttpClient}} ... even using values of {{null}} or {{-1}} 
won't work, because of other nonsensical ways that "default" values come into 
play

I created SOLR-13605 to track the silliness in {{HttpClient.Builder}} – it's a 
bigger issue then just fixing this ping/recovery problem, and will require more 
careful consideration.

As much as it pains me to say this: I think that for now, for the purpose of 
fixing the bug in this jira, we should just remove the {{withSocketTimeout(}} 
and {{withConnectionTimeout()}} calls completely, and defer to the 
(pre-existing) hardcoded defaults in {{SolrClientBuilder}} ... at least that 
way we're reducing the number of hardcoded defaults in the code, and if/when 
SOLR-13605 get's fixed, the {{solr.xml}} settings should take affect.

The other alternative to this would be to update the {{RecoveryStrategy}} code 
to use something like {{cc.getConfig().getUpdateShardHandlerConfig()}} and then 
use {{UpdateShardHandlerConfig.getDistributedSocketTimeout()}} and 
{{UpdateShardHandlerConfig.getDistributedConnectionTimeout()}} to pass as the 
inputs to {{SolrHttpClient.Builder}} ... that seemed really silly and redundent 
when it first occured to me, but the more i think about it the more it's 
probably not that bad as a work around for SOLR-13605 until it's fixed.

What do folks think?

> Unable to start core recovery due to timeout in ping request
> 
>
> Key: SOLR-13532
> URL: https://issues.apache.org/jira/browse/SOLR-13532
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Affects Versions: 7.6
>Reporter: Suril Shah
>Priority: Major
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> Discovered following issue with the core recovery:
>  * Core recovery is not being initialized and throwing following exception 
> message :
> {code:java}
> 2019-06-07 00:53:12.436 INFO  
> (recoveryExecutor-4-thread-1-processing-n::8983_solr 
> x:_shard41_replica_n2777 c: s:shard41 
> r:core_node2778) x:_shard41_replica_n2777 
> o.a.s.c.RecoveryStrategy Failed to connect leader http://:8983/solr 
> on recovery, try again{code}
>  * Above error occurs when ping request takes time more than a timeout period 
> which is hard-coded to one second in solr source code. However In a general 
> production setting it is common to have ping time more than one second, 
> hence, the core recovery never starts and exception is thrown.
>  * Also the other major concern is that this exception is logged as an info 
> message, hence it is very difficult to identify the error if info logging is 
> not enabled.
>  * Please refer to following code snippet from the [source 
> cod

[jira] [Created] (SOLR-13605) HttpSolrClient.Builder.withHttpClient() is useless for the purpose of setting client scoped so/connect timeouts

[Hoss Man (JIRA)]

Hoss Man created SOLR-13605:
---

 Summary: HttpSolrClient.Builder.withHttpClient() is useless for 
the purpose of setting client scoped so/connect timeouts
 Key: SOLR-13605
 URL: https://issues.apache.org/jira/browse/SOLR-13605
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Hoss Man


TL;DR: trying to use {{HttpSolrClient.Builder.withHttpClient}} is useless for 
the the purpose of specifying an {{HttpClient}} with the default "timeouts" you 
want to use on all requests, because of how {{HttpSolrClient.Builder}} and 
{{HttpClientUtil.createDefaultRequestConfigBuilder()}} hardcode values thta get 
set on every {{HttpRequest}}.

This internally affects code that uses things like 
{{UpdateShardHandler.getDefaultHttpClient()}}, 
{{UpdateShardHandler.getUpdateOnlyHttpClient()}} 
{{UpdateShardHandler.getRecoveryOnlyHttpClient()}}, etc...

While looking into the patch in SOLR-13532, I realized that the way 
{{HttpSolrClient.Builder}} and it's super class {{SolrClientBuilder}} work, the 
following code doesn't do what a reasonable person would expect...
{code:java}
SolrParams clientParams = params(HttpClientUtil.PROP_SO_TIMEOUT, 12345,
 HttpClientUtil.PROP_CONNECTION_TIMEOUT, 67890);
HttpClient httpClient = HttpClientUtil.createClient(clientParams);
HttpSolrClient solrClient = new HttpSolrClient.Builder(ANY_BASE_SOLR_URL)
.withHttpClient(httpClient)
.build();
{code}
When {{solrClient}} is used to execute a request, neither of the properties 
passed to {{HttpClientUtil.createClient(...)}} will matter - the 
{{HttpSolrClient.Builder}} (via inheritence from {{SolrClientBuilder}} has the 
following hardcoded values...
{code:java}
  // SolrClientBuilder
  protected Integer connectionTimeoutMillis = 15000;
  protected Integer socketTimeoutMillis = 12;
{code}
...which unless overridden by calls to {{withConnectionTimeout()}} and 
{{withSocketTimeout()}} will get set on the {{HttpSolrClient}} object, and used 
on every request...
{code:java}
// protected HttpSolrClient constructor
this.connectionTimeout = builder.connectionTimeoutMillis;
this.soTimeout = builder.socketTimeoutMillis;

{code}
It would be tempting to try and do something like this to work around the 
problem...
{code:java}
SolrParams clientParams = params(HttpClientUtil.PROP_SO_TIMEOUT, 12345,
 HttpClientUtil.PROP_CONNECTION_TIMEOUT, 67890);
HttpClient httpClient = HttpClientUtil.createClient(clientParams);
HttpSolrClient solrClient = new HttpSolrClient.Builder(ANY_BASE_SOLR_URL)
.withHttpClient(httpClient)
.withSocketTimeout(null)
.withConnectionTimeout(null)
.build();
{code}
...except for 2 problems:
 # In {{HttpSolrClient.executeMethod}}, if the values of 
{{this.connectionTimeout}} or {{this.soTimeout}} are null, then the values from 
{{HttpClientUtil.createDefaultRequestConfigBuilder();}} get used, which has 
it's own hardcoded defaults.
 # {{withSocketTimeout}} and {{withConnectionTimeout}} take an int, not a 
(nullable) Integer.

So then maybe something like this would work? - particularly since at the 
{{HttpClient}} / {{HttpRequest}} / {{RequestConfig}} level, a "-1" set on the 
{{HttpRequest}}'s {{RequestConfig}} is suppose to mean "use the (client) 
default" ...
{code:java}
SolrParams clientParams = params(HttpClientUtil.PROP_SO_TIMEOUT, 12345,
 HttpClientUtil.PROP_CONNECTION_TIMEOUT, 67890);
HttpClient httpClient = HttpClientUtil.createClient(clientParams);
HttpSolrClient client = new HttpSolrClient.Builder(ANY_BASE_SOLR_URL)
.withHttpClient(httpClient)
.withSocketTimeout(-1)
.withConnectionTimeout(-1)
.build();
{code}
...except that if we do *that* we get an IllegalArgumentException...
{code:java}
  // SolrClientBuilder
  public B withConnectionTimeout(int connectionTimeoutMillis) {
if (connectionTimeoutMillis < 0) {
  throw new IllegalArgumentException("connectionTimeoutMillis must be a 
non-negative integer.");
}
{code}
This is madness, and eliminates most/all of the known value of using 
{{.withHttpClient}}



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

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

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

[Policeman Jenkins Server]

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

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

Error Message:
should be a routed alias

Stack Trace:
java.lang.AssertionError: should be a routed alias
at 
__randomizedtesting.SeedInfo.seed([99940F84659538EF:864393A8169EC1A4]:0)
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.assertTrue(Assert.java:41)
at 
org.apache.solr.cloud.AliasIntegrationTest.testClusterStateProviderAPI(AliasIntegrationTest.java:315)
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 14458 lines...]
   [junit4] Suite: org.apache.solr.cloud.AliasIntegrationTest
   [junit4]   2> 2102645 INFO  
(SUITE-AliasIntegrationTest-seed#[99940F84659538EF]-worker) [ ] 
o.a.s.SolrTestCaseJ4 SecureRandom sanity checks: 
test.solr.allowed.securerandom=

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

[Policeman Jenkins Server]

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

1 tests failed.
FAILED:  org.apache.solr.cloud.SystemCollectionCompatTest.testBackCompat

Error Message:
re-indexing warning not found

Stack Trace:
java.lang.AssertionError: re-indexing warning not found
at 
__randomizedtesting.SeedInfo.seed([C95B7D9726E72868:B9AEDE3E462F811E]:0)
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.assertTrue(Assert.java:41)
at 
org.apache.solr.cloud.SystemCollectionCompatTest.testBackCompat(SystemCollectionCompatTest.java:206)
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 14456 lines...]
   [junit4] Suite: org.apache.solr.cloud.SystemCollectionCompatTest
   [junit4]   2> 1390127 INFO  
(SUITE-SystemCollectionCompatTest-seed#[C95B7D9726E72868]-worker) [ ] 
o.a.s.SolrTestCaseJ4 SecureRandom sanity checks: 
test.solr.allowed.securerandom=null & j

[GitHub] [lucene-solr] s1monw 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]

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

 ##
 File path: 
lucene/core/src/java/org/apache/lucene/store/ByteBufferIndexInput.java
 ##
 @@ -491,4 +492,14 @@ protected ByteBufferIndexInput buildSlice(String 
sliceDescription, long ofs, lon
   return super.buildSlice(sliceDescription, this.offset + ofs, length);
 }
   }
+
+  @Override
+  public boolean load() {
+for (ByteBuffer buffer : buffers) {
+  if (buffer instanceof MappedByteBuffer) {
+((MappedByteBuffer) buffer).load();
 
 Review comment:
   I pushed changes to address this. I still need to look into testing more.


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

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

 ##
 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:
   sure I can do that


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-MacOSX (64bit/jdk-11.0.3) - Build # 221 - Unstable!

[Policeman Jenkins Server]

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

5 tests failed.
FAILED:  
org.apache.solr.ltr.model.TestWrapperModel.testMethodOverridesAndDelegation

Error Message:
class org.apache.solr.ltr.model.WrapperModel needs to override 'public long 
org.apache.solr.ltr.model.LTRScoringModel.ramBytesUsed()'

Stack Trace:
java.lang.AssertionError: class org.apache.solr.ltr.model.WrapperModel needs to 
override 'public long org.apache.solr.ltr.model.LTRScoringModel.ramBytesUsed()'
at 
__randomizedtesting.SeedInfo.seed([C550A28B6C27EDFC:C0AF7E2BD1EFA8B5]:0)
at org.junit.Assert.fail(Assert.java:88)
at 
org.apache.solr.ltr.model.TestWrapperModel.testOverwrittenMethods(TestWrapperModel.java:205)
at 
org.apache.solr.ltr.model.TestWrapperModel.testMethodOverridesAndDelegation(TestWrapperModel.java:169)
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)


FAILED:  
org.apache.solr.ltr.model.

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

[Apache Jenkins Server]

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

[...truncated 28 lines...]
[repro] Jenkins log URL: 
https://builds.apache.org/job/Lucene-Solr-NightlyTests-8.1/50/consoleText

[repro] Revision: e50e9c34683cd1b439f717faff074f7fabe871a5

[repro] Ant options: -Dtests.multiplier=2 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-8.1/test-data/enwiki.random.lines.txt
[repro] Repro line:  ant test  -Dtestcase=PeerSyncTest -Dtests.method=test 
-Dtests.seed=8221CF0205D372F8 -Dtests.multiplier=2 -Dtests.nightly=true 
-Dtests.slow=true 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-8.1/test-data/enwiki.random.lines.txt
 -Dtests.locale=da-DK -Dtests.timezone=Europe/Zurich -Dtests.asserts=true 
-Dtests.file.encoding=UTF-8

[repro] git rev-parse --abbrev-ref HEAD
[repro] git rev-parse HEAD
[repro] Initial local git branch/revision: 
66812b2a6758240f401a5c8aee1488a1f4d14d5f
[repro] git fetch
[repro] git checkout e50e9c34683cd1b439f717faff074f7fabe871a5

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

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

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

[...truncated 3576 lines...]
[repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=5 
-Dtests.class="*.PeerSyncTest" -Dtests.showOutput=onerror -Dtests.multiplier=2 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-8.1/test-data/enwiki.random.lines.txt
 -Dtests.seed=8221CF0205D372F8 -Dtests.multiplier=2 -Dtests.nightly=true 
-Dtests.slow=true 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-8.1/test-data/enwiki.random.lines.txt
 -Dtests.locale=da-DK -Dtests.timezone=Europe/Zurich -Dtests.asserts=true 
-Dtests.file.encoding=UTF-8

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

[repro] Failures:
[repro]   2/5 failed: org.apache.solr.update.PeerSyncTest
[repro] git checkout 66812b2a6758240f401a5c8aee1488a1f4d14d5f

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

[...truncated 6 lines...]

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

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

[Apache Jenkins Server]

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

No tests ran.

Build Log:
[...truncated 24989 lines...]
[asciidoctor:convert] asciidoctor: ERROR: about-this-guide.adoc: line 1: 
invalid part, must have at least one section (e.g., chapter, appendix, etc.)
[asciidoctor:convert] asciidoctor: ERROR: solr-glossary.adoc: line 1: invalid 
part, must have at least one section (e.g., chapter, appendix, etc.)
 [java] Processed 2587 links (2117 relative) to 3396 anchors in 259 files
 [echo] Validated Links & Anchors via: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.x/solr/build/solr-ref-guide/bare-bones-html/

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

package:

-unpack-solr-tgz:

-ensure-solr-tgz-exists:
[mkdir] Created dir: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.x/solr/build/solr.tgz.unpacked
[untar] Expanding: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.x/solr/package/solr-8.2.0.tgz
 into 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.x/solr/build/solr.tgz.unpacked

generate-maven-artifacts:

resolve:

resolve:

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

-ivy-fail-disallowed-ivy-version:

ivy-fail:

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

resolve:

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

-ivy-fail-disallowed-ivy-version:

ivy-fail:

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

resolve:

resolve:

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

-ivy-fail-disallowed-ivy-version:

ivy-fail:

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

resolve:

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

-ivy-fail-disallowed-ivy-version:

ivy-fail:

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

resolve:

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

-ivy-fail-disallowed-ivy-version:

ivy-fail:

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

resolve:

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

-ivy-fail-disallowed-ivy-version:

ivy-fail:

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

resolve:

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

-ivy-fail-disallowed-ivy-version:

ivy-fail:

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

resolve:

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

-ivy-fail-disallowed-ivy-version:

ivy-fail:

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

resolve:

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

-ivy-fail-disallowed-ivy-version:

ivy-fail:

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

resolve:

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

-ivy-fail-disallowed-ivy-version:

ivy-fail:

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

resolve:

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

-ivy-fail-disallowed-ivy-version:

ivy-fail:

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

resolve:

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

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings ::

Re: SolrCloud - "[not a shard request]" is returned when search request is short circuited

[David Smiley]

Sounds like a bug to me; please do file an issue.

~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley


On Fri, Jun 28, 2019 at 7:24 PM gopikannan  wrote:

> Hello,
>If the collection has only one shard/replica or in case when _route_
> param points to the hosted core,  [shard] field in response is set to
> "[not a shard request]".
>
> When short-circuiting in below code "shard.url" is not populated in
> request param.
> Please let me know if I  submit a JIRA.
>
>
> https://github.com/apache/lucene-solr/blob/301ea0e4624c2bd693fc034a801c4abb91cba299/solr/core/src/java/org/apache/solr/handler/component/HttpShardHandler.java#L405
>
> http://localhost:8983/solr/collection1/selct?q=*:*&fl=[shard]
>
> Thanks
> Gopi
>

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

[Apache Jenkins Server]

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

All tests passed

Build Log:
[...truncated 64439 lines...]
-ecj-javadoc-lint-src:
[mkdir] Created dir: /tmp/ecj1579440909
 [ecj-lint] Compiling 1280 source files to /tmp/ecj1579440909
 [ecj-lint] Processing annotations
 [ecj-lint] Annotations processed
 [ecj-lint] Processing annotations
 [ecj-lint] No elements to process
 [ecj-lint] invalid Class-Path header in manifest of jar file: 
/x1/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: 
/x1/jenkins/.ivy2/cache/org.restlet.jee/org.restlet.ext.servlet/jars/org.restlet.ext.servlet-2.3.0.jar
 [ecj-lint] --
 [ecj-lint] 1. WARNING in 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-master/checkout/solr/core/src/java/org/apache/solr/client/solrj/embedded/EmbeddedSolrServer.java
 (at line 219)
 [ecj-lint] return (NamedList) new 
JavaBinCodec(resolver).unmarshal(in);
 [ecj-lint]^^
 [ecj-lint] Resource leak: '' is never closed
 [ecj-lint] --
 [ecj-lint] --
 [ecj-lint] 2. WARNING in 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-master/checkout/solr/core/src/java/org/apache/solr/cloud/autoscaling/sim/SimCloudManager.java
 (at line 788)
 [ecj-lint] throw new UnsupportedOperationException("must add at least 1 
node first");
 [ecj-lint] 
^^
 [ecj-lint] Resource leak: 'queryRequest' is not closed at this location
 [ecj-lint] --
 [ecj-lint] 3. WARNING in 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-master/checkout/solr/core/src/java/org/apache/solr/cloud/autoscaling/sim/SimCloudManager.java
 (at line 794)
 [ecj-lint] throw new UnsupportedOperationException("must add at least 1 
node first");
 [ecj-lint] 
^^
 [ecj-lint] Resource leak: 'queryRequest' is not closed at this location
 [ecj-lint] --
 [ecj-lint] --
 [ecj-lint] 4. ERROR in 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-master/checkout/solr/core/src/java/org/apache/solr/core/SolrResourceLoader.java
 (at line 19)
 [ecj-lint] import javax.naming.Context;
 [ecj-lint]
 [ecj-lint] The type javax.naming.Context is not accessible
 [ecj-lint] --
 [ecj-lint] 5. ERROR in 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-master/checkout/solr/core/src/java/org/apache/solr/core/SolrResourceLoader.java
 (at line 20)
 [ecj-lint] import javax.naming.InitialContext;
 [ecj-lint]^^^
 [ecj-lint] The type javax.naming.InitialContext is not accessible
 [ecj-lint] --
 [ecj-lint] 6. ERROR in 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-master/checkout/solr/core/src/java/org/apache/solr/core/SolrResourceLoader.java
 (at line 21)
 [ecj-lint] import javax.naming.NamingException;
 [ecj-lint]
 [ecj-lint] The type javax.naming.NamingException is not accessible
 [ecj-lint] --
 [ecj-lint] 7. ERROR in 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-master/checkout/solr/core/src/java/org/apache/solr/core/SolrResourceLoader.java
 (at line 22)
 [ecj-lint] import javax.naming.NoInitialContextException;
 [ecj-lint]^^
 [ecj-lint] The type javax.naming.NoInitialContextException is not accessible
 [ecj-lint] --
 [ecj-lint] 8. ERROR in 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-master/checkout/solr/core/src/java/org/apache/solr/core/SolrResourceLoader.java
 (at line 776)
 [ecj-lint] Context c = new InitialContext();
 [ecj-lint] ^^^
 [ecj-lint] Context cannot be resolved to a type
 [ecj-lint] --
 [ecj-lint] 9. ERROR in 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-master/checkout/solr/core/src/java/org/apache/solr/core/SolrResourceLoader.java
 (at line 776)
 [ecj-lint] Context c = new InitialContext();
 [ecj-lint] ^^
 [ecj-lint] InitialContext cannot be resolved to a type
 [ecj-lint] --
 [ecj-lint] 10. ERROR in 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-master/checkout/solr/core/src/java/org/apache/solr/core/SolrResourceLoader.java
 (at line 779)
 [ecj-lint] } catch (NoInitialContextException e) {
 [ecj-lint]  ^
 [ecj-lint] NoInitialContextException cannot be resolved to a type
 [ecj-lint] --
 [ecj-lint] 11. ERROR in 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-master/checkout/solr/core/src/java/org/apache/solr/core/SolrResourceLoader.java
 (at line 781)
 [ecj-lint] } catch (NamingException e) {
 [ecj-lint]  ^^^
 [ecj-l

[jira] [Commented] (SOLR-13003) Query Result Cache does not honour maxRamBytes parameter

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-13003:


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

SOLR-13003: Fix WrapperModel method delegation.


> Query Result Cache does not honour maxRamBytes parameter
> 
>
> Key: SOLR-13003
> URL: https://issues.apache.org/jira/browse/SOLR-13003
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 7.3.1
>Reporter: Cetra Free
>Assignee: Andrzej Bialecki 
>Priority: Major
> Fix For: 8.2
>
> Attachments: CLRU-logging.patch, SOLR-13003.patch, 
> lrucacheexpanded.png, lrucachemaxmb.png, solr-core-7.3.1-SNAPSHOT.jar, 
> solrconfig.xml
>
>
> When using the maxRamBytes parameter with the queryResultCache directive, we 
> have seen the retained size of the cache orders of magnitude larger than what 
> is configured.
> Please see attached VisualVM output which shows the retained size is about 
> 1.5gb, but the maxRamBytes is set to 64mb.



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

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

[jira] [Commented] (SOLR-13003) Query Result Cache does not honour maxRamBytes parameter

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-13003:


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

SOLR-13003: Fix WrapperModel method delegation.


> Query Result Cache does not honour maxRamBytes parameter
> 
>
> Key: SOLR-13003
> URL: https://issues.apache.org/jira/browse/SOLR-13003
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 7.3.1
>Reporter: Cetra Free
>Assignee: Andrzej Bialecki 
>Priority: Major
> Fix For: 8.2
>
> Attachments: CLRU-logging.patch, SOLR-13003.patch, 
> lrucacheexpanded.png, lrucachemaxmb.png, solr-core-7.3.1-SNAPSHOT.jar, 
> solrconfig.xml
>
>
> When using the maxRamBytes parameter with the queryResultCache directive, we 
> have seen the retained size of the cache orders of magnitude larger than what 
> is configured.
> Please see attached VisualVM output which shows the retained size is about 
> 1.5gb, but the maxRamBytes is set to 64mb.



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

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

[jira] [Commented] (SOLR-13604) if updateLog isn't in config, complain loudly if it's needed for SolrCloud

[Andrzej Bialecki (JIRA)]

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

Andrzej Bialecki  commented on SOLR-13604:
--

+1. Even with single replica collections this should be an error because you 
can easily add more replicas after you've created the collection, at which 
point things will go south (even more).

> if updateLog isn't in config, complain loudly if it's needed for SolrCloud
> --
>
> Key: SOLR-13604
> URL: https://issues.apache.org/jira/browse/SOLR-13604
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Affects Versions: 7.1
>Reporter: David Smiley
>Priority: Minor
>
> The updateLog can be commented out, and SolrCloud will only contain this 
> error:
> 2019-07-03 16:15:55.907 ERROR (qtp214649627-92) [c:gettingstarted s:shard1 
> r:core_node4 x:gettingstarted_shard1_replica_n2] o.a.s.c.SyncStrategy No 
> UpdateLog found - cannot sync
> I suspect it's truly required in which Solr should complain more loudly about 
> this -- throw an exception.  For single replica collections, I suppose it's 
> fine (not an error?)?  Granted then there could be an issue of adding 
> replicas later (unless pull type; those are fine).  Even if multi-replica 
> SolrCloud can usefully work without an updateLog (news to me) then maybe we 
> shouldn't log an error, although the lack of an updateLog would probably be 
> an oversight that would be hard to track down the root cause of.
> I wish the updateLog altogether could be more optional but that's another 
> conversation.



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

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

[jira] [Updated] (SOLR-13507) Remove support for "addr" parameter from the "/solr/admin/zookeeper" endpoint.

[Anshum Gupta (JIRA)]

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

Anshum Gupta updated SOLR-13507:

Fix Version/s: 8.2

> Remove support for "addr" parameter from the "/solr/admin/zookeeper" endpoint.
> --
>
> Key: SOLR-13507
> URL: https://issues.apache.org/jira/browse/SOLR-13507
> Project: Solr
>  Issue Type: Improvement
>Reporter: Anshum Gupta
>Assignee: Anshum Gupta
>Priority: Major
> Fix For: 8.2
>
> Attachments: SOLR-13507.02.patch, SOLR-13507.patch
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> The addr parameter isn't needed and it should be removed from the code.



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

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

[JENKINS] Lucene-Solr-8.x-Linux (64bit/jdk-12.0.1) - Build # 812 - Still Unstable!

[Policeman Jenkins Server]

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

1 tests failed.
FAILED:  
org.apache.solr.cloud.autoscaling.TestPolicyCloud.testCreateCollectionSplitShard

Error Message:
Timeout occurred while waiting response from server at: 
https://127.0.0.1:45953/solr

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: Timeout occurred while 
waiting response from server at: https://127.0.0.1:45953/solr
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.autoscaling.TestPolicyCloud.testCreateCollectionSplitShard(TestPolicyCloud.java:246)
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.junit.rules.ExpectedException$ExpectedExceptionStatement.evaluate(ExpectedException.java:239)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:947)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
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.e

[jira] [Commented] (SOLR-13507) Remove support for "addr" parameter from the "/solr/admin/zookeeper" endpoint.

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-13507:


Commit b7090d9c25ba430442628b0dc77c7c700cb35b33 in lucene-solr's branch 
refs/heads/master from Anshum Gupta
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=b7090d9 ]

SOLR-13507: Remove support for addr parameter from the /solr/admin/zookeeper 
endpoint. (#759)



> Remove support for "addr" parameter from the "/solr/admin/zookeeper" endpoint.
> --
>
> Key: SOLR-13507
> URL: https://issues.apache.org/jira/browse/SOLR-13507
> Project: Solr
>  Issue Type: Improvement
>Reporter: Anshum Gupta
>Assignee: Anshum Gupta
>Priority: Major
> Attachments: SOLR-13507.02.patch, SOLR-13507.patch
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> The addr parameter isn't needed and it should be removed from the code.



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

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

[GitHub] [lucene-solr] anshumg merged pull request #759: SOLR-13507: Remove support for addr parameter from the /solr/admin/zookeeper endpoint.

[GitBox]

anshumg merged pull request #759: SOLR-13507: Remove support for addr parameter 
from the /solr/admin/zookeeper endpoint.
URL: https://github.com/apache/lucene-solr/pull/759
 
 
   


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-master-MacOSX (64bit/jdk-12.0.1) - Build # 5237 - Still Unstable!

[Policeman Jenkins Server]

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

10 tests failed.
FAILED:  
org.apache.solr.ltr.model.TestWrapperModel.testMethodOverridesAndDelegation

Error Message:
class org.apache.solr.ltr.model.WrapperModel needs to override 'public long 
org.apache.solr.ltr.model.LTRScoringModel.ramBytesUsed()'

Stack Trace:
java.lang.AssertionError: class org.apache.solr.ltr.model.WrapperModel needs to 
override 'public long org.apache.solr.ltr.model.LTRScoringModel.ramBytesUsed()'
at 
__randomizedtesting.SeedInfo.seed([DCBEABC613445463:D9417766AE8C112A]:0)
at org.junit.Assert.fail(Assert.java:88)
at 
org.apache.solr.ltr.model.TestWrapperModel.testOverwrittenMethods(TestWrapperModel.java:205)
at 
org.apache.solr.ltr.model.TestWrapperModel.testMethodOverridesAndDelegation(TestWrapperModel.java:169)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:567)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:947)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.base/java.lang.Thread.run(Thread.java:835)


FAILED:  
org.apache.solr.ltr.model

Re: 8.1.2 bug fix release

[Anshum Gupta]

Hi Dat,

Can we also get SOLR-13507
 in for 8.1.2 ?

On Wed, Jul 3, 2019 at 4:55 AM Đạt Cao Mạnh  wrote:

> Thanks Andrzej!
>
> On Wed, Jul 3, 2019 at 6:41 PM Andrzej Białecki  wrote:
>
>> Dat,
>>
>> The fix for SOLR-13583 has been committed to branch_8_1.
>>
>> On 3 Jul 2019, at 04:56, Đạt Cao Mạnh  wrote:
>>
>> Hi Steve,
>>
>> I'm seeing this failure
>>
>> [smoker] subprocess.CalledProcessError: Command 'export
>> JAVA_HOME="/home/jenkins/tools/java/latest1.9"
>> PATH="/home/jenkins/tools/java/latest1.9/bin:$PATH"
>> JAVACMD="/home/jenkins/tools/java/latest1.9/bin/java"; java -version'
>> returned non-zero exit status 127
>> on
>>
>> https://builds.apache.org/view/L/view/Lucene/job/Lucene-Solr-SmokeRelease-8.1/49/console
>>
>> It seems that the /home/jenkins/tools/java/latest1.9/bin does not
>> present in the system. Can you work on this, if that is not possible can
>> you show me how I can connect to that jenkins box?
>>
>> Thanks a lot!
>>
>> On Wed, Jul 3, 2019 at 9:52 AM Đạt Cao Mạnh 
>> wrote:
>>
>>> Hi guys,
>>>
>>> I'm seeing several Lucene test failures for branch_8_1. Should they be
>>> marked as badApples?
>>>
>>> https://builds.apache.org/view/L/view/Lucene/job/Lucene-Solr-Tests-8.1/73/
>>>
>>> https://builds.apache.org/view/L/view/Lucene/job/Lucene-Solr-NightlyTests-8.1/49/
>>>
>>>
>>> On Fri, Jun 28, 2019 at 11:28 PM Ignacio Vera  wrote:
>>>
 Thanks! it is done.

 On Fri, Jun 28, 2019 at 5:19 PM Đạt Cao Mạnh 
 wrote:

> Ok, I'm hoping these two are these last ones.
>

>>>
>>> --
>>> *Best regards,*
>>> *Cao Mạnh Đạt*
>>> *E-mail: caomanhdat...@gmail.com *
>>>
>>
>>
>> --
>> *Best regards,*
>> *Cao Mạnh Đạt*
>> *E-mail: caomanhdat...@gmail.com *
>>
>>
>>
>
> --
> *Best regards,*
> *Cao Mạnh Đạt*
> *E-mail: caomanhdat...@gmail.com *
>


-- 
Anshum Gupta

Re: 8.1.2 bug fix release

[Uwe Schindler]

Thanks!

I was about to look for this.

Uwe

Am July 3, 2019 4:47:45 PM UTC schrieb Steve Rowe :
>I created https://issues.apache.org/jira/browse/INFRA-18701
> to ask Infra for
>help.  Looks like a borked Java9 JDK installation.
>
>> On Jul 3, 2019, at 12:24 PM, Steve Rowe  wrote:
>> 
>> Hi Đạt,
>> 
>> I'll look into it.  (FYI Uwe has more experience with Jenkins
>toolchain juggling.)
>> 
>> You'll have to contact Infra to request login access to that box -
>IIRC: I provided them with a public key so that I could log in, and
>then an entry was added to sudoers to allow me to run commands as the
>jenkins user.  (Uwe also has this kind of access there.)
>> 
>> I'm surprised we're still testing with Java9; I though we had
>switched to Java11 testing?  Maybe not on branch_8_1 though.
>> 
>> Steve
>> 
>>> On Jul 2, 2019, at 10:56 PM, Đạt Cao Mạnh > wrote:
>>> 
>>> Hi Steve,
>>> 
>>> I'm seeing this failure
>>> 
>>> [smoker] subprocess.CalledProcessError: Command 'export
>JAVA_HOME="/home/jenkins/tools/java/latest1.9"
>PATH="/home/jenkins/tools/java/latest1.9/bin:$PATH"
>JAVACMD="/home/jenkins/tools/java/latest1.9/bin/java"; java -version'
>returned non-zero exit status 127
>>> on
>>>
>https://builds.apache.org/view/L/view/Lucene/job/Lucene-Solr-SmokeRelease-8.1/49/console
>
>>> 
>>> It seems that the /home/jenkins/tools/java/latest1.9/bin does not
>present in the system. Can you work on this, if that is not possible
>can you show me how I can connect to that jenkins box?
>>> 
>>> Thanks a lot!
>>> 
>>> On Wed, Jul 3, 2019 at 9:52 AM Đạt Cao Mạnh > wrote:
>>> Hi guys,
>>> 
>>> I'm seeing several Lucene test failures for branch_8_1. Should they
>be marked as badApples?
>>>
>https://builds.apache.org/view/L/view/Lucene/job/Lucene-Solr-Tests-8.1/73/
>
>>>
>https://builds.apache.org/view/L/view/Lucene/job/Lucene-Solr-NightlyTests-8.1/49/
>
>>> 
>>> 
>>> On Fri, Jun 28, 2019 at 11:28 PM Ignacio Vera > wrote:
>>> Thanks! it is done.
>>> 
>>> On Fri, Jun 28, 2019 at 5:19 PM Đạt Cao Mạnh
>mailto:caomanhdat...@gmail.com>> wrote:
>>> Ok, I'm hoping these two are these last ones.
>>> 
>>> 
>>> -- 
>>> Best regards,
>>> Cao Mạnh Đạt
>>> E-mail: caomanhdat...@gmail.com 
>>> 
>>> 
>>> -- 
>>> Best regards,
>>> Cao Mạnh Đạt
>>> E-mail: caomanhdat...@gmail.com 
>> 

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

Re: 8.1.2 bug fix release

[Steve Rowe]

I created https://issues.apache.org/jira/browse/INFRA-18701 
 to ask Infra for help.  
Looks like a borked Java9 JDK installation.

> On Jul 3, 2019, at 12:24 PM, Steve Rowe  wrote:
> 
> Hi Đạt,
> 
> I'll look into it.  (FYI Uwe has more experience with Jenkins toolchain 
> juggling.)
> 
> You'll have to contact Infra to request login access to that box - IIRC: I 
> provided them with a public key so that I could log in, and then an entry was 
> added to sudoers to allow me to run commands as the jenkins user.  (Uwe also 
> has this kind of access there.)
> 
> I'm surprised we're still testing with Java9; I though we had switched to 
> Java11 testing?  Maybe not on branch_8_1 though.
> 
> Steve
> 
>> On Jul 2, 2019, at 10:56 PM, Đạt Cao Mạnh > > wrote:
>> 
>> Hi Steve,
>> 
>> I'm seeing this failure
>> 
>> [smoker] subprocess.CalledProcessError: Command 'export 
>> JAVA_HOME="/home/jenkins/tools/java/latest1.9" 
>> PATH="/home/jenkins/tools/java/latest1.9/bin:$PATH" 
>> JAVACMD="/home/jenkins/tools/java/latest1.9/bin/java"; java -version' 
>> returned non-zero exit status 127
>> on
>> https://builds.apache.org/view/L/view/Lucene/job/Lucene-Solr-SmokeRelease-8.1/49/console
>>  
>> 
>> 
>> It seems that the /home/jenkins/tools/java/latest1.9/bin does not present in 
>> the system. Can you work on this, if that is not possible can you show me 
>> how I can connect to that jenkins box?
>> 
>> Thanks a lot!
>> 
>> On Wed, Jul 3, 2019 at 9:52 AM Đạt Cao Mạnh > > wrote:
>> Hi guys,
>> 
>> I'm seeing several Lucene test failures for branch_8_1. Should they be 
>> marked as badApples?
>> https://builds.apache.org/view/L/view/Lucene/job/Lucene-Solr-Tests-8.1/73/ 
>> 
>> https://builds.apache.org/view/L/view/Lucene/job/Lucene-Solr-NightlyTests-8.1/49/
>>  
>> 
>> 
>> 
>> On Fri, Jun 28, 2019 at 11:28 PM Ignacio Vera > > wrote:
>> Thanks! it is done.
>> 
>> On Fri, Jun 28, 2019 at 5:19 PM Đạt Cao Mạnh > > wrote:
>> Ok, I'm hoping these two are these last ones.
>> 
>> 
>> -- 
>> Best regards,
>> Cao Mạnh Đạt
>> E-mail: caomanhdat...@gmail.com 
>> 
>> 
>> -- 
>> Best regards,
>> Cao Mạnh Đạt
>> E-mail: caomanhdat...@gmail.com 
> 

[jira] [Created] (SOLR-13604) if updateLog isn't in config, complain loudly if it's needed for SolrCloud

[David Smiley (JIRA)]

David Smiley created SOLR-13604:
---

 Summary: if updateLog isn't in config, complain loudly if it's 
needed for SolrCloud
 Key: SOLR-13604
 URL: https://issues.apache.org/jira/browse/SOLR-13604
 Project: Solr
  Issue Type: Improvement
  Security Level: Public (Default Security Level. Issues are Public)
  Components: SolrCloud
Affects Versions: 7.1
Reporter: David Smiley


The updateLog can be commented out, and SolrCloud will only contain this error:

2019-07-03 16:15:55.907 ERROR (qtp214649627-92) [c:gettingstarted s:shard1 
r:core_node4 x:gettingstarted_shard1_replica_n2] o.a.s.c.SyncStrategy No 
UpdateLog found - cannot sync

I suspect it's truly required in which Solr should complain more loudly about 
this -- throw an exception.  For single replica collections, I suppose it's 
fine (not an error?)?  Granted then there could be an issue of adding replicas 
later (unless pull type; those are fine).  Even if multi-replica SolrCloud can 
usefully work without an updateLog (news to me) then maybe we shouldn't log an 
error, although the lack of an updateLog would probably be an oversight that 
would be hard to track down the root cause of.

I wish the updateLog altogether could be more optional but that's another 
conversation.



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

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

Re: 8.1.2 bug fix release

[Steve Rowe]

Hi Đạt,

I'll look into it.  (FYI Uwe has more experience with Jenkins toolchain 
juggling.)

You'll have to contact Infra to request login access to that box - IIRC: I 
provided them with a public key so that I could log in, and then an entry was 
added to sudoers to allow me to run commands as the jenkins user.  (Uwe also 
has this kind of access there.)

I'm surprised we're still testing with Java9; I though we had switched to 
Java11 testing?  Maybe not on branch_8_1 though.

Steve

> On Jul 2, 2019, at 10:56 PM, Đạt Cao Mạnh  wrote:
> 
> Hi Steve,
> 
> I'm seeing this failure
> 
> [smoker] subprocess.CalledProcessError: Command 'export 
> JAVA_HOME="/home/jenkins/tools/java/latest1.9" 
> PATH="/home/jenkins/tools/java/latest1.9/bin:$PATH" 
> JAVACMD="/home/jenkins/tools/java/latest1.9/bin/java"; java -version' 
> returned non-zero exit status 127
> on
> https://builds.apache.org/view/L/view/Lucene/job/Lucene-Solr-SmokeRelease-8.1/49/console
>  
> 
> 
> It seems that the /home/jenkins/tools/java/latest1.9/bin does not present in 
> the system. Can you work on this, if that is not possible can you show me how 
> I can connect to that jenkins box?
> 
> Thanks a lot!
> 
> On Wed, Jul 3, 2019 at 9:52 AM Đạt Cao Mạnh  > wrote:
> Hi guys,
> 
> I'm seeing several Lucene test failures for branch_8_1. Should they be marked 
> as badApples?
> https://builds.apache.org/view/L/view/Lucene/job/Lucene-Solr-Tests-8.1/73/ 
> 
> https://builds.apache.org/view/L/view/Lucene/job/Lucene-Solr-NightlyTests-8.1/49/
>  
> 
> 
> 
> On Fri, Jun 28, 2019 at 11:28 PM Ignacio Vera  > wrote:
> Thanks! it is done.
> 
> On Fri, Jun 28, 2019 at 5:19 PM Đạt Cao Mạnh  > wrote:
> Ok, I'm hoping these two are these last ones.
> 
> 
> -- 
> Best regards,
> Cao Mạnh Đạt
> E-mail: caomanhdat...@gmail.com 
> 
> 
> -- 
> Best regards,
> Cao Mạnh Đạt
> E-mail: caomanhdat...@gmail.com 

[jira] [Commented] (SOLR-13003) Query Result Cache does not honour maxRamBytes parameter

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-13003:


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

SOLR-13003: Query Result Cache does not honour maxRamBytes parameter.


> Query Result Cache does not honour maxRamBytes parameter
> 
>
> Key: SOLR-13003
> URL: https://issues.apache.org/jira/browse/SOLR-13003
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 7.3.1
>Reporter: Cetra Free
>Assignee: Andrzej Bialecki 
>Priority: Major
> Fix For: 8.2
>
> Attachments: CLRU-logging.patch, SOLR-13003.patch, 
> lrucacheexpanded.png, lrucachemaxmb.png, solr-core-7.3.1-SNAPSHOT.jar, 
> solrconfig.xml
>
>
> When using the maxRamBytes parameter with the queryResultCache directive, we 
> have seen the retained size of the cache orders of magnitude larger than what 
> is configured.
> Please see attached VisualVM output which shows the retained size is about 
> 1.5gb, but the maxRamBytes is set to 64mb.



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

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

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

[Policeman Jenkins Server]

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

10 tests failed.
FAILED:  
org.apache.solr.cloud.TestConfigSetsAPI.testUserAndTestDefaultConfigsetsAreSame

Error Message:
Mismatch in files expected:<..._es.txt, stopwords_e[t.txt, stopwords_e]u.txt, 
stopwords_fa> but was:<..._es.txt, stopwords_e[]u.txt, stopwords_fa>

Stack Trace:
org.junit.ComparisonFailure: Mismatch in files expected:<..._es.txt, 
stopwords_e[t.txt, stopwords_e]u.txt, stopwords_fa> but was:<..._es.txt, 
stopwords_e[]u.txt, stopwords_fa>
at 
__randomizedtesting.SeedInfo.seed([C447F13A7AD832CF:CED5A8E61277906C]:0)
at org.junit.Assert.assertEquals(Assert.java:115)
at 
org.apache.solr.cloud.TestConfigSetsAPI$1.preVisitDirectory(TestConfigSetsAPI.java:720)
at 
org.apache.solr.cloud.TestConfigSetsAPI$1.preVisitDirectory(TestConfigSetsAPI.java:710)
at java.base/java.nio.file.Files.walkFileTree(Files.java:2808)
at java.base/java.nio.file.Files.walkFileTree(Files.java:2873)
at 
org.apache.solr.cloud.TestConfigSetsAPI.compareDirectories(TestConfigSetsAPI.java:710)
at 
org.apache.solr.cloud.TestConfigSetsAPI.testUserAndTestDefaultConfigsetsAreSame(TestConfigSetsAPI.java:701)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:567)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:947)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)

[jira] [Commented] (LUCENE-8895) Switch all FSTs to use direct addressing optimization

[Mike Sokolov (JIRA)]

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

Mike Sokolov commented on LUCENE-8895:
--

Ah yes, thanks! I now deprecated the other one too.

> Switch all FSTs to use direct addressing optimization
> -
>
> Key: LUCENE-8895
> URL: https://issues.apache.org/jira/browse/LUCENE-8895
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Mike Sokolov
>Priority: Major
> Fix For: 8.2
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> See discussion in LUCENE-8781 about turning on array-with-gaps encoding 
> everywhere. Let's conduct any further discussion here so we can use an open 
> issue.



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

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

[jira] [Comment Edited] (LUCENE-7745) Explore GPU acceleration

[Rinka Singh (JIRA)]

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

Rinka Singh edited comment on LUCENE-7745 at 7/3/19 3:56 PM:
-

{quote}The basic idea is to compute sub-histograms in each thread block with 
each thread block accumulating into the local memory. Then, when each thread 
block finishes its workload, it atomically adds the result to global memory, 
reducing the overall amount of traffic to global memory.To increase throughput 
and reduce shared memory contention, the main contribution here is that they 
actually use R "replicated" sub-histograms in each thread block, and they 
offset them so that bin 0 of the 1st histogram falls into a different memory 
bank than bin 0 of the 2nd histogram, and so on for R histograms. Essentially, 
it improves throughput in the degenerate case where multiple threads are trying 
to accumulate the same histogram bin at the same time.
{quote}
So here's what I've done/am doing:

I have a basic histogramming (including eliminating stop words) working on a 
single GPU  (I have an old Quadro 2000 with 1 GB memory) - I've tested it for a 
5MB (text file) and it seems to be working OK.

The following is how I'm implementing it - briefly.

Read a file in from command line (linux executable) into the GPU
 * convert the stream to words, chunk them into blocks
 * eliminate the stop words
 * sort/merge (including word-count) everything first inside a block and then 
across blocks - I came up with my own sort - haven't had the time to explore 
the parallel sorts out there
 * This results in a sorted histogram is held in multiple blocks in the GPU.

The advantages of this approach (to my mind) are:
 * i can scale up use the entire GPU memory.  My guess is I can create and 
manage an 8-10 GB index in a V100 (it has 32GB) - like I said, I've only tested 
with a 5 MB text file so far.
 * Easy to add fresh data into the existing histogram.  All I need to do is 
create new blocks and sort/merge them all.
 * I'm guessing this should make it easy to implement scaling across GPUs which 
means on a multi-GPU machine, I can scale to the almost the number of GPUs 
there and then of course one can setup a cluster of such machines...  This is 
far in the future though...
 * The sort is kept separate so we can experiment with various sorts and see 
which one performs best.

 

The issues are:
 * It is currently horrendously slow (I use global memory all the way and no 
optimization).  Well OK much too slow for my liking (I went over to nVidia's 
office and tested it on a K80 and it was just twice as fast as my GPU).  I'm 
currently trying to implement a shared memory version (and a few other tweaks) 
that should speed it up.
 * I have yet to do comparisons with the histogramming tools out there and so 
cannot say how much better it is.  Once I have the basic inverted index in 
place, I'll reach out to you all for the testing.
 * It is still a bit fragile - I'm still finding bugs as I test but the basic 
works.

 

Currently in process:
 * code is modified for (some) performance.  Am debugging/testing - it will 
take a while.  As of now, I feel good about what I've done but I won't know 
till I get it to work and test for performance.
 * Need to add ability to handle multiple files (I think I will postpone this 
as one can always cat the files together and pass it in - that is a pretty 
simple script that can be wrapped around the executable).
 * Need to create inverted index.
 * we'll worry about searching on the index later but that should be pretty 
trivial - well actually nothing is trivial here.

 
{quote}Re: efficient histogram implementation in CUDA

If it helps, [this 
approach|https://scholar.google.com/scholar?cluster=4154868272073145366&hl=en&as_sdt=0,3]
 has been good for a balance between GPU performance and ease of implementation 
for work I've done in the past. If academic paywalls block you for all those 
results, it looks to also be available (presumably by the authors) on 
[researchgate|https://www.researchgate.net/publication/256674650_An_optimized_approach_to_histogram_computation_on_GPU]
{quote}
 Took a quick look - they are all priced products.  I will take a look at 
researchgate sometime.

I apologize but I may not be very responsive in the next month or so as we are 
in the middle of a release at work and also my night time job (this).


was (Author: rinka):
{quote}The basic idea is to compute sub-histograms in each thread block with 
each thread block accumulating into the local memory. Then, when each thread 
block finishes its workload, it atomically adds the result to global memory, 
reducing the overall amount of traffic to global memory.To increase throughput 
and reduce shared memory contention, the main contribution here is that they 
actually use R "replicated" sub-histograms in each threa

[jira] [Commented] (LUCENE-7745) Explore GPU acceleration

[Rinka Singh (JIRA)]

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

Rinka Singh commented on LUCENE-7745:
-

{quote}The basic idea is to compute sub-histograms in each thread block with 
each thread block accumulating into the local memory. Then, when each thread 
block finishes its workload, it atomically adds the result to global memory, 
reducing the overall amount of traffic to global memory.To increase throughput 
and reduce shared memory contention, the main contribution here is that they 
actually use R "replicated" sub-histograms in each thread block, and they 
offset them so that bin 0 of the 1st histogram falls into a different memory 
bank than bin 0 of the 2nd histogram, and so on for R histograms. Essentially, 
it improves throughput in the degenerate case where multiple threads are trying 
to accumulate the same histogram bin at the same time.
{quote}
So here's what I've done/am doing:

I have a basic histogramming (including eliminating stop words) working on a 
single GPU  (I have an old Quadro 2000 with 1 GB memory) - I've tested it for a 
5MB (text file) and it seems to be working OK.

The following is how I'm implementing it - briefly.

Read a file in from command line (linux executable) into the GPU
 * convert the stream to words, chunk them into blocks
 * eliminate the stop words
 * sort/merge (including word-count) everything first inside a block and then 
across blocks - I came up with my own sort - haven't had the time to explore 
the parallel sorts out there
 * This results in a sorted histogram is held in multiple blocks in the GPU.

The advantages of this approach (to my mind) are:
 * i can scale up use the entire GPU memory.  My guess is I can create and 
manage an 8-10 GB index in a V100 (it has 32GB) - like I said, I've only tested 
with a 5 MB text file so far.
 * Easy to add fresh data into the existing histogram.  All I need to do is 
create new blocks and sort/merge them all.
 * I'm guessing this should make it easy to implement scaling across GPUs which 
means on a multi-GPU machine, I can scale to the almost the number of GPUs 
there and then of course one can setup a cluster of such machines...  This is 
far in the future though...
 * The sort is kept separate so we can experiment with various sorts and see 
which one performs best.

 

The issues are:
 * It is currently horrendously slow (I use global memory all the way and no 
optimization).  Well OK much too slow for my liking (I went over to nVidia's 
office and tested it on a K80 and it was just twice as fast as my GPU).  I'm 
currently trying to implement a shared memory version (and a few other tweaks) 
that should speed it up.
 * I have yet to do comparisons with the histogramming tools out there and so 
cannot say how much better it is.  Once I have the basic inverted index in 
place, I'll reach out to you all for the testing.
 * It is still a bit fragile - I'm still finding bugs as I test but the basic 
works.

 

Currently in process:
 * code is modified for (some) performance.  Am debugging/testing - it will 
take a while.  As of now, I feel good about what I've done but I won't know 
till I test for performance.
 * Need to add ability to handle multiple files (I think I will postpone this 
as one can always cat the files together and pass it in - that is a pretty 
simple script that can be wrapped around the executable).
 * Need to create inverted index.
 * we'll worry about searching on the index later but that should be pretty 
trivial - well actually nothing is trivial here.

 
{quote}Re: efficient histogram implementation in CUDA

If it helps, [this 
approach|https://scholar.google.com/scholar?cluster=4154868272073145366&hl=en&as_sdt=0,3]
 has been good for a balance between GPU performance and ease of implementation 
for work I've done in the past. If academic paywalls block you for all those 
results, it looks to also be available (presumably by the authors) on 
[researchgate|https://www.researchgate.net/publication/256674650_An_optimized_approach_to_histogram_computation_on_GPU]
{quote}
 Took a quick look - they are all priced products.  I will take a look at 
researchgate sometime.

I apologize but I may not be very responsive in the next month or so as we are 
in the middle of a release at work and also my night time job (this).

> Explore GPU acceleration
> 
>
> Key: LUCENE-7745
> URL: https://issues.apache.org/jira/browse/LUCENE-7745
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Ishan Chattopadhyaya
>Assignee: Ishan Chattopadhyaya
>Priority: Major
>  Labels: gsoc2017, mentor
> Attachments: TermDisjunctionQuery.java, gpu-benchmarks.png
>
>
> There are parts of Lucene that can potentially be speeded up if comp

[jira] [Commented] (LUCENE-8900) Simplify MultiSorter

[Namgyu Kim (JIRA)]

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

Namgyu Kim commented on LUCENE-8900:


Oh, about the suggestion 2, I saw it wrong.
It can cause a ClassCastException :(

Sorry for confusing and thank you for taking the suggestion 1.

> Simplify MultiSorter
> 
>
> Key: LUCENE-8900
> URL: https://issues.apache.org/jira/browse/LUCENE-8900
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Adrien Grand
>Priority: Minor
> Attachments: LUCENE-8900.patch
>
>




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

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

[jira] [Updated] (SOLR-13596) Remove deprecated grouping methods

[Munendra S N (JIRA)]

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

Munendra S N updated SOLR-13596:

   Resolution: Done
 Assignee: Munendra S N
Fix Version/s: master (9.0)
   Status: Resolved  (was: Patch Available)

Methods are removed only from master

> Remove deprecated grouping methods
> --
>
> Key: SOLR-13596
> URL: https://issues.apache.org/jira/browse/SOLR-13596
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Munendra S N
>Assignee: Munendra S N
>Priority: Major
> Fix For: master (9.0)
>
> Attachments: SOLR-13596.patch
>
>
> As part of SOLR-9660, few of the methods in GroupingSpecification are 
> deprecated. Remove these methods and their usages



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

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

[jira] [Commented] (SOLR-13596) Remove deprecated grouping methods

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-13596:


Commit 96860eb18198492c09bad1731a7715385a02 in lucene-solr's branch 
refs/heads/master from Munendra S N
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=96860eb ]

SOLR-13596: remove deprecated groupSpec methods


> Remove deprecated grouping methods
> --
>
> Key: SOLR-13596
> URL: https://issues.apache.org/jira/browse/SOLR-13596
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Munendra S N
>Priority: Major
> Attachments: SOLR-13596.patch
>
>
> As part of SOLR-9660, few of the methods in GroupingSpecification are 
> deprecated. Remove these methods and their usages



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

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

[jira] [Commented] (LUCENE-8311) Leverage impacts for phrase queries

[Adrien Grand (JIRA)]

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

Adrien Grand commented on LUCENE-8311:
--

I opened https://github.com/apache/lucene-solr/pull/760. Performance is a bit 
better than what we had before:

{noformat}
TaskQPS baseline  StdDev   QPS patch  StdDev
Pct diff
HighTerm 1395.12  (5.1%) 1230.78  (4.3%)  
-11.8% ( -20% -   -2%)
 MedTerm 2352.56  (4.7%) 2170.42  (3.9%)   
-7.7% ( -15% -0%)
 LowSpanNear   13.70  (7.0%)   12.67  (4.9%)   
-7.5% ( -18% -4%)
HighSpanNear5.69  (5.3%)5.31  (3.2%)   
-6.5% ( -14% -2%)
 MedSpanNear   23.33  (4.2%)   21.97  (2.4%)   
-5.8% ( -11% -0%)
  AndHighMed  114.70  (2.9%)  109.40  (4.1%)   
-4.6% ( -11% -2%)
 AndHighHigh   35.08  (3.2%)   33.51  (4.1%)   
-4.5% ( -11% -2%)
 LowTerm 3014.11  (4.7%) 2893.44  (4.7%)   
-4.0% ( -12% -5%)
   OrHighMed   60.26  (2.5%)   57.96  (2.1%)   
-3.8% (  -8% -0%)
  OrHighHigh   15.45  (2.5%)   14.87  (2.3%)   
-3.8% (  -8% -1%)
   LowPhrase   25.81  (3.4%)   24.89  (2.8%)   
-3.6% (  -9% -2%)
HighSloppyPhrase7.44  (6.3%)7.20  (5.7%)   
-3.3% ( -14% -9%)
 MedSloppyPhrase   12.76  (5.1%)   12.51  (4.6%)   
-1.9% ( -10% -8%)
 LowSloppyPhrase   34.24  (4.1%)   33.59  (3.8%)   
-1.9% (  -9% -6%)
   HighTermMonthSort   70.86 (10.9%)   69.98 (10.7%)   
-1.2% ( -20% -   22%)
  Fuzzy1  211.28  (3.5%)  208.86  (2.2%)   
-1.1% (  -6% -4%)
  Fuzzy2  180.97  (4.4%)  179.47  (2.6%)   
-0.8% (  -7% -6%)
   OrHighLow  467.25  (2.9%)  467.94  (2.0%)
0.1% (  -4% -5%)
 Prefix3   91.35  (8.1%)   91.52  (7.2%)
0.2% ( -14% -   16%)
   HighTermDayOfYearSort   62.77  (6.9%)   62.96  (7.5%)
0.3% ( -13% -   15%)
Wildcard  129.49  (4.3%)  129.99  (2.8%)
0.4% (  -6% -7%)
 Respell  210.68  (1.9%)  211.58  (2.4%)
0.4% (  -3% -4%)
  AndHighLow  541.64  (3.1%)  544.44  (3.2%)
0.5% (  -5% -7%)
  IntNRQ  148.56  (8.3%)  149.44 (10.4%)
0.6% ( -16% -   21%)
  HighPhrase   10.86  (9.0%)   13.92 (15.2%)   
28.2% (   3% -   57%)
   MedPhrase   62.22  (2.1%)   97.61  (4.6%)   
56.9% (  49% -   64%)
{noformat}

But there is a lot of variance across runs because it depends a lot on which 
query gets picked up. For instance on another run I got

{noformat}
   LowPhrase   39.39  (1.9%)   51.21  (2.2%)   
30.0% (  25% -   34%)
  HighPhrase   13.09  (3.2%)  192.76 (26.8%) 
1372.5% (1301% - 1448%)
{noformat}

In spite of some queries that get slightly slower, I think we should merge this 
since we need phrases to expose good impacts if we want to give boolean queries 
a chance to speed up queries that include phrases. Term queries appear to be a 
bit slower, I'm assuming that this is due to the fact that the JVM cannot do as 
much inlining as before since we are starting to use classes for phrases that 
were only used for term queries before.

> Leverage impacts for phrase queries
> ---
>
> Key: LUCENE-8311
> URL: https://issues.apache.org/jira/browse/LUCENE-8311
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Adrien Grand
>Priority: Minor
> Attachments: LUCENE-8311.patch
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Now that we expose raw impacts, we could leverage them for phrase queries.
> For instance for exact phrases, we could take the minimum term frequency for 
> each unique norm value in order to get upper bounds of the score for the 
> phrase.



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

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

Re: [JENKINS] Lucene-Solr-8.x-Linux (64bit/jdk-12.0.1) - Build # 811 - Unstable!

[Tomoko Uchida]

I forgot to update _default schema file for tests. The schema was fixed.
Thanks @ab for letting me know.

Tomoko

2019年7月3日(水) 23:17 Policeman Jenkins Server :
>
> Build: https://jenkins.thetaphi.de/job/Lucene-Solr-8.x-Linux/811/
> Java: 64bit/jdk-12.0.1 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC
>
> 4 tests failed.
> FAILED:  
> org.apache.solr.cloud.TestConfigSetsAPI.testUserAndTestDefaultConfigsetsAreSame
>
> Error Message:
> Mismatch in files expected:<..._es.txt, stopwords_e[t.txt, stopwords_e]u.txt, 
> stopwords_fa> but was:<..._es.txt, stopwords_e[]u.txt, stopwords_fa>
>
> Stack Trace:
> org.junit.ComparisonFailure: Mismatch in files expected:<..._es.txt, 
> stopwords_e[t.txt, stopwords_e]u.txt, stopwords_fa> but was:<..._es.txt, 
> stopwords_e[]u.txt, stopwords_fa>
> at 
> __randomizedtesting.SeedInfo.seed([AE0C276FE5A8AE44:A49E7EB38D070CE7]:0)
> at org.junit.Assert.assertEquals(Assert.java:115)
> at 
> org.apache.solr.cloud.TestConfigSetsAPI$1.preVisitDirectory(TestConfigSetsAPI.java:720)
> at 
> org.apache.solr.cloud.TestConfigSetsAPI$1.preVisitDirectory(TestConfigSetsAPI.java:710)
> at java.base/java.nio.file.Files.walkFileTree(Files.java:2808)
> at java.base/java.nio.file.Files.walkFileTree(Files.java:2873)
> at 
> org.apache.solr.cloud.TestConfigSetsAPI.compareDirectories(TestConfigSetsAPI.java:710)
> at 
> org.apache.solr.cloud.TestConfigSetsAPI.testUserAndTestDefaultConfigsetsAreSame(TestConfigSetsAPI.java:701)
> at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at 
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:567)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988)
> at 
> com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
> at 
> org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
> at 
> org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
> at 
> org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
> at 
> org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
> at 
> org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
> at 
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
> at 
> com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
> at 
> com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
> at 
> com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:947)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894)
> at 
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
> at 
> com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
> at 
> org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
> at 
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
> at 
> org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
> at 
> com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
> at 
> com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
> at 
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
> at 
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36

[jira] [Commented] (LUCENE-8762) Lucene50PostingsReader should specialize reading docs+freqs with impacts

[Adrien Grand (JIRA)]

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

Adrien Grand commented on LUCENE-8762:
--

I proposed to change the specialization for docs+freqs+positions as part of 
LUCENE-8311. But it doesn't add any specialization for docs+freqs, which would 
still probably be worth adding?

> Lucene50PostingsReader should specialize reading docs+freqs with impacts
> 
>
> Key: LUCENE-8762
> URL: https://issues.apache.org/jira/browse/LUCENE-8762
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Adrien Grand
>Priority: Minor
>
> Currently if you ask for impacts, we only have one implementation that is 
> able to expose everything: docs, freqs, positions and offsets. In contrast, 
> if you don't need impacts, we have specialization for docs+freqs, 
> docs+freqs+positions and docs+freqs+positions+offsets.
> Maybe we should add specialization for the docs+freqs case with impacts, 
> which should be the most common case, and remove specialization for 
> docs+freqs+positions when impacts are not requested?



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

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

[GitHub] [lucene-solr] jpountz opened a new pull request #760: LUCENE-8311: Phrase impacts

[GitBox]

jpountz opened a new pull request #760: LUCENE-8311: Phrase impacts
URL: https://github.com/apache/lucene-solr/pull/760
 
 
   This PR adds and leverages impacts for phrase queries. It contains two 
commits that are unrelated but getting them at the same time helps preserve 
performance: currently impacts don't specialize at all. After doing some 
digging, I noticed that one reason why the change made things slower is that 
postings specialize both the docs(+freqs) and docs+freqs+positions cases, while 
impacts don't specialize anything at all. So I removed the specialization for 
docs+freqs+positions with postings and added specialization for 
docs+freqs+positions with impacts instead. The assumption is that phrases are 
more often used for ranking than for filtering.


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-13602) Add a field type for Estonian language to default managed_schema

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-13602:


Commit a471ece05bc0058b5ac683247809249acf92f703 in lucene-solr's branch 
refs/heads/branch_8x from Tomoko Uchida
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=a471ece ]

SOLR-13602: Update _default schema for unittests.


> Add a field type for Estonian language to default managed_schema
> 
>
> Key: SOLR-13602
> URL: https://issues.apache.org/jira/browse/SOLR-13602
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Tomoko Uchida
>Assignee: Tomoko Uchida
>Priority: Minor
> Fix For: master (9.0), 8.2
>
> Attachments: SOLR-13602.patch, SOLR-13602.patch, Screenshot from 
> 2019-07-03 20-44-46.png
>
>
> An analyzer for Estonian language have been added (LUCENE-8891).
> Default {{managed_schama}} should be updated to include a field type 
> corresponding to the {{EstonianAnalyzer}}.
> I will attach a patch soon.



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

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

[jira] [Commented] (SOLR-13602) Add a field type for Estonian language to default managed_schema

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-13602:


Commit 2e3e6c5944f4ca784c10583c155d11d36708d7b7 in lucene-solr's branch 
refs/heads/master from Tomoko Uchida
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=2e3e6c5 ]

SOLR-13602: Update _default schema for unittests.


> Add a field type for Estonian language to default managed_schema
> 
>
> Key: SOLR-13602
> URL: https://issues.apache.org/jira/browse/SOLR-13602
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Tomoko Uchida
>Assignee: Tomoko Uchida
>Priority: Minor
> Fix For: master (9.0), 8.2
>
> Attachments: SOLR-13602.patch, SOLR-13602.patch, Screenshot from 
> 2019-07-03 20-44-46.png
>
>
> An analyzer for Estonian language have been added (LUCENE-8891).
> Default {{managed_schama}} should be updated to include a field type 
> corresponding to the {{EstonianAnalyzer}}.
> I will attach a patch soon.



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

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

[JENKINS-EA] Lucene-Solr-8.x-Windows (64bit/jdk-13-ea+26) - Build # 346 - Unstable!

[Policeman Jenkins Server]

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

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

Error Message:
Expected rf=2 because batch should have succeeded on 2 replicas (only one 
replica should be down) but got 1; clusterState: {   "control_collection":{ 
"pullReplicas":"0", "replicationFactor":"1", "shards":{"shard1":{   
  "range":"8000-7fff", "state":"active", 
"replicas":{"core_node2":{ 
"core":"control_collection_shard1_replica_n1", 
"base_url":"http://127.0.0.1:62620/s";, 
"node_name":"127.0.0.1:62620_s", "state":"active", 
"type":"NRT", "leader":"true", 
"router":{"name":"compositeId"}, "maxShardsPerNode":"1", 
"autoAddReplicas":"false", "nrtReplicas":"1", "tlogReplicas":"0"},   
"repfacttest_c8n_1x3":{ "pullReplicas":"0", "replicationFactor":"3",
 "shards":{"shard1":{ "range":"8000-7fff", 
"state":"active", "replicas":{   "core_node4":{ 
"core":"repfacttest_c8n_1x3_shard1_replica_n1", 
"base_url":"http://127.0.0.1:62620/s";, 
"node_name":"127.0.0.1:62620_s", "state":"active", 
"type":"NRT", "leader":"true"},   "core_node5":{
 "core":"repfacttest_c8n_1x3_shard1_replica_n3", 
"base_url":"http://127.0.0.1:62724/s";, 
"node_name":"127.0.0.1:62724_s", "state":"active", 
"type":"NRT"},   "core_node6":{ 
"core":"repfacttest_c8n_1x3_shard1_replica_n2", 
"base_url":"http://127.0.0.1:62764/s";, 
"node_name":"127.0.0.1:62764_s", "state":"active", 
"type":"NRT", "router":{"name":"compositeId"}, 
"maxShardsPerNode":"1", "autoAddReplicas":"false", "nrtReplicas":"3",   
  "tlogReplicas":"0"},   "collection1":{ "pullReplicas":"0", 
"replicationFactor":"1", "shards":{   "shard1":{ 
"range":"8000-d554", "state":"active", 
"replicas":{"core_node5":{ "core":"collection1_shard1_replica_n3",  
   "base_url":"http://127.0.0.1:62764/s";, 
"node_name":"127.0.0.1:62764_s", "state":"active", 
"type":"NRT", "leader":"true"}}},   "shard2":{ 
"range":"d555-2aa9", "state":"active", 
"replicas":{"core_node6":{ "core":"collection1_shard2_replica_n2",  
   "base_url":"http://127.0.0.1:62684/s";, 
"node_name":"127.0.0.1:62684_s", "state":"active", 
"type":"NRT", "leader":"true"}}},   "shard3":{ 
"range":"2aaa-7fff", "state":"active", 
"replicas":{"core_node4":{ "core":"collection1_shard3_replica_n1",  
   "base_url":"http://127.0.0.1:62724/s";, 
"node_name":"127.0.0.1:62724_s", "state":"active", 
"type":"NRT", "leader":"true", 
"router":{"name":"compositeId"}, "maxShardsPerNode":"1", 
"autoAddReplicas":"false", "nrtReplicas":"1", "tlogReplicas":"0"}}

Stack Trace:
java.lang.AssertionError: Expected rf=2 because batch should have succeeded on 
2 replicas (only one replica should be down) but got 1; clusterState: {
  "control_collection":{
"pullReplicas":"0",
"replicationFactor":"1",
"shards":{"shard1":{
"range":"8000-7fff",
"state":"active",
"replicas":{"core_node2":{
"core":"control_collection_shard1_replica_n1",
"base_url":"http://127.0.0.1:62620/s";,
"node_name":"127.0.0.1:62620_s",
"state":"active",
"type":"NRT",
"leader":"true",
"router":{"name":"compositeId"},
"maxShardsPerNode":"1",
"autoAddReplicas":"false",
"nrtReplicas":"1",
"tlogReplicas":"0"},
  "repfacttest_c8n_1x3":{
"pullReplicas":"0",
"replicationFactor":"3",
"shards":{"shard1":{
"range":"8000-7fff",
"state":"active",
"replicas":{
  "core_node4":{
"core":"repfacttest_c8n_1x3_shard1_replica_n1",
"base_url":"http://127.0.0.1:62620/s";,
"node_name":"127.0.0.1:62620_s",
"state":"active",
"type":"NRT",
"leader":"true"},
  "core_node5":{
"core":"repfacttest_c8n_1x3_shard1_replica_n3",
"base_url":"http://127.0.0.1:62724/s";,
"node_name":"127.0.0.1:62724_s",
"state":"active",
"type":"NRT"},
  "core_node6":{
"core":"repfacttest_c8n_1x3_shard1_replica_n2",
"base_url":"http://127.0.0.1:62764/s";,
"node_name":"127.0.0.1:62764_s",
"state

[jira] [Commented] (SOLR-13003) Query Result Cache does not honour maxRamBytes parameter

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-13003:


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

SOLR-13003: Query Result Cache does not honour maxRamBytes parameter.


> Query Result Cache does not honour maxRamBytes parameter
> 
>
> Key: SOLR-13003
> URL: https://issues.apache.org/jira/browse/SOLR-13003
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 7.3.1
>Reporter: Cetra Free
>Assignee: Andrzej Bialecki 
>Priority: Major
> Fix For: 8.2
>
> Attachments: CLRU-logging.patch, SOLR-13003.patch, 
> lrucacheexpanded.png, lrucachemaxmb.png, solr-core-7.3.1-SNAPSHOT.jar, 
> solrconfig.xml
>
>
> When using the maxRamBytes parameter with the queryResultCache directive, we 
> have seen the retained size of the cache orders of magnitude larger than what 
> is configured.
> Please see attached VisualVM output which shows the retained size is about 
> 1.5gb, but the maxRamBytes is set to 64mb.



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

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

[jira] [Resolved] (LUCENE-8829) TopDocs#Merge is Tightly Coupled To Number Of Collectors Involved

[Atri Sharma (JIRA)]

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

Atri Sharma resolved LUCENE-8829.
-
Resolution: Fixed

Merged to master

> TopDocs#Merge is Tightly Coupled To Number Of Collectors Involved
> -
>
> Key: LUCENE-8829
> URL: https://issues.apache.org/jira/browse/LUCENE-8829
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Atri Sharma
>Priority: Major
> Attachments: LUCENE-8829.patch, LUCENE-8829.patch, LUCENE-8829.patch, 
> LUCENE-8829.patch
>
>
> While investigating LUCENE-8819, I understood that TopDocs#merge's order of 
> results are indirectly dependent on the number of collectors involved in the 
> merge. This is troubling because 1) The number of collectors involved in a 
> merge are cost based and directly dependent on the number of slices created 
> for the parallel searcher case. 2) TopN hits code path will invoke merge with 
> a single Collector, so essentially, doing the same TopN query with single 
> threaded and parallel threaded searcher will invoke different order of 
> results, which is a bad invariant that breaks.
>  
> The reason why this happens is because of the subtle way TopDocs#merge sets 
> shardIndex in the ScoreDoc population during populating the priority queue 
> used for merging. ShardIndex is essentially set to the ordinal of the 
> collector which generates the hit. This means that the shardIndex is 
> dependent on the number of collectors, even for the same set of hits.
>  
> In case of no sort order specified, shardIndex is used for tie breaking when 
> scores are equal. This translates to different orders for same hits with 
> different shardIndices.
>  
> I propose that we remove shardIndex from the default tie breaking mechanism 
> and replace it with docID. DocID order is the de facto that is expected 
> during collection, so it might make sense to use the same factor during tie 
> breaking when scores are the same.
>  
> CC: [~ivera]



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

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

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

[Atri Sharma (JIRA)]

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

Atri Sharma resolved LUCENE-8794.
-
Resolution: Fixed

Merged to master

> Cost Based Slice Allocation Algorithm
> -
>
> Key: LUCENE-8794
> URL: https://issues.apache.org/jira/browse/LUCENE-8794
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Atri Sharma
>Priority: Major
>
> In https://issues.apache.org/jira/browse/LUCENE-8757, the idea of a cost 
> based and dynamically adjusting slice allocation algorithm was conceived. We 
> should ideally have a hard cap on the number of threads that can be consumed 
> by a single query, and have static cost factors associated with segments and 
> assign them to threads in a fair manner. We will also need to ensure that we 
> end up not assigning individual threads to small segments, or making more 
> thread s that needed (thread context switching could outweight benefits).



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

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

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

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-8.x-Linux/811/
Java: 64bit/jdk-12.0.1 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC

4 tests failed.
FAILED:  
org.apache.solr.cloud.TestConfigSetsAPI.testUserAndTestDefaultConfigsetsAreSame

Error Message:
Mismatch in files expected:<..._es.txt, stopwords_e[t.txt, stopwords_e]u.txt, 
stopwords_fa> but was:<..._es.txt, stopwords_e[]u.txt, stopwords_fa>

Stack Trace:
org.junit.ComparisonFailure: Mismatch in files expected:<..._es.txt, 
stopwords_e[t.txt, stopwords_e]u.txt, stopwords_fa> but was:<..._es.txt, 
stopwords_e[]u.txt, stopwords_fa>
at 
__randomizedtesting.SeedInfo.seed([AE0C276FE5A8AE44:A49E7EB38D070CE7]:0)
at org.junit.Assert.assertEquals(Assert.java:115)
at 
org.apache.solr.cloud.TestConfigSetsAPI$1.preVisitDirectory(TestConfigSetsAPI.java:720)
at 
org.apache.solr.cloud.TestConfigSetsAPI$1.preVisitDirectory(TestConfigSetsAPI.java:710)
at java.base/java.nio.file.Files.walkFileTree(Files.java:2808)
at java.base/java.nio.file.Files.walkFileTree(Files.java:2873)
at 
org.apache.solr.cloud.TestConfigSetsAPI.compareDirectories(TestConfigSetsAPI.java:710)
at 
org.apache.solr.cloud.TestConfigSetsAPI.testUserAndTestDefaultConfigsetsAreSame(TestConfigSetsAPI.java:701)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:567)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:947)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
or

[jira] [Resolved] (SOLR-13603) Remove deprecated grouping methods usage

[Munendra S N (JIRA)]

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

Munendra S N resolved SOLR-13603.
-
   Resolution: Done
 Assignee: Munendra S N
Fix Version/s: 8.2

> Remove deprecated grouping methods usage
> 
>
> Key: SOLR-13603
> URL: https://issues.apache.org/jira/browse/SOLR-13603
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Munendra S N
>Assignee: Munendra S N
>Priority: Minor
> Fix For: 8.2
>
>
> As part of SOLR-9660, few of the methods in GroupingSpecification are 
> deprecated. Remove their usage



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

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

[jira] [Commented] (SOLR-13603) Remove deprecated grouping methods usage

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-13603:


Commit fd93b43cf935343cb5fe375c938564e86406dd9f in lucene-solr's branch 
refs/heads/branch_8x from Munendra S N
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=fd93b43 ]

SOLR-13603: remove deprecated groupSpec methods usage

This is precursor to removing deprecated methods


> Remove deprecated grouping methods usage
> 
>
> Key: SOLR-13603
> URL: https://issues.apache.org/jira/browse/SOLR-13603
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Munendra S N
>Priority: Minor
>
> As part of SOLR-9660, few of the methods in GroupingSpecification are 
> deprecated. Remove their usage



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

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

[JENKINS] Lucene-Solr-SmokeRelease-8.1 - Build # 50 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-8.1/50/

No tests ran.

Build Log:
[...truncated 23880 lines...]
[asciidoctor:convert] asciidoctor: ERROR: about-this-guide.adoc: line 1: 
invalid part, must have at least one section (e.g., chapter, appendix, etc.)
[asciidoctor:convert] asciidoctor: ERROR: solr-glossary.adoc: line 1: invalid 
part, must have at least one section (e.g., chapter, appendix, etc.)
 [java] Processed 2570 links (2103 relative) to 3374 anchors in 253 files
 [echo] Validated Links & Anchors via: 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.1/solr/build/solr-ref-guide/bare-bones-html/

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

package:

-unpack-solr-tgz:

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

generate-maven-artifacts:

resolve:

resolve:

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

-ivy-fail-disallowed-ivy-version:

ivy-fail:

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

resolve:

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

-ivy-fail-disallowed-ivy-version:

ivy-fail:

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

resolve:

resolve:

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

-ivy-fail-disallowed-ivy-version:

ivy-fail:

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

resolve:

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

-ivy-fail-disallowed-ivy-version:

ivy-fail:

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

resolve:

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

-ivy-fail-disallowed-ivy-version:

ivy-fail:

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

resolve:

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

-ivy-fail-disallowed-ivy-version:

ivy-fail:

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

resolve:

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

-ivy-fail-disallowed-ivy-version:

ivy-fail:

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

resolve:

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

-ivy-fail-disallowed-ivy-version:

ivy-fail:

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

resolve:

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

-ivy-fail-disallowed-ivy-version:

ivy-fail:

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

resolve:

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

-ivy-fail-disallowed-ivy-version:

ivy-fail:

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

resolve:

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

-ivy-fail-disallowed-ivy-version:

ivy-fail:

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

resolve:

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

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:co

[jira] [Commented] (LUCENE-8762) Lucene50PostingsReader should specialize reading docs+freqs with impacts

[Atri Sharma (JIRA)]

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

Atri Sharma commented on LUCENE-8762:
-

I will take a crack at this and post a patch soon.

> Lucene50PostingsReader should specialize reading docs+freqs with impacts
> 
>
> Key: LUCENE-8762
> URL: https://issues.apache.org/jira/browse/LUCENE-8762
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Adrien Grand
>Priority: Minor
>
> Currently if you ask for impacts, we only have one implementation that is 
> able to expose everything: docs, freqs, positions and offsets. In contrast, 
> if you don't need impacts, we have specialization for docs+freqs, 
> docs+freqs+positions and docs+freqs+positions+offsets.
> Maybe we should add specialization for the docs+freqs case with impacts, 
> which should be the most common case, and remove specialization for 
> docs+freqs+positions when impacts are not requested?



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

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

[jira] [Commented] (SOLR-13603) Remove deprecated grouping methods usage

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-13603:


Commit e3d247f288f2bbfc8f73858fa35481a611bb16cf in lucene-solr's branch 
refs/heads/master from Munendra S N
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=e3d247f ]

SOLR-13603: remove deprecated groupSpec methods usage

This is precursor to removing deprecated methods


> Remove deprecated grouping methods usage
> 
>
> Key: SOLR-13603
> URL: https://issues.apache.org/jira/browse/SOLR-13603
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Munendra S N
>Priority: Minor
>
> As part of SOLR-9660, few of the methods in GroupingSpecification are 
> deprecated. Remove their usage



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

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

[jira] [Commented] (SOLR-13583) Impossible to delete a collection with the same name as an existing alias

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-13583:


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

SOLR-13583: Impossible to delete a collection with the same name as an existing 
alias.


> Impossible to delete a collection with the same name as an existing alias
> -
>
> Key: SOLR-13583
> URL: https://issues.apache.org/jira/browse/SOLR-13583
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 8.1, 8.1.1
>Reporter: Andrzej Bialecki 
>Assignee: Andrzej Bialecki 
>Priority: Blocker
> Fix For: 8.1.2
>
> Attachments: SOLR-13583.patch, SOLR-13583.patch
>
>
> SOLR-13262 changed the behavior of most collection admin commands so that 
> they always resolve aliases by default. In most cases this is desireable 
> behavior but it also prevents executing commands on the collections that have 
> the same name as an existing alias (which usually points to a different 
> collection).
> This behavior also breaks the REINDEXCOLLECTION command with 
> {{removeSource=true,}} which can also lead to data loss.
> This issue can be resolved by adding either an opt-in or opt-out flag to the 
> collection admin commands that specifies whether the command should attempt 
> resolving the provided name as an alias first. From the point of view of ease 
> of use this could be an opt-out option, from the point of view of data safety 
> this could be an opt-in option.



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

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

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

[Apache Jenkins Server]

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

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

Error Message:
Waiting for collection testSimple2 Timeout waiting to see state for 
collection=testSimple2 
:DocCollection(testSimple2//collections/testSimple2/state.json/26)={   
"pullReplicas":"0",   "replicationFactor":"2",   "shards":{ "shard1":{  
 "range":"8000-",   "state":"active",   "replicas":{
 "core_node3":{   
"dataDir":"hdfs://localhost:38896/solr_hdfs_home/testSimple2/core_node3/data/", 
  "base_url":"http://127.0.0.1:36722/solr";,   
"node_name":"127.0.0.1:36722_solr",   "type":"NRT",   
"force_set_state":"false",   
"ulogDir":"hdfs://localhost:38896/solr_hdfs_home/testSimple2/core_node3/data/tlog",
   "core":"testSimple2_shard1_replica_n1",   
"shared_storage":"true",   "state":"active",   
"leader":"true"}, "core_node5":{   
"dataDir":"hdfs://localhost:38896/solr_hdfs_home/testSimple2/core_node5/data/", 
  "base_url":"http://127.0.0.1:38305/solr";,   
"node_name":"127.0.0.1:38305_solr",   "type":"NRT",   
"force_set_state":"false",   
"ulogDir":"hdfs://localhost:38896/solr_hdfs_home/testSimple2/core_node5/data/tlog",
   "core":"testSimple2_shard1_replica_n2",   
"shared_storage":"true",   "state":"down"}}}, "shard2":{   
"range":"0-7fff",   "state":"active",   "replicas":{ 
"core_node7":{   
"dataDir":"hdfs://localhost:38896/solr_hdfs_home/testSimple2/core_node7/data/", 
  "base_url":"http://127.0.0.1:36722/solr";,   
"node_name":"127.0.0.1:36722_solr",   "type":"NRT",   
"force_set_state":"false",   
"ulogDir":"hdfs://localhost:38896/solr_hdfs_home/testSimple2/core_node7/data/tlog",
   "core":"testSimple2_shard2_replica_n4",   
"shared_storage":"true",   "state":"active",   
"leader":"true"}, "core_node8":{   
"dataDir":"hdfs://localhost:38896/solr_hdfs_home/testSimple2/core_node8/data/", 
  "base_url":"http://127.0.0.1:38305/solr";,   
"node_name":"127.0.0.1:38305_solr",   "type":"NRT",   
"force_set_state":"false",   
"ulogDir":"hdfs://localhost:38896/solr_hdfs_home/testSimple2/core_node8/data/tlog",
   "core":"testSimple2_shard2_replica_n6",   
"shared_storage":"true",   "state":"down",   
"router":{"name":"compositeId"},   "maxShardsPerNode":"2",   
"autoAddReplicas":"true",   "nrtReplicas":"2",   "tlogReplicas":"0"} Live 
Nodes: [127.0.0.1:36722_solr, 127.0.0.1:41990_solr] Last available state: 
DocCollection(testSimple2//collections/testSimple2/state.json/26)={   
"pullReplicas":"0",   "replicationFactor":"2",   "shards":{ "shard1":{  
 "range":"8000-",   "state":"active",   "replicas":{
 "core_node3":{   
"dataDir":"hdfs://localhost:38896/solr_hdfs_home/testSimple2/core_node3/data/", 
  "base_url":"http://127.0.0.1:36722/solr";,   
"node_name":"127.0.0.1:36722_solr",   "type":"NRT",   
"force_set_state":"false",   
"ulogDir":"hdfs://localhost:38896/solr_hdfs_home/testSimple2/core_node3/data/tlog",
   "core":"testSimple2_shard1_replica_n1",   
"shared_storage":"true",   "state":"active",   
"leader":"true"}, "core_node5":{   
"dataDir":"hdfs://localhost:38896/solr_hdfs_home/testSimple2/core_node5/data/", 
  "base_url":"http://127.0.0.1:38305/solr";,   
"node_name":"127.0.0.1:38305_solr",   "type":"NRT",   
"force_set_state":"false",   
"ulogDir":"hdfs://localhost:38896/solr_hdfs_home/testSimple2/core_node5/data/tlog",
   "core":"testSimple2_shard1_replica_n2",   
"shared_storage":"true",   "state":"down"}}}, "shard2":{   
"range":"0-7fff",   "state":"active",   "replicas":{ 
"core_node7":{   
"dataDir":"hdfs://localhost:38896/solr_hdfs_home/testSimple2/core_node7/data/", 
  "base_url":"http://127.0.0.1:36722/solr";,   
"node_name":"127.0.0.1:36722_solr",   "type":"NRT",   
"force_set_state":"false",   
"ulogDir":"hdfs://localhost:38896/solr_hdfs_home/testSimple2/core_node7/data/tlog",
   "core":"testSimple2_shard2_replica_n4",   
"shared_storage":"true",   "state":"active",   
"leader":"true"}, "core_node8":{   
"dataDir":"hdfs://localhost:38896/solr_hdfs_home/testSimple2/core_node8/data/", 
  "base_url":"http://127.0.0.1:38305/solr";,   
"node_name":"127.0.0.1:38305_solr",   "type":"NRT",   
"force_set_state":"false",   
"ulogDir":"hdfs://localhost:38896/solr_hdfs_home/te

[jira] [Commented] (SOLR-13507) Remove support for "addr" parameter from the "/solr/admin/zookeeper" endpoint.

[Lucene/Solr QA (JIRA)]

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

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

| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:red}-1{color} | {color:red} patch {color} | {color:red}  0m  6s{color} 
| {color:red} SOLR-13507 does not apply to master. Rebase required? Wrong 
Branch? See 
https://wiki.apache.org/solr/HowToContribute#Creating_the_patch_file for help. 
{color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | SOLR-13507 |
| JIRA Patch URL | 
https://issues.apache.org/jira/secure/attachment/12971373/SOLR-13507.02.patch |
| Console output | 
https://builds.apache.org/job/PreCommit-SOLR-Build/478/console |
| Powered by | Apache Yetus 0.7.0   http://yetus.apache.org |


This message was automatically generated.



> Remove support for "addr" parameter from the "/solr/admin/zookeeper" endpoint.
> --
>
> Key: SOLR-13507
> URL: https://issues.apache.org/jira/browse/SOLR-13507
> Project: Solr
>  Issue Type: Improvement
>Reporter: Anshum Gupta
>Assignee: Anshum Gupta
>Priority: Major
> Attachments: SOLR-13507.02.patch, SOLR-13507.patch
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> The addr parameter isn't needed and it should be removed from the code.



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

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

[GitHub] [lucene-solr] dsmiley commented on a change in pull request #726: LUCENE-8632: New XYShape Field and Queries for indexing and searching general cartesian geometries

[GitBox]

dsmiley commented on a change in pull request #726: LUCENE-8632: New XYShape 
Field and Queries for indexing and searching general cartesian geometries
URL: https://github.com/apache/lucene-solr/pull/726#discussion_r299962828
 
 

 ##
 File path: lucene/sandbox/src/java/org/apache/lucene/geo/XYPolygon2D.java
 ##
 @@ -0,0 +1,44 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements.  See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License.  You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.lucene.geo;
+
+/**
+ * 2D cartesian polygon implementation represented as a balanced interval tree 
of edges.
+ *
+ * @lucene.internal
+ */
+public class XYPolygon2D extends Polygon2D {
+
+  protected XYPolygon2D(XYPolygon polygon, XYPolygon2D holes) {
 
 Review comment:
   I hear ya @iverase ... I'm glad to hear I'm not the only crazy one :-)


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


With regards,
Apache Git Services

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

[jira] [Commented] (LUCENE-8311) Leverage impacts for phrase queries

[Adrien Grand (JIRA)]

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

Adrien Grand commented on LUCENE-8311:
--

It turns out that part of the reason why the patch is making things slower is 
that it is moving phrase queries from BlockPostingsEnum, which is specialized 
to read freqs and positions only, to BlockImpactsEverythingEnum, which can read 
any of docs+freqs, docs+freqs+positios or docs+freqs+positions+offsets. Maybe 
we should remove BlockPostingsEnum and have a specialized impacts enum for 
positions instead.

The merged impacts look like they have some room for improvement as well. I'm 
looking into those issues so that we can then do better testing of LUCENE-8806.

> Leverage impacts for phrase queries
> ---
>
> Key: LUCENE-8311
> URL: https://issues.apache.org/jira/browse/LUCENE-8311
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Adrien Grand
>Priority: Minor
> Attachments: LUCENE-8311.patch
>
>
> Now that we expose raw impacts, we could leverage them for phrase queries.
> For instance for exact phrases, we could take the minimum term frequency for 
> each unique norm value in order to get upper bounds of the score for the 
> phrase.



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

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

[jira] [Created] (SOLR-13603) Remove deprecated grouping methods usage

[Munendra S N (JIRA)]

Munendra S N created SOLR-13603:
---

 Summary: Remove deprecated grouping methods usage
 Key: SOLR-13603
 URL: https://issues.apache.org/jira/browse/SOLR-13603
 Project: Solr
  Issue Type: Sub-task
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Munendra S N


As part of SOLR-9660, few of the methods in GroupingSpecification are 
deprecated. Remove their usage



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

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

[jira] [Commented] (LUCENE-8895) Switch all FSTs to use direct addressing optimization

[David Smiley (JIRA)]

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

David Smiley commented on LUCENE-8895:
--

Dare I ask:  Did you intend to only Deprecate the first getByOutput method and 
not the other?    It's my favorite method after all :)

Tip: when creating issues related to each other, link them in Jira so the 
"watchers" of the first issue know about the new issue

> Switch all FSTs to use direct addressing optimization
> -
>
> Key: LUCENE-8895
> URL: https://issues.apache.org/jira/browse/LUCENE-8895
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Mike Sokolov
>Priority: Major
> Fix For: 8.2
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> See discussion in LUCENE-8781 about turning on array-with-gaps encoding 
> everywhere. Let's conduct any further discussion here so we can use an open 
> issue.



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

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

[JENKINS] Lucene-Solr-Tests-8.1 - Build # 74 - Still Unstable

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Tests-8.1/74/

1 tests failed.
FAILED:  org.apache.solr.security.BasicAuthIntegrationTest.testBasicAuth

Error Message:
Expected metric minimums for prefix SECURITY./authentication.: 
{failMissingCredentials=2, authenticated=20, passThrough=9, 
failWrongCredentials=1, requests=32, errors=0}, but got: 
{failMissingCredentials=2, authenticated=19, passThrough=11, 
totalTime=14123134, failWrongCredentials=1, requestTimes=390, requests=33, 
errors=0}

Stack Trace:
java.lang.AssertionError: Expected metric minimums for prefix 
SECURITY./authentication.: {failMissingCredentials=2, authenticated=20, 
passThrough=9, failWrongCredentials=1, requests=32, errors=0}, but got: 
{failMissingCredentials=2, authenticated=19, passThrough=11, 
totalTime=14123134, failWrongCredentials=1, requestTimes=390, requests=33, 
errors=0}
at 
__randomizedtesting.SeedInfo.seed([498846F2BDBD79BF:F5E630E019EEFAC5]:0)
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.assertTrue(Assert.java:41)
at 
org.apache.solr.cloud.SolrCloudAuthTestCase.assertAuthMetricsMinimums(SolrCloudAuthTestCase.java:129)
at 
org.apache.solr.cloud.SolrCloudAuthTestCase.assertAuthMetricsMinimums(SolrCloudAuthTestCase.java:83)
at 
org.apache.solr.security.BasicAuthIntegrationTest.testBasicAuth(BasicAuthIntegrationTest.java:313)
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

[jira] [Resolved] (SOLR-13588) Document Estonian analyzer in Solr Ref Guide

[Tomoko Uchida (JIRA)]

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

Tomoko Uchida resolved SOLR-13588.
--
   Resolution: Fixed
Fix Version/s: 8.2
   master (9.0)

> Document Estonian analyzer in Solr Ref Guide
> 
>
> Key: SOLR-13588
> URL: https://issues.apache.org/jira/browse/SOLR-13588
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Affects Versions: master (9.0), 8.2
>Reporter: Tomoko Uchida
>Assignee: Tomoko Uchida
>Priority: Minor
> Fix For: master (9.0), 8.2
>
> Attachments: SOLR-13588.patch, Screenshot from 2019-07-03 
> 21-59-23.png, Screenshot from 2019-07-03 22-00-34.png
>
>
> A stemmer and analyzer for Estonian language have been added (LUCENE-8891).
> The Ref Guilde needs to be updated to include the documentation and example 
> for Estonian.
>  [https://lucene.apache.org/solr/guide/8_1/language-analysis.html]
> I suppose default schema example also should be updated, but I'm not sure 
> about that.



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

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

[jira] [Commented] (SOLR-13588) Document Estonian analyzer in Solr Ref Guide

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-13588:


Commit d586c44a33eaec3b3993cc056e1d5e4fba927948 in lucene-solr's branch 
refs/heads/branch_8x from Tomoko Uchida
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=d586c44 ]

SOLR-13588: Document Estonian analyzer in Solr Ref Guide


> Document Estonian analyzer in Solr Ref Guide
> 
>
> Key: SOLR-13588
> URL: https://issues.apache.org/jira/browse/SOLR-13588
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Affects Versions: master (9.0), 8.2
>Reporter: Tomoko Uchida
>Assignee: Tomoko Uchida
>Priority: Minor
> Attachments: SOLR-13588.patch, Screenshot from 2019-07-03 
> 21-59-23.png, Screenshot from 2019-07-03 22-00-34.png
>
>
> A stemmer and analyzer for Estonian language have been added (LUCENE-8891).
> The Ref Guilde needs to be updated to include the documentation and example 
> for Estonian.
>  [https://lucene.apache.org/solr/guide/8_1/language-analysis.html]
> I suppose default schema example also should be updated, but I'm not sure 
> about that.



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

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

[jira] [Commented] (SOLR-13588) Document Estonian analyzer in Solr Ref Guide

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-13588:


Commit 9d2f5163578d70a6227a3354e064dcb19c1209e9 in lucene-solr's branch 
refs/heads/master from Tomoko Uchida
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=9d2f516 ]

SOLR-13588: Document Estonian analyzer in Solr Ref Guide


> Document Estonian analyzer in Solr Ref Guide
> 
>
> Key: SOLR-13588
> URL: https://issues.apache.org/jira/browse/SOLR-13588
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Affects Versions: master (9.0), 8.2
>Reporter: Tomoko Uchida
>Assignee: Tomoko Uchida
>Priority: Minor
> Attachments: SOLR-13588.patch, Screenshot from 2019-07-03 
> 21-59-23.png, Screenshot from 2019-07-03 22-00-34.png
>
>
> A stemmer and analyzer for Estonian language have been added (LUCENE-8891).
> The Ref Guilde needs to be updated to include the documentation and example 
> for Estonian.
>  [https://lucene.apache.org/solr/guide/8_1/language-analysis.html]
> I suppose default schema example also should be updated, but I'm not sure 
> about that.



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

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

[jira] [Commented] (SOLR-13588) Document Estonian analyzer in Solr Ref Guide

[Tomoko Uchida (JIRA)]

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

Tomoko Uchida commented on SOLR-13588:
--

HTML and PDF formats were successfully built.

> Document Estonian analyzer in Solr Ref Guide
> 
>
> Key: SOLR-13588
> URL: https://issues.apache.org/jira/browse/SOLR-13588
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Affects Versions: master (9.0), 8.2
>Reporter: Tomoko Uchida
>Assignee: Tomoko Uchida
>Priority: Minor
> Attachments: SOLR-13588.patch, Screenshot from 2019-07-03 
> 21-59-23.png, Screenshot from 2019-07-03 22-00-34.png
>
>
> A stemmer and analyzer for Estonian language have been added (LUCENE-8891).
> The Ref Guilde needs to be updated to include the documentation and example 
> for Estonian.
>  [https://lucene.apache.org/solr/guide/8_1/language-analysis.html]
> I suppose default schema example also should be updated, but I'm not sure 
> about that.



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

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

[jira] [Commented] (SOLR-13588) Document Estonian analyzer in Solr Ref Guide

[Tomoko Uchida (JIRA)]

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

Tomoko Uchida commented on SOLR-13588:
--

Generated ref guide (HTML):

!Screenshot from 2019-07-03 22-00-34.png!
 !Screenshot from 2019-07-03 21-59-23.png!

> Document Estonian analyzer in Solr Ref Guide
> 
>
> Key: SOLR-13588
> URL: https://issues.apache.org/jira/browse/SOLR-13588
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Affects Versions: master (9.0), 8.2
>Reporter: Tomoko Uchida
>Assignee: Tomoko Uchida
>Priority: Minor
> Attachments: SOLR-13588.patch, Screenshot from 2019-07-03 
> 21-59-23.png, Screenshot from 2019-07-03 22-00-34.png
>
>
> A stemmer and analyzer for Estonian language have been added (LUCENE-8891).
> The Ref Guilde needs to be updated to include the documentation and example 
> for Estonian.
>  [https://lucene.apache.org/solr/guide/8_1/language-analysis.html]
> I suppose default schema example also should be updated, but I'm not sure 
> about that.



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

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

[jira] [Updated] (SOLR-13588) Document Estonian analyzer in Solr Ref Guide

[Tomoko Uchida (JIRA)]

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

Tomoko Uchida updated SOLR-13588:
-
Attachment: Screenshot from 2019-07-03 22-00-34.png

> Document Estonian analyzer in Solr Ref Guide
> 
>
> Key: SOLR-13588
> URL: https://issues.apache.org/jira/browse/SOLR-13588
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Affects Versions: master (9.0), 8.2
>Reporter: Tomoko Uchida
>Assignee: Tomoko Uchida
>Priority: Minor
> Attachments: SOLR-13588.patch, Screenshot from 2019-07-03 
> 21-59-23.png, Screenshot from 2019-07-03 22-00-34.png
>
>
> A stemmer and analyzer for Estonian language have been added (LUCENE-8891).
> The Ref Guilde needs to be updated to include the documentation and example 
> for Estonian.
>  [https://lucene.apache.org/solr/guide/8_1/language-analysis.html]
> I suppose default schema example also should be updated, but I'm not sure 
> about that.



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

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

[jira] [Updated] (SOLR-13588) Document Estonian analyzer in Solr Ref Guide

[Tomoko Uchida (JIRA)]

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

Tomoko Uchida updated SOLR-13588:
-
Attachment: Screenshot from 2019-07-03 21-59-23.png

> Document Estonian analyzer in Solr Ref Guide
> 
>
> Key: SOLR-13588
> URL: https://issues.apache.org/jira/browse/SOLR-13588
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Affects Versions: master (9.0), 8.2
>Reporter: Tomoko Uchida
>Assignee: Tomoko Uchida
>Priority: Minor
> Attachments: SOLR-13588.patch, Screenshot from 2019-07-03 
> 21-59-23.png, Screenshot from 2019-07-03 22-00-34.png
>
>
> A stemmer and analyzer for Estonian language have been added (LUCENE-8891).
> The Ref Guilde needs to be updated to include the documentation and example 
> for Estonian.
>  [https://lucene.apache.org/solr/guide/8_1/language-analysis.html]
> I suppose default schema example also should be updated, but I'm not sure 
> about that.



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

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

[jira] [Updated] (SOLR-13588) Document Estonian analyzer in Solr Ref Guide

[Tomoko Uchida (JIRA)]

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

Tomoko Uchida updated SOLR-13588:
-
 Assignee: Tomoko Uchida
Affects Version/s: 8.2
   master (9.0)
   Attachment: SOLR-13588.patch
   Status: Open  (was: Open)

> Document Estonian analyzer in Solr Ref Guide
> 
>
> Key: SOLR-13588
> URL: https://issues.apache.org/jira/browse/SOLR-13588
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Affects Versions: master (9.0), 8.2
>Reporter: Tomoko Uchida
>Assignee: Tomoko Uchida
>Priority: Minor
> Attachments: SOLR-13588.patch
>
>
> A stemmer and analyzer for Estonian language have been added (LUCENE-8891).
> The Ref Guilde needs to be updated to include the documentation and example 
> for Estonian.
>  [https://lucene.apache.org/solr/guide/8_1/language-analysis.html]
> I suppose default schema example also should be updated, but I'm not sure 
> about that.



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

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

[jira] [Commented] (LUCENE-8902) Index-time join ToParentBlockJoinQuery query produces incorrect result with child wildcards

[Andrei (JIRA)]

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

Andrei commented on LUCENE-8902:


My apologies. Thank you and I will pot something to the mailing list.

> Index-time join ToParentBlockJoinQuery query produces incorrect result with 
> child wildcards
> ---
>
> Key: LUCENE-8902
> URL: https://issues.apache.org/jira/browse/LUCENE-8902
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/join
>Affects Versions: 8.1.1
>Reporter: Andrei
>Priority: Major
>
> When I do a index-time join query on certain parent docs with a wildcard 
> query for child docs, sometimes I get the wrong answer. Example:
>  
> ||Parent Doc||Children||
> |id=id0|  none|
> |id=id1| # program=P1|
> |id=id2| # program=P1
>  # program=P2|
> |id=id3|  none|
> |id=id4| # program=P1|
> |id=id5| # program=P1
>  # program=P2|
> So essentially I have 6 parent docs, doc 0 has no children, doc 1 has 1 
> child, doc 2 has 2 children, etc.
> 1. The following query gives the correct results:
>     BitSetProducer parentSet = new QueryBitSetProducer(new 
> TermInSetQuery("id", toSet("id0", "id1", "id2", "id3", 
> "id4", "id5")));
>         Query q = new ToParentBlockJoinQuery(new TermInSetQuery("program", 
> toSet("P1", "P2")), parentSet, ScoreMode.None);
> Returns the correct result (4 docs: ["id1", "id2", "id4", 
> "id5"]
>  
> 2. This also gives correct result (same as above):
>     BitSetProducer parentSet = new QueryBitSetProducer(new 
> TermInSetQuery("id", toSet("id0", "id1", "id2", "id3", 
> "id4", "id5")));
>         Query q = new ToParentBlockJoinQuery(new WildcardQuery(new 
> Term("program", "*")), parentSet, ScoreMode.None);
>  
> 3. Also correct (same as above)
>     BitSetProducer parentSet = new QueryBitSetProducer(new 
> WildcardQuery(new Term("id", "*")));
>         Query q = new ToParentBlockJoinQuery(new WildcardQuery(new 
> Term("program", "*")), parentSet, ScoreMode.None);
> so far so good.
>  
> 4. This one gives incorrect result:
>     BitSetProducer parentSet = new QueryBitSetProducer(new 
> TermInSetQuery("id", toSet("id0", "id1", "id3")));
>         Query q = new ToParentBlockJoinQuery(new WildcardQuery(new 
> Term("program", "*")), parentSet, 
> org.apache.lucene.search.join.ScoreMode.None);
> Returns 2 docs ["id1", "id3"]. It should only return "id1" and 
> not "id3" here. Very strange behavior. 
>  
> 5. Just asking for "id3" also incorrectly returns it:
>     BitSetProducer parentSet = new QueryBitSetProducer(new TermQuery(new 
> Term("id", "id3")));
>         Query q = new ToParentBlockJoinQuery(new WildcardQuery(new 
> Term("program", "*")), parentSet, 
> org.apache.lucene.search.join.ScoreMode.None);
>  
> 6. But as soon as I add "id2" to the parent query, it works again..
>     BitSetProducer parentSet = new QueryBitSetProducer(new 
> TermInSetQuery("id", toSet( "id3", "id2")));
>         Query q = new ToParentBlockJoinQuery(new WildcardQuery(new 
> Term("program", "*")), parentSet, 
> org.apache.lucene.search.join.ScoreMode.None);
> Gives the correct result ["id2"]
> 
> I am attaching the unit test that demonstrates this: 
> [https://pastebin.com/aJ1LDLCS]
> I don't know if I am doing something wrong, or if there is an issue.
> Thank you for looking into it.



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

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

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

[Policeman Jenkins Server]

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

1 tests failed.
FAILED:  
org.apache.lucene.index.TestIndexWriterOnDiskFull.testAddDocumentOnDiskFull

Error Message:
this IndexWriter is closed

Stack Trace:
org.apache.lucene.store.AlreadyClosedException: this IndexWriter is closed
at 
__randomizedtesting.SeedInfo.seed([EA79D22EDD9A86A1:6661EA51200F5065]:0)
at org.apache.lucene.index.IndexWriter.ensureOpen(IndexWriter.java:681)
at org.apache.lucene.index.IndexWriter.ensureOpen(IndexWriter.java:695)
at 
org.apache.lucene.index.IndexWriter.updateDocument(IndexWriter.java:1591)
at 
org.apache.lucene.index.IndexWriter.addDocument(IndexWriter.java:1213)
at 
org.apache.lucene.index.TestIndexWriterOnDiskFull.addDoc(TestIndexWriterOnDiskFull.java:571)
at 
org.apache.lucene.index.TestIndexWriterOnDiskFull.testAddDocumentOnDiskFull(TestIndexWriterOnDiskFull.java:79)
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 
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:830)
Caused by: java.io.IOException: fake disk full at 8724 bytes when writing 
_3.fnm (file length=23; wrote 18 of 18 bytes)
at 
org.apache.lucene.store.MockIndexOutputWrapper.checkDiskFull(MockIndexOutputWrapper.java:87)
at 
org.apache.lucene.store.MockIndexOutputWrapper.writeBytes(MockIndex

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

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/8032/
Java: 64bit/jdk-11.0.3 -XX:+UseCompressedOops -XX:+UseSerialGC

All tests passed

Build Log:
[...truncated 64841 lines...]
-ecj-javadoc-lint-src:
[mkdir] Created dir: C:\Users\jenkins\AppData\Local\Temp\ecj598037397
 [ecj-lint] Compiling 69 source files to 
C:\Users\jenkins\AppData\Local\Temp\ecj598037397
 [ecj-lint] invalid Class-Path header in manifest of jar file: 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\core\lib\org.restlet-2.3.0.jar
 [ecj-lint] invalid Class-Path header in manifest of jar file: 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\core\lib\org.restlet.ext.servlet-2.3.0.jar
 [ecj-lint] --
 [ecj-lint] 1. ERROR in 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\contrib\dataimporthandler\src\java\org\apache\solr\handler\dataimport\JdbcDataSource.java
 (at line 28)
 [ecj-lint] import javax.naming.InitialContext;
 [ecj-lint]^^^
 [ecj-lint] The type javax.naming.InitialContext is not accessible
 [ecj-lint] --
 [ecj-lint] 2. ERROR in 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\contrib\dataimporthandler\src\java\org\apache\solr\handler\dataimport\JdbcDataSource.java
 (at line 29)
 [ecj-lint] import javax.naming.NamingException;
 [ecj-lint]
 [ecj-lint] The type javax.naming.NamingException is not accessible
 [ecj-lint] --
 [ecj-lint] 3. ERROR in 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\contrib\dataimporthandler\src\java\org\apache\solr\handler\dataimport\JdbcDataSource.java
 (at line 182)
 [ecj-lint] c = getFromJndi(initProps, jndiName);
 [ecj-lint] ^^^
 [ecj-lint] The method getFromJndi(Properties, String) from the type new 
Callable(){} refers to the missing type NamingException
 [ecj-lint] --
 [ecj-lint] 4. ERROR in 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\contrib\dataimporthandler\src\java\org\apache\solr\handler\dataimport\JdbcDataSource.java
 (at line 245)
 [ecj-lint] private Connection getFromJndi(final Properties initProps, 
final String jndiName) throws NamingException,
 [ecj-lint] 
 ^^^
 [ecj-lint] NamingException cannot be resolved to a type
 [ecj-lint] --
 [ecj-lint] 5. ERROR in 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\contrib\dataimporthandler\src\java\org\apache\solr\handler\dataimport\JdbcDataSource.java
 (at line 249)
 [ecj-lint] InitialContext ctx =  new InitialContext();
 [ecj-lint] ^^
 [ecj-lint] InitialContext cannot be resolved to a type
 [ecj-lint] --
 [ecj-lint] 6. ERROR in 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\contrib\dataimporthandler\src\java\org\apache\solr\handler\dataimport\JdbcDataSource.java
 (at line 249)
 [ecj-lint] InitialContext ctx =  new InitialContext();
 [ecj-lint]   ^^
 [ecj-lint] InitialContext cannot be resolved to a type
 [ecj-lint] --
 [ecj-lint] 6 problems (6 errors)

BUILD FAILED
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\build.xml:634: The 
following error occurred while executing this line:
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\build.xml:101: The 
following error occurred while executing this line:
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build.xml:651: The 
following error occurred while executing this line:
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\common-build.xml:479:
 The following error occurred while executing this line:
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\common-build.xml:2009:
 The following error occurred while executing this line:
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\common-build.xml:2048:
 Compile failed; see the compiler error output for details.

Total time: 140 minutes 53 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
Setting 
ANT_1_8_2_HOME=C:\Users\jenkins\tools\hudson.tasks.Ant_AntInstallation\ANT_1.8.2
[WARNINGS] Skipping publisher since build result is FAILURE
Recording test results
Setting 
ANT_1_8_2_HOME=C:\Users\jenkins\tools\hudson.tasks.Ant_AntInstallation\ANT_1.8.2
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any
Setting 
ANT_1_8_2_HOME=C:\Users\jenkins\tools\hudson.tasks.Ant_AntInstallation\ANT_1.8.2
Setting 
ANT_1_8_2_HOME=C:\Users\jenkins\tools\hudson.tasks.Ant_AntInstallation\ANT_1.8.2
Setting 
ANT_1_8_2_HOME=C:\Users\jenkins\tools\hudson.tasks.Ant_AntInstallation\ANT_1.8.2
Setting 
ANT_1_8_2_HOME=C:\Users\jenkins\tools\hudson.tasks.Ant_AntInstallation\ANT_1.8.2
Setting 
ANT_1_8_2_HOME=C:\Users\jenkins\tools\hudson.tasks.Ant_AntInstallation\ANT_1.8.2
Setting 
ANT_1_8_2_HOME=C:\Users\jenkins\tools\hudson.tasks.Ant_AntInst

[jira] [Resolved] (SOLR-13602) Add a field type for Estonian language to default managed_schema

[Tomoko Uchida (JIRA)]

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

Tomoko Uchida resolved SOLR-13602.
--
   Resolution: Fixed
Fix Version/s: 8.2
   master (9.0)

{{_default}} and {{sample_techproducts_configs}} configsets were updated.

> Add a field type for Estonian language to default managed_schema
> 
>
> Key: SOLR-13602
> URL: https://issues.apache.org/jira/browse/SOLR-13602
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Tomoko Uchida
>Assignee: Tomoko Uchida
>Priority: Minor
> Fix For: master (9.0), 8.2
>
> Attachments: SOLR-13602.patch, SOLR-13602.patch, Screenshot from 
> 2019-07-03 20-44-46.png
>
>
> An analyzer for Estonian language have been added (LUCENE-8891).
> Default {{managed_schama}} should be updated to include a field type 
> corresponding to the {{EstonianAnalyzer}}.
> I will attach a patch soon.



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

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

[jira] [Commented] (SOLR-13602) Add a field type for Estonian language to default managed_schema

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-13602:


Commit bb074f6a8aaa2131a276d9826d1ddd20ab573c90 in lucene-solr's branch 
refs/heads/branch_8x from Tomoko Uchida
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=bb074f6 ]

SOLR-13602: Add a field type for Estonian language to default managed_schema


> Add a field type for Estonian language to default managed_schema
> 
>
> Key: SOLR-13602
> URL: https://issues.apache.org/jira/browse/SOLR-13602
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Tomoko Uchida
>Assignee: Tomoko Uchida
>Priority: Minor
> Attachments: SOLR-13602.patch, SOLR-13602.patch, Screenshot from 
> 2019-07-03 20-44-46.png
>
>
> An analyzer for Estonian language have been added (LUCENE-8891).
> Default {{managed_schama}} should be updated to include a field type 
> corresponding to the {{EstonianAnalyzer}}.
> I will attach a patch soon.



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

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

[jira] [Commented] (SOLR-13602) Add a field type for Estonian language to default managed_schema

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-13602:


Commit 45ea46a425bb04dcfeca8392b1db1eb39681c131 in lucene-solr's branch 
refs/heads/master from Tomoko Uchida
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=45ea46a ]

SOLR-13602: Add a field type for Estonian language to default managed_schema


> Add a field type for Estonian language to default managed_schema
> 
>
> Key: SOLR-13602
> URL: https://issues.apache.org/jira/browse/SOLR-13602
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Tomoko Uchida
>Assignee: Tomoko Uchida
>Priority: Minor
> Attachments: SOLR-13602.patch, SOLR-13602.patch, Screenshot from 
> 2019-07-03 20-44-46.png
>
>
> An analyzer for Estonian language have been added (LUCENE-8891).
> Default {{managed_schama}} should be updated to include a field type 
> corresponding to the {{EstonianAnalyzer}}.
> I will attach a patch soon.



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

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

[jira] [Updated] (SOLR-13602) Add a field type for Estonian language to default managed_schema

[Tomoko Uchida (JIRA)]

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

Tomoko Uchida updated SOLR-13602:
-
Attachment: Screenshot from 2019-07-03 20-44-46.png

> Add a field type for Estonian language to default managed_schema
> 
>
> Key: SOLR-13602
> URL: https://issues.apache.org/jira/browse/SOLR-13602
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Tomoko Uchida
>Assignee: Tomoko Uchida
>Priority: Minor
> Attachments: SOLR-13602.patch, SOLR-13602.patch, Screenshot from 
> 2019-07-03 20-44-46.png
>
>
> An analyzer for Estonian language have been added (LUCENE-8891).
> Default {{managed_schama}} should be updated to include a field type 
> corresponding to the {{EstonianAnalyzer}}.
> I will attach a patch soon.



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

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

[jira] [Commented] (SOLR-13602) Add a field type for Estonian language to default managed_schema

[Tomoko Uchida (JIRA)]

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

Tomoko Uchida commented on SOLR-13602:
--

Analysis tab screenshot:
 !Screenshot from 2019-07-03 20-44-46.png! 

> Add a field type for Estonian language to default managed_schema
> 
>
> Key: SOLR-13602
> URL: https://issues.apache.org/jira/browse/SOLR-13602
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Tomoko Uchida
>Assignee: Tomoko Uchida
>Priority: Minor
> Attachments: SOLR-13602.patch, SOLR-13602.patch, Screenshot from 
> 2019-07-03 20-44-46.png
>
>
> An analyzer for Estonian language have been added (LUCENE-8891).
> Default {{managed_schama}} should be updated to include a field type 
> corresponding to the {{EstonianAnalyzer}}.
> I will attach a patch soon.



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

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

[jira] [Updated] (SOLR-13602) Add a field type for Estonian language to default managed_schema

[Tomoko Uchida (JIRA)]

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

Tomoko Uchida updated SOLR-13602:
-
Attachment: SOLR-13602.patch

> Add a field type for Estonian language to default managed_schema
> 
>
> Key: SOLR-13602
> URL: https://issues.apache.org/jira/browse/SOLR-13602
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Tomoko Uchida
>Assignee: Tomoko Uchida
>Priority: Minor
> Attachments: SOLR-13602.patch, SOLR-13602.patch
>
>
> An analyzer for Estonian language have been added (LUCENE-8891).
> Default {{managed_schama}} should be updated to include a field type 
> corresponding to the {{EstonianAnalyzer}}.
> I will attach a patch soon.



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

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

[GitHub] [lucene-solr] iverase commented on a change in pull request #726: LUCENE-8632: New XYShape Field and Queries for indexing and searching general cartesian geometries

[GitBox]

iverase commented on a change in pull request #726: LUCENE-8632: New XYShape 
Field and Queries for indexing and searching general cartesian geometries
URL: https://github.com/apache/lucene-solr/pull/726#discussion_r299915146
 
 

 ##
 File path: lucene/sandbox/src/java/org/apache/lucene/document/ShapeField.java
 ##
 @@ -0,0 +1,303 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements.  See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License.  You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.lucene.document;
+
+import org.apache.lucene.geo.GeoUtils;
+import org.apache.lucene.geo.Line;
+import org.apache.lucene.geo.Polygon;
+import org.apache.lucene.geo.Tessellator;
+import org.apache.lucene.util.BytesRef;
+import org.apache.lucene.util.NumericUtils;
+
+/**
+ * A base shape utility class used for both LatLon (spherical) and XY 
(cartesian) shape fields.
+ * 
+ * {@link Polygon}'s and {@link Line}'s are decomposed into a triangular mesh 
using the {@link Tessellator} utility class.
+ * Each {@link Triangle} is encoded by this base class and indexed as a seven 
dimension multi-value field.
+ * 
+ * Finding all shapes that intersect a range (e.g., bounding box), or target 
shape, at search time is efficient.
+ * 
+ * This class defines the static methods for encoding the three vertices of a 
tessellated triangles as a seven dimension point.
+ * The coordinates are converted from double precision values into 32 bit 
integers so they are sortable at index time.
+ * 
+ *
+ * @lucene.experimental
+ */
+public abstract class ShapeField {
+  /** vertex coordinates are encoded as 4 byte integers */
 
 Review comment:
   This class is abstract but not implemented by any other. 


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] iverase commented on a change in pull request #726: LUCENE-8632: New XYShape Field and Queries for indexing and searching general cartesian geometries

[GitBox]

iverase commented on a change in pull request #726: LUCENE-8632: New XYShape 
Field and Queries for indexing and searching general cartesian geometries
URL: https://github.com/apache/lucene-solr/pull/726#discussion_r299914492
 
 

 ##
 File path: lucene/sandbox/src/java/org/apache/lucene/document/XYShape.java
 ##
 @@ -0,0 +1,103 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements.  See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License.  You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.lucene.document;
+
+import java.util.ArrayList;
+import java.util.List;
+
+import org.apache.lucene.document.ShapeField.QueryRelation; // javadoc
+import org.apache.lucene.document.ShapeField.Triangle;
+import org.apache.lucene.geo.Tessellator;
+import org.apache.lucene.index.PointValues; // javadoc
+import org.apache.lucene.geo.XYLine;
+import org.apache.lucene.geo.XYPolygon;
+import org.apache.lucene.search.Query;
+
+import static org.apache.lucene.geo.XYEncodingUtils.encode;
+
+/**
+ * A cartesian shape utility class for indexing and searching geometries whose 
vertices are unitless x, y values.
+ * 
+ * This class defines six static factory methods for common indexing and 
search operations:
+ * 
+ *   {@link #createIndexableFields(String, XYPolygon)} for indexing a 
cartesian polygon.
+ *   {@link #createIndexableFields(String, XYLine)} for indexing a 
cartesian linestring.
+ *   {@link #createIndexableFields(String, double, double)} for indexing a 
x, y cartesian point.
+ *   {@link #newBoxQuery newBoxQuery()} for matching cartesian shapes that 
have some {@link QueryRelation} with a bounding box.
+ *   {@link #newBoxQuery newLineQuery()} for matching cartesian shapes 
that have some {@link QueryRelation} with a linestring.
+ *   {@link #newBoxQuery newPolygonQuery()} for matching cartesian shapes 
that have some {@link QueryRelation} with a polygon.
+ * 
+
+ * WARNING: Like {@link LatLonPoint}, vertex values are indexed with 
some loss of precision from the
+ * original {@code double} values.
+ * @see PointValues
+ * @see LatLonDocValuesField
+ *
+ * @lucene.experimental
+ */
+public class XYShape {
+
+  // no instance:
+  private XYShape() {
+  }
+
+  /** create indexable fields for cartesian polygon geometry */
+  public static Field[] createIndexableFields(String fieldName, XYPolygon 
polygon) {
+
+List tessellation = Tessellator.tessellate(polygon);
+List fields = new ArrayList<>(tessellation.size());
+for (Tessellator.Triangle t : tessellation) {
+  fields.add(new Triangle(fieldName, t));
+}
+return fields.toArray(new Field[fields.size()]);
+  }
+
+  /** create indexable fields for cartesian line geometry */
+  public static Field[] createIndexableFields(String fieldName, XYLine line) {
+int numPoints = line.numPoints();
+Field[] fields = new Field[numPoints - 1];
+// create "flat" triangles
+for (int i = 0, j = 1; j < numPoints; ++i, ++j) {
+  fields[i] = new Triangle(fieldName,
+  encode(line.getX(i)), encode(line.getY(i)),
+  encode(line.getX(j)), encode(line.getY(j)),
+  encode(line.getX(i)), encode(line.getY(i)));
+}
+return fields;
+  }
+
+  /** create indexable fields for cartesian point geometry */
+  public static Field[] createIndexableFields(String fieldName, double x, 
double y) {
+return new Field[] {new Triangle(fieldName,
 
 Review comment:
   Should we have floats here instead?


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-13602) Add a field type for Estonian language to default managed_schema

[Tomoko Uchida (JIRA)]

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

Tomoko Uchida updated SOLR-13602:
-
  Assignee: Tomoko Uchida
Attachment: SOLR-13602.patch
Status: Open  (was: Open)

> Add a field type for Estonian language to default managed_schema
> 
>
> Key: SOLR-13602
> URL: https://issues.apache.org/jira/browse/SOLR-13602
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Tomoko Uchida
>Assignee: Tomoko Uchida
>Priority: Minor
> Attachments: SOLR-13602.patch
>
>
> An analyzer for Estonian language have been added (LUCENE-8891).
> Default {{managed_schama}} should be updated to include a field type 
> corresponding to the {{EstonianAnalyzer}}.
> I will attach a patch soon.



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

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