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

[Apache Jenkins Server]

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

4 tests failed.
FAILED:  
org.apache.solr.cloud.autoscaling.SearchRateTriggerIntegrationTest.testDeleteNode

Error Message:
unexpected DELETENODE status: 
{responseHeader={status=0,QTime=4},status={state=notfound,msg=Did not find 
[search_rate_trigger3/459443420a3990Tv6zy840c64nckgf0ca7z13vy/0] in any tasks 
queue}}

Stack Trace:
java.lang.AssertionError: unexpected DELETENODE status: 
{responseHeader={status=0,QTime=4},status={state=notfound,msg=Did not find 
[search_rate_trigger3/459443420a3990Tv6zy840c64nckgf0ca7z13vy/0] in any tasks 
queue}}
at 
__randomizedtesting.SeedInfo.seed([95BDDD7260F2E8E:2BC9135511C5A1F3]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.autoscaling.SearchRateTriggerIntegrationTest.lambda$testDeleteNode$5(SearchRateTriggerIntegrationTest.java:684)
at java.util.ArrayList.forEach(ArrayList.java:1257)
at 
org.apache.solr.cloud.autoscaling.SearchRateTriggerIntegrationTest.testDeleteNode(SearchRateTriggerIntegrationTest.java:676)
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:1742)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:935)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:971)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:985)
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:944)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:830)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:891)
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(Statem

[jira] [Resolved] (SOLR-12765) Possibly incorrect format in JMX cache stats

[Andrzej Bialecki (JIRA)]

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

Andrzej Bialecki  resolved SOLR-12765.
--
   Resolution: Fixed
Fix Version/s: master (8.0)
   7.5
   7.4.1

> Possibly incorrect format in JMX cache stats
> 
>
> Key: SOLR-12765
> URL: https://issues.apache.org/jira/browse/SOLR-12765
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: metrics
>Affects Versions: 7.4, 7.5, master (8.0)
>Reporter: Bojan Smid
>Assignee: Andrzej Bialecki 
>Priority: Major
> Fix For: 7.4.1, 7.5, master (8.0)
>
> Attachments: SOLR-12765.patch
>
>
> I posted a question on ML 
> [https://mail-archives.apache.org/mod_mbox/lucene-solr-user/201809.mbox/%3CCAGniRXR4Ps%3D03X0uiByCn5ecUT2VY4TLV4iNcxCde3dxBnmC-w%40mail.gmail.com%3E|https://mail-archives.apache.org/mod_mbox/lucene-solr-user/201809.mbox/%3CCAGniRXR4Ps%3D03X0uiByCn5ecUT2VY4TLV4iNcxCde3dxBnmC-w%40mail.gmail.com%3E),]
>  , but didn't get feedback. Since it looks like a possible bug, I am opening 
> a ticket.
>  
>   It seems the format of cache mbeans changed with 7.4.0.  And from what I 
> see similar change wasn't made for other mbeans, which may mean it was 
> accidental and may be a bug.
>  
>   In Solr 7.3.* format was (each attribute on its own, numeric type):
>  
> mbean:
> solr:dom1=core,dom2=gettingstarted,dom3=shard1,dom4=replica_n1,category=CACHE,scope=searcher,name=filterCache
>  
> attributes:
>   lookups java.lang.Long = 0
>   hits java.lang.Long = 0
>   cumulative_evictions java.lang.Long = 0
>   size java.lang.Long = 0
>   hitratio java.lang.Float = 0.0
>   evictions java.lang.Long = 0
>   cumulative_lookups java.lang.Long = 0
>   cumulative_hitratio java.lang.Float = 0.0
>   warmupTime java.lang.Long = 0
>   inserts java.lang.Long = 0
>   cumulative_inserts java.lang.Long = 0
>   cumulative_hits java.lang.Long = 0
>  
>   With 7.4.0 there is a single attribute "Value" (java.lang.Object):
>  
> mbean:
> solr:dom1=core,dom2=gettingstarted,dom3=shard1,dom4=replica_n1,category=CACHE,scope=searcher,name=filterCache
>  
> attributes:
>   Value java.lang.Object = \{lookups=0, evictions=0, 
> cumulative_inserts=0, cumulative_hits=0, hits=0, cumulative_evictions=0, 
> size=0, hitratio=0.0, cumulative_lookups=0, cumulative_hitratio=0.0, 
> warmupTime=0, inserts=0}
>  



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

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

[jira] [Created] (SOLR-12779) Force field/term centric mode for multi-term synonyms with splitOnWhitespace=false

[Amrit Sarkar (JIRA)]

Amrit Sarkar created SOLR-12779:
---

 Summary: Force field/term centric mode for multi-term synonyms 
with splitOnWhitespace=false
 Key: SOLR-12779
 URL: https://issues.apache.org/jira/browse/SOLR-12779
 Project: Solr
  Issue Type: Improvement
  Security Level: Public (Default Security Level. Issues are Public)
Affects Versions: master (8.0)
Reporter: Amrit Sarkar


As Doug Turnbull pointed out on the solr-user mailing list: 
_http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201703.mbox/%3ccalg6hl8w_cpexcynvks2espdsttcz8_rbcyqwr+zpoxwu5a...@mail.gmail.com%3e_,
 (recommended reading, especially for his discussion of the limitations of the 
new sow=false request parameter), sow=false changes the queries edismax 
produces over multiple fields when any of the fields’ query-time analysis 
differs from the other fields’, e.g. if one field’s analyzer removes stopwords 
when another field’s doesn’t. In this case, rather than a 
dismax-query-per-whitespace-separated-term (edismax’s behavior when sow=true), 
a dismax query per field is produced. This can change results in general, but 
quite significantly when combined with the mm (min-should-match) request 
parameter: since min-should-match applies per field instead of per term, 
missing terms in one field’s analysis won’t disqualify docs from matching. E.g. 
query “Terminator 100” with request param “mm=100%” against both a title (text) 
field and a run_length (integer) field will result in the following queries:
When sow=true:
{code:java}
+(DisjunctionMaxQuery((title:terminator)) DisjunctionMaxQuery((run_length:[100 
TO 100] | title:100)))~2{code}
When sow=false:
{code:java}
+DisjunctionMaxQuery((run_length:[100 TO 100] | ((title:terminator 
title:100)~2))){code}
In the above scenario, when sow=true (and in versions of Solr before 6.5), 
“terminator” must appear in documents in order to produce a match. But when 
sow=false, a document can match if its run_length field is 100, even when the 
title does not contain “terminator”.

It is good to have an option to force term centric or query-centric matching at 
query parsing; so that expected behavior can be achieved; discussed under 
http://lucene.472066.n3.nabble.com/Split-on-whitespace-parameter-doubt-td4404185.html.



--
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-BadApples-7.x-Linux (64bit/jdk-11-ea+28) - Build # 93 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-BadApples-7.x-Linux/93/
Java: 64bit/jdk-11-ea+28 -XX:-UseCompressedOops -XX:+UseSerialGC

18 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.client.solrj.embedded.LargeVolumeBinaryJettyTest

Error Message:
2 threads leaked from SUITE scope at 
org.apache.solr.client.solrj.embedded.LargeVolumeBinaryJettyTest: 1) 
Thread[id=40, name=Connection evictor, state=TIMED_WAITING, 
group=TGRP-LargeVolumeBinaryJettyTest] at 
java.base@11/java.lang.Thread.sleep(Native Method) at 
app//org.apache.http.impl.client.IdleConnectionEvictor$1.run(IdleConnectionEvictor.java:66)
 at java.base@11/java.lang.Thread.run(Thread.java:834)2) 
Thread[id=42, name=Connection evictor, state=TIMED_WAITING, 
group=TGRP-LargeVolumeBinaryJettyTest] at 
java.base@11/java.lang.Thread.sleep(Native Method) at 
app//org.apache.http.impl.client.IdleConnectionEvictor$1.run(IdleConnectionEvictor.java:66)
 at java.base@11/java.lang.Thread.run(Thread.java:834)

Stack Trace:
com.carrotsearch.randomizedtesting.ThreadLeakError: 2 threads leaked from SUITE 
scope at org.apache.solr.client.solrj.embedded.LargeVolumeBinaryJettyTest: 
   1) Thread[id=40, name=Connection evictor, state=TIMED_WAITING, 
group=TGRP-LargeVolumeBinaryJettyTest]
at java.base@11/java.lang.Thread.sleep(Native Method)
at 
app//org.apache.http.impl.client.IdleConnectionEvictor$1.run(IdleConnectionEvictor.java:66)
at java.base@11/java.lang.Thread.run(Thread.java:834)
   2) Thread[id=42, name=Connection evictor, state=TIMED_WAITING, 
group=TGRP-LargeVolumeBinaryJettyTest]
at java.base@11/java.lang.Thread.sleep(Native Method)
at 
app//org.apache.http.impl.client.IdleConnectionEvictor$1.run(IdleConnectionEvictor.java:66)
at java.base@11/java.lang.Thread.run(Thread.java:834)
at __randomizedtesting.SeedInfo.seed([C5F19985C48257C4]:0)


FAILED:  
junit.framework.TestSuite.org.apache.solr.client.solrj.embedded.LargeVolumeBinaryJettyTest

Error Message:
1 thread leaked from SUITE scope at 
org.apache.solr.client.solrj.embedded.LargeVolumeBinaryJettyTest: 1) 
Thread[id=1817, name=Connection evictor, state=TIMED_WAITING, 
group=TGRP-LargeVolumeBinaryJettyTest] at 
java.base@11/java.lang.Thread.sleep(Native Method) at 
app//org.apache.http.impl.client.IdleConnectionEvictor$1.run(IdleConnectionEvictor.java:66)
 at java.base@11/java.lang.Thread.run(Thread.java:834)

Stack Trace:
com.carrotsearch.randomizedtesting.ThreadLeakError: 1 thread leaked from SUITE 
scope at org.apache.solr.client.solrj.embedded.LargeVolumeBinaryJettyTest: 
   1) Thread[id=1817, name=Connection evictor, state=TIMED_WAITING, 
group=TGRP-LargeVolumeBinaryJettyTest]
at java.base@11/java.lang.Thread.sleep(Native Method)
at 
app//org.apache.http.impl.client.IdleConnectionEvictor$1.run(IdleConnectionEvictor.java:66)
at java.base@11/java.lang.Thread.run(Thread.java:834)
at __randomizedtesting.SeedInfo.seed([C5F19985C48257C4]:0)


FAILED:  org.apache.solr.TestTolerantSearch.testGetFieldsPhaseError

Error Message:
Error from server at https://127.0.0.1:34871/solr/collection1: 
java.lang.NullPointerException  at 
org.apache.solr.handler.component.MoreLikeThisComponent.handleResponses(MoreLikeThisComponent.java:162)
  at 
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:426)
  at 
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:199)
  at org.apache.solr.core.SolrCore.execute(SolrCore.java:2541)  at 
org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:709)  at 
org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:515)  at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:377)
  at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:323)
  at 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1642)
  at 
org.apache.solr.client.solrj.embedded.JettySolrRunner$DebugFilter.doFilter(JettySolrRunner.java:139)
  at 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1642)
  at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:533) 
 at 
org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255)
  at 
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1595)
  at 
org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255)
  at 
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1317)
  at 
org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:203)
  at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:473)  
at 
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1564)
  at 
org.eclipse.jetty.server.handler.ScopedHandler.nextScope(S

Solr add doc with overwrite=false and presence of UpdateLog

[David Smiley]

Is   supported when there is an UpdateLog?  Perhaps
only when you are darned sure the doc is in fact uniuqe?  Maybe we should
throw an exception if you even try at all with an UpdateLog?

Context:  I'm working with Moshe, a contributor, on doc updates for nested
docs.  It's all very much WIP with TODOs but nonetheless
ConvertedLegacyTest failed due to some oddity.  It turns out this ancient
test deliberately adds docs with overwrite=false that already exist by the
same ID.  Youch!  This test very much pre-dated the UpdateLog, but at some
point the UpdateLog ended up in the default config thus this test ended up
using it.  It *appears* to be accidental luck that the test hasn't been
failing -- i.e. I doubt this situation above was deliberately made to
work.  We're fiddling with some related code and now it fails.

I'm inclined to think the test is broken by virtue of it using a config
with an UpdateLog -- something it wasn't originally designed for.
-- 
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
http://www.solrenterprisesearchserver.com

[JENKINS] Lucene-Solr-SmokeRelease-master - Build # 1128 - Still Failing

[Apache Jenkins Server]

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

No tests ran.

Build Log:
[...truncated 23265 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 2430 links (1981 relative) to 3172 anchors in 246 files
 [echo] Validated Links & Anchors via: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/solr/build/solr-ref-guide/bare-bones-html/

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

package:

-unpack-solr-tgz:

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

generate-maven-artifacts:

resolve:

resolve:

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

-ivy-fail-disallowed-ivy-version:

ivy-fail:

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

resolve:

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

-ivy-fail-disallowed-ivy-version:

ivy-fail:

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

resolve:

resolve:

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

-ivy-fail-disallowed-ivy-version:

ivy-fail:

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

resolve:

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

-ivy-fail-disallowed-ivy-version:

ivy-fail:

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

resolve:

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

-ivy-fail-disallowed-ivy-version:

ivy-fail:

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

resolve:

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

-ivy-fail-disallowed-ivy-version:

ivy-fail:

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

resolve:

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

-ivy-fail-disallowed-ivy-version:

ivy-fail:

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

resolve:

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

-ivy-fail-disallowed-ivy-version:

ivy-fail:

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

resolve:

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

-ivy-fail-disallowed-ivy-version:

ivy-fail:

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

resolve:

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

-ivy-fail-disallowed-ivy-version:

ivy-fail:

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

resolve:

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

-ivy-fail-disallowed-ivy-version:

ivy-fail:

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

resolve:

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

-ivy-fail-disallowed-ivy-version:

ivy-fail:

i

[JENKINS] Lucene-Solr-BadApples-master-Linux (64bit/jdk-10.0.1) - Build # 94 - Still unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-BadApples-master-Linux/94/
Java: 64bit/jdk-10.0.1 -XX:+UseCompressedOops -XX:+UseParallelGC

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

Error Message:
Replica didn't have the proper urlScheme in the ClusterState

Stack Trace:
java.lang.AssertionError: Replica didn't have the proper urlScheme in the 
ClusterState
at 
__randomizedtesting.SeedInfo.seed([493FAE3B5C9B0227:C16B91E1F2676FDF]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.cloud.SSLMigrationTest.assertReplicaInformation(SSLMigrationTest.java:104)
at 
org.apache.solr.cloud.SSLMigrationTest.testMigrateSSL(SSLMigrationTest.java:97)
at org.apache.solr.cloud.SSLMigrationTest.test(SSLMigrationTest.java:61)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1742)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:935)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:971)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:985)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:1008)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:983)
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:944)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:830)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:891)
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(S

[GitHub] lucene-solr pull request #455: WIP: SOLR-12638

[dsmiley]

Github user dsmiley commented on a diff in the pull request:

https://github.com/apache/lucene-solr/pull/455#discussion_r218293921
  
--- Diff: 
solr/core/src/java/org/apache/solr/update/processor/DistributedUpdateProcessor.java
 ---
@@ -1184,7 +1196,16 @@ protected boolean versionAdd(AddUpdateCommand cmd) 
throws IOException {
 
 // TODO: possibly set checkDeleteByQueries as a flag on the 
command?
 doLocalAdd(cmd);
-
+
+if(lastKnownVersion != null && 
req.getSchema().isUsableForChildDocs() &&
--- End diff --

This may very well be right but can you tell me why you added this delete 
here at this line and why the delete is version-dependent?


---

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

[GitHub] lucene-solr issue #455: WIP: SOLR-12638

[dsmiley]

Github user dsmiley commented on the issue:

https://github.com/apache/lucene-solr/pull/455
  
ConvertedLegacyTest fails in part because line 306 adds with 
overwrite=false -- a bit of a dubious Solr feature that is probably not 
properly compatible with the UpdateLog which makes various assumptions about 
the uniqueKey being unique.  I'll email the dev list to see what others think 
but I'm inclined to think overwrite=false ought to be explicitly forbidden with 
an UpdateLog in place.  That ancient legacy test can use a config that doesn't 
have an updateLog.


---

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

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

[Apache Jenkins Server]

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

3 tests failed.
FAILED:  
org.apache.solr.cloud.autoscaling.ScheduledMaintenanceTriggerTest.testInactiveShardCleanup

Error Message:
should be at least one inactive event

Stack Trace:
java.lang.AssertionError: should be at least one inactive event
at 
__randomizedtesting.SeedInfo.seed([DD3A5CBFED94B8B7:C0169CCD8CD79FBC]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.cloud.autoscaling.ScheduledMaintenanceTriggerTest.testInactiveShardCleanup(ScheduledMaintenanceTriggerTest.java:224)
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:1742)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:935)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:971)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:985)
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:944)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:830)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:891)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:748)


FAILED:  
org.apache.solr.cloud.autoscaling.sim.TestSimComputePlanAction.testNodeLost

Error Message:
Timed out waiting for replicas of new collection to be active Live Nodes: 
[127.0.0.1:10001_solr, 127.0.0.1:1_solr] Last available state: 
DocCollection(testN

[jira] [Commented] (SOLR-12725) ParseDateFieldUpdateProcessorFactory should reuse ParsePosition

[David Smiley (JIRA)]

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

David Smiley commented on SOLR-12725:
-

bq. I like that idea, but it seems a lot more involved then just re-using a 
single ParsePosition repeatedly for a single input string? should probably be 
it's own issue?

It's not an either-or    quoting myself "we might _also_" .  Yes perhaps a 
different issue though I don't care either way.

bq. IIUC you seem to be theorizing that by re-using a single ParsePosition ...

No; my idea has nothing to do with ParsePosition.  It's simply about which 
index into the list of formats do you start attempting to see if it matched.  
It'd loop back to the first and ultimately try them all if need be.

> ParseDateFieldUpdateProcessorFactory should reuse ParsePosition
> ---
>
> Key: SOLR-12725
> URL: https://issues.apache.org/jira/browse/SOLR-12725
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Andrzej Bialecki 
>Assignee: Andrzej Bialecki 
>Priority: Minor
>
> {{ParseDateFieldUpdateProcessorFactory.parseInstant}} repeatedly calls all 
> configured date parsers ({{DateTimeFormatter}}-s) for each incoming date-like 
> field. However, it uses {{DateTimeFormatter.parse(dateStr)}} method that 
> needs to allocate a throwaway instance of {{ParsePosition}}, instead of 
> {{DateTimeFormatter.parse(dateStr, parsePosition)}}.
> Javadocs for this method suggest reusing (and reseting) a single instance of 
> {{ParsePosition}} for multiple calls in order to reduce object allocations.



--
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] [Reopened] (SOLR-12759) Disable ExtractingRequestHandlerTest on JDK 11

[David Smiley (JIRA)]

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

David Smiley reopened SOLR-12759:
-

Great idea Hoss!  I think I'd prefer something a little simpler that addresses 
the core concern:  If the current JVM/config exhibits the problem, then 
assumeTrue to bail out.  Otherwise continue as normal.  No need to even care 
with the JDK is.  I think this'll be easier to read, and doesn't demand future 
work to back out the checks when the JDK is fixed.  I'll do this.

> Disable ExtractingRequestHandlerTest on JDK 11
> --
>
> Key: SOLR-12759
> URL: https://issues.apache.org/jira/browse/SOLR-12759
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: contrib - Solr Cell (Tika extraction)
> Environment: JDK 11 and Tika 1.x
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Minor
> Fix For: 7.6
>
>
> ExtractingRequestHandlerTest has failed on a JDK 11 RC due to two conspiring 
> problems: (A) Tika 1.x sometimes calls Date.toString() when extracting 
> metadata (unreleased 2.x will fix this), (B) JDK 11 RC has a bug in some 
> locales like Arabic in which a Date.toString() will have a timezone offset 
> using its locale's characters for the digits instead of using EN_US.  
> I'll add an "assume" check so we don't see failures about this.



--
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-8505) IndexWriter#addIndices should not sort indices if they are not already sorted

[Lucene/Solr QA (JIRA)]

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

Lucene/Solr QA commented on LUCENE-8505:


| (/) *{color:green}+1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green}  0m 
 0s{color} | {color:green} The patch appears to include 1 new or modified test 
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  0m 
24s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  0m 
19s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green}  0m 
19s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Release audit (RAT) {color} | 
{color:green}  0m 19s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Check forbidden APIs {color} | 
{color:green}  0m 19s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Validate source patterns {color} | 
{color:green}  0m 19s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 11m 
24s{color} | {color:green} core in the patch passed. {color} |
| {color:black}{color} | {color:black} {color} | {color:black} 13m 59s{color} | 
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | LUCENE-8505 |
| JIRA Patch URL | 
https://issues.apache.org/jira/secure/attachment/12939986/LUCENE-8505.patch |
| Optional Tests |  compile  javac  unit  ratsources  checkforbiddenapis  
validatesourcepatterns  |
| uname | Linux lucene1-us-west 4.4.0-130-generic #156~14.04.1-Ubuntu SMP Thu 
Jun 14 13:51:47 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | ant |
| Personality | 
/home/jenkins/jenkins-slave/workspace/PreCommit-LUCENE-Build/sourcedir/dev-tools/test-patch/lucene-solr-yetus-personality.sh
 |
| git revision | master / 7d0a778 |
| ant | version: Apache Ant(TM) version 1.9.3 compiled on July 24 2018 |
| Default Java | 1.8.0_172 |
|  Test Results | 
https://builds.apache.org/job/PreCommit-LUCENE-Build/93/testReport/ |
| modules | C: lucene/core U: lucene/core |
| Console output | 
https://builds.apache.org/job/PreCommit-LUCENE-Build/93/console |
| Powered by | Apache Yetus 0.7.0   http://yetus.apache.org |


This message was automatically generated.



> IndexWriter#addIndices should not sort indices if they are not already sorted
> -
>
> Key: LUCENE-8505
> URL: https://issues.apache.org/jira/browse/LUCENE-8505
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Jim Ferenczi
>Priority: Minor
> Attachments: LUCENE-8505.patch
>
>
> Today IndexWriter#addIndices silently re-sort non-sorted indices when they 
> are added in a sorted index. This is not safe because the sort is done 
> entirely in memory and cannot handle big segments efficiently. This leniency 
> was added because prior to 6.5, segments produced by flushes were not sorted, 
> they had to wait for a merge to apply the index sorting. Now that segments 
> are always sorted (LUCENE-7579) we should remove this ability and throw an 
> error if the sort of the current index does not match with the candidate.



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

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

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

[Apache Jenkins Server]

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

1 tests failed.
FAILED:  
org.apache.solr.cloud.autoscaling.sim.TestSimTriggerIntegration.testEventQueue

Error Message:
java.util.concurrent.ExecutionException: java.io.IOException: 
org.apache.solr.api.ApiBag$ExceptionWithErrObject: Error in command payload, 
errors: [{suspend-trigger={name=.scheduled_maintenance}, errorMessages=[No 
trigger exists with name: .scheduled_maintenance]}], 

Stack Trace:
java.io.IOException: java.util.concurrent.ExecutionException: 
java.io.IOException: org.apache.solr.api.ApiBag$ExceptionWithErrObject: Error 
in command payload, errors: [{suspend-trigger={name=.scheduled_maintenance}, 
errorMessages=[No trigger exists with name: .scheduled_maintenance]}], 
at 
__randomizedtesting.SeedInfo.seed([2512F0926DF71D09:ECA7B23C6490DBFC]:0)
at 
org.apache.solr.cloud.autoscaling.sim.SimCloudManager.request(SimCloudManager.java:632)
at 
org.apache.solr.cloud.autoscaling.sim.SimCloudManager$1.request(SimCloudManager.java:211)
at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219)
at 
org.apache.solr.cloud.autoscaling.sim.TestSimTriggerIntegration.setupTest(TestSimTriggerIntegration.java:129)
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:1742)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:969)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:985)
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:944)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:830)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:891)
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.randomizedt

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

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/2761/
Java: 64bit/jdk1.8.0_172 -XX:+UseCompressedOops -XX:+UseParallelGC

2 tests failed.
FAILED:  org.apache.solr.handler.TestSolrConfigHandlerConcurrent.test

Error Message:


Stack Trace:
java.lang.NullPointerException
at 
__randomizedtesting.SeedInfo.seed([6B720754CB5023B4:E326388E65AC4E4C]:0)
at 
org.apache.solr.handler.TestSolrConfigHandlerConcurrent.test(TestSolrConfigHandlerConcurrent.java:93)
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:1742)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:935)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:971)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:985)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:1008)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:983)
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:944)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:830)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:891)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:748)


FAILED:  org.apache.solr.handler.TestSolrConfigHandlerConcurrent.test

Error Message:


Stack Trace:
java.lang.NullPointerException
at 
__ran

[JENKINS] Lucene-Solr-SmokeRelease-7.5 - Build # 6 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-7.5/6/

No tests ran.

Build Log:
[...truncated 23296 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: WARNING: simulations.adoc: line 25: section 
title out of sequence: expected level 3, got level 4
[asciidoctor:convert] asciidoctor: WARNING: simulations.adoc: line 92: section 
title out of sequence: expected level 3, got level 4
[asciidoctor:convert] asciidoctor: WARNING: simulations.adoc: line 138: section 
title out of sequence: expected level 3, got level 4
[asciidoctor:convert] asciidoctor: ERROR: solr-glossary.adoc: line 1: invalid 
part, must have at least one section (e.g., chapter, appendix, etc.)
[asciidoctor:convert] asciidoctor: WARNING: simulations.adoc: line 25: section 
title out of sequence: expected levels 0 or 1, got level 2
[asciidoctor:convert] asciidoctor: WARNING: simulations.adoc: line 92: section 
title out of sequence: expected levels 0 or 1, got level 2
[asciidoctor:convert] asciidoctor: WARNING: simulations.adoc: line 138: section 
title out of sequence: expected levels 0 or 1, got level 2
 [java] Processed 2343 links (1894 relative) to 3145 anchors in 245 files
 [echo] Validated Links & Anchors via: 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.5/solr/build/solr-ref-guide/bare-bones-html/

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

package:

-unpack-solr-tgz:

-ensure-solr-tgz-exists:
[mkdir] Created dir: 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.5/solr/build/solr.tgz.unpacked
[untar] Expanding: 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.5/solr/package/solr-7.5.0.tgz
 into 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.5/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-7.5/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-7.5/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-7.5/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-7.5/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-7.5/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-7.5/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-7.5/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-7.5/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-7.5/lucene/top-level-ivy-settings.xml

resolve:

ivy-av

[jira] [Commented] (SOLR-12725) ParseDateFieldUpdateProcessorFactory should reuse ParsePosition

[Hoss Man (JIRA)]

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

Hoss Man commented on SOLR-12725:
-

{quote}We might also want to keep track of which pattern last matched for the 
field we are currently parsing.
{quote}
I like that idea, but it seems a lot more involved then just re-using a single 
ParsePosition repeatedly for a single input string? should probably be it's own 
issue?
{quote}Although there is some risk that it's wrong, and it's possible the 
formats might be written in a way that is order-dependent, and thus could 
produce a different result based on the sequence of document's values.
{quote}
IIUC you seem to be theorizing that by re-using a single ParsePosition, we 
might wind up in situations where a parser early in the list leaves the 
ParsePosition in a state that causes a parser laterin the list to produce 
different results then if it was used on it's own ... that would seem like a 
straight up bug to me – if we are going to re-use ParsePosition objects, then 
it seems like we should do so _solely_ to avoid the extra object creation – 
calling \{setIndex(0)} before every parse call (and checking that the full 
string was consumed after every parse call)

> ParseDateFieldUpdateProcessorFactory should reuse ParsePosition
> ---
>
> Key: SOLR-12725
> URL: https://issues.apache.org/jira/browse/SOLR-12725
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Andrzej Bialecki 
>Assignee: Andrzej Bialecki 
>Priority: Minor
>
> {{ParseDateFieldUpdateProcessorFactory.parseInstant}} repeatedly calls all 
> configured date parsers ({{DateTimeFormatter}}-s) for each incoming date-like 
> field. However, it uses {{DateTimeFormatter.parse(dateStr)}} method that 
> needs to allocate a throwaway instance of {{ParsePosition}}, instead of 
> {{DateTimeFormatter.parse(dateStr, parsePosition)}}.
> Javadocs for this method suggest reusing (and reseting) a single instance of 
> {{ParsePosition}} for multiple calls in order to reduce object allocations.



--
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-11-ea+28) - Build # 22875 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/22875/
Java: 64bit/jdk-11-ea+28 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC

19 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.update.processor.TimeRoutedAliasUpdateProcessorTest

Error Message:
5 threads leaked from SUITE scope at 
org.apache.solr.update.processor.TimeRoutedAliasUpdateProcessorTest: 1) 
Thread[id=643, name=zkConnectionManagerCallback-204-thread-1, state=WAITING, 
group=TGRP-TimeRoutedAliasUpdateProcessorTest] at 
java.base@11/jdk.internal.misc.Unsafe.park(Native Method) at 
java.base@11/java.util.concurrent.locks.LockSupport.park(LockSupport.java:194)  
   at 
java.base@11/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2081)
 at 
java.base@11/java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:433)
 at 
java.base@11/java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1054)
 at 
java.base@11/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1114)
 at 
java.base@11/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
 at java.base@11/java.lang.Thread.run(Thread.java:834)2) 
Thread[id=642, name=test-261-thread-2-EventThread, state=WAITING, 
group=TGRP-TimeRoutedAliasUpdateProcessorTest] at 
java.base@11/jdk.internal.misc.Unsafe.park(Native Method) at 
java.base@11/java.util.concurrent.locks.LockSupport.park(LockSupport.java:194)  
   at 
java.base@11/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2081)
 at 
java.base@11/java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:433)
 at 
app//org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:502)3) 
Thread[id=631, name=test-261-thread-1, state=WAITING, 
group=TGRP-TimeRoutedAliasUpdateProcessorTest] at 
java.base@11/jdk.internal.misc.Unsafe.park(Native Method) at 
java.base@11/java.util.concurrent.locks.LockSupport.park(LockSupport.java:194)  
   at 
java.base@11/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2081)
 at 
java.base@11/java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:433)
 at 
java.base@11/java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1054)
 at 
java.base@11/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1114)
 at 
java.base@11/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
 at java.base@11/java.lang.Thread.run(Thread.java:834)4) 
Thread[id=641, name=test-261-thread-2-SendThread(127.0.0.1:39089), 
state=TIMED_WAITING, group=TGRP-TimeRoutedAliasUpdateProcessorTest] at 
java.base@11/java.lang.Thread.sleep(Native Method) at 
app//org.apache.zookeeper.client.StaticHostProvider.next(StaticHostProvider.java:105)
 at 
app//org.apache.zookeeper.ClientCnxn$SendThread.startConnect(ClientCnxn.java:1000)
 at 
app//org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1063)5) 
Thread[id=632, name=test-261-thread-2, state=WAITING, 
group=TGRP-TimeRoutedAliasUpdateProcessorTest] at 
java.base@11/jdk.internal.misc.Unsafe.park(Native Method) at 
java.base@11/java.util.concurrent.locks.LockSupport.park(LockSupport.java:194)  
   at 
java.base@11/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2081)
 at 
java.base@11/java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:433)
 at 
java.base@11/java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1054)
 at 
java.base@11/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1114)
 at 
java.base@11/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
 at java.base@11/java.lang.Thread.run(Thread.java:834)

Stack Trace:
com.carrotsearch.randomizedtesting.ThreadLeakError: 5 threads leaked from SUITE 
scope at org.apache.solr.update.processor.TimeRoutedAliasUpdateProcessorTest: 
   1) Thread[id=643, name=zkConnectionManagerCallback-204-thread-1, 
state=WAITING, group=TGRP-TimeRoutedAliasUpdateProcessorTest]
at java.base@11/jdk.internal.misc.Unsafe.park(Native Method)
at 
java.base@11/java.util.concurrent.locks.LockSupport.park(LockSupport.java:194)
at 
java.base@11/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2081)
at 
java.base@11/java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:433)
at 
java.base@11/java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1054)

Re: Collection creation via CLI sets maxShardsPerNode as -1

[Edward Ribeiro]

Thanks Jan,

This comment pretty much summarised my issue:
https://issues.apache.org/jira/browse/SOLR-11807?focusedCommentId=16517943&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16517943

Edward

On Mon, Sep 17, 2018 at 5:29 PM, Jan Høydahl  wrote:

> There is already several JIRAs on this bug, see SOLR-11807
> , SOLR-11823
> , SOLR-12489
> , SOLR-11676
> , and should be fixed
> with the upcoming 7.5 release.
>
> --
> Jan Høydahl, search solution architect
> Cominvent AS - www.cominvent.com
>
> 17. sep. 2018 kl. 22:25 skrev Edward Ribeiro :
>
> Jeez, I should have posted this on user@ mailing list, sorry about that.
>
> On Mon, Sep 17, 2018 at 4:35 PM, Edward Ribeiro 
> wrote:
>
>> When using the CLI to create a collection on a single cloud node with the
>> following command:
>>
>> $ bin/solr create -c test -shards 1 -replicationFactor 1
>>
>> It creates the collection with maxShardsPerNode as -1 as seen here:
>> https://github.com/apache/lucene-solr/blob/c97f27b06c1d7c250
>> e9596a9bc7bf5ca11ef6ad3/solr/core/src/java/org/apache/solr/
>> util/SolrCLI.java#L1530-L1534
>>
>> As we can see, it even allows the setting of maxShardsPerNode as a
>> parameter, but according to 7.4 documentation the default value would be 1
>> instead of -1 (see https://lucene.apache.org/solr
>> /guide/7_4/collections-api.html ). If I create the collection directly
>> via HTTP request
>>
>> curl -X POST 'http://localhost:8983/solr/admin/collections?action=CREATE&;
>> name=test2&numShards=1&replicationFactor=1'
>>
>> It creates the collection with the default maxShardsPerNode of 1.
>>
>> It seems that the fix is trivial (either code or docs), but I would like
>> to know if this is really a bug or not, that is, should I provide a fix or
>> leave it as-is?
>>
>> PS: As a bit of context, I was bited by this when demo-ing Solr
>> backup/restore capabilities and it refused to recover a collection with
>> maxShardsPerNode == -1.
>>
>> Best regards,
>> Edward
>>
>
>
>

[jira] [Comment Edited] (SOLR-12759) Disable ExtractingRequestHandlerTest on JDK 11

[Hoss Man (JIRA)]

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

Hoss Man edited comment on SOLR-12759 at 9/17/18 9:34 PM:
--

nitpick...

in the case of "broken in current RC of third-party X" type test 
assumptions/workarounds, i think we should try as much as possible to ensure 
that the the assumption/workaround starts failing loudly once the underlying 
third-party bug is fixed, so we don't inadvertently leave a bunch of tests 
disabled forever.

Maybe something like this (unless i've got my logic backwards)...
{code:java}
final boolean brokenJDKDates = someMethodThatReturnsFalseIfJDK11IsBroken();
if (brokenJDKDates) {
  asumeTrue("SOLR-12759 JDK 11 RCs currently don't work",
System.getProperty("java.version").startsWith("11"));
} else {
  assertFalse("SOLR-12759 JDK 11 RCs are not expected to work, apparently they 
do now, test should be updated",
  System.getProperty("java.version").startsWith("11"));
}{code}


was (Author: hossman):
nitpick...

in the case of "broken in current RC of third-party X" type test 
assumptions/workarounds, i think we should try as much as possible to ensure 
that the the assumption/workaround starts failing loudly once the underlying 
third-party bug is fixed, so we don't inadvertently leave a bunch of tests 
disabled forever.

Maybe something like this (unless i've got my logic backwards)...
{code:java}
final boolean brokenJDKDates = someMethodThatReturnsFalseIfJDK11IsBroken();
if (brokenJDKDates) {
  asumeTrue("SOLR-12759 JDK 11 RCs currently don't work",
System.getProperty("java.version").startsWith("11"));
} else {
  asumeFalse("SOLR-12759 JDK 11 RCs are not expected to work, apparently they 
do now, test should be updated",
 System.getProperty("java.version").startsWith("11"));
}{code}

> Disable ExtractingRequestHandlerTest on JDK 11
> --
>
> Key: SOLR-12759
> URL: https://issues.apache.org/jira/browse/SOLR-12759
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: contrib - Solr Cell (Tika extraction)
> Environment: JDK 11 and Tika 1.x
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Minor
> Fix For: 7.6
>
>
> ExtractingRequestHandlerTest has failed on a JDK 11 RC due to two conspiring 
> problems: (A) Tika 1.x sometimes calls Date.toString() when extracting 
> metadata (unreleased 2.x will fix this), (B) JDK 11 RC has a bug in some 
> locales like Arabic in which a Date.toString() will have a timezone offset 
> using its locale's characters for the digits instead of using EN_US.  
> I'll add an "assume" check so we don't see failures about this.



--
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-12759) Disable ExtractingRequestHandlerTest on JDK 11

[Hoss Man (JIRA)]

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

Hoss Man commented on SOLR-12759:
-

nitpick...

in the case of "broken in current RC of third-party X" type test 
assumptions/workarounds, i think we should try as much as possible to ensure 
that the the assumption/workaround starts failing loudly once the underlying 
third-party bug is fixed, so we don't inadvertently leave a bunch of tests 
disabled forever.

Maybe something like this (unless i've got my logic backwards)...
{code:java}
final boolean brokenJDKDates = someMethodThatReturnsFalseIfJDK11IsBroken();
if (brokenJDKDates) {
  asumeTrue("SOLR-12759 JDK 11 RCs currently don't work",
System.getProperty("java.version").startsWith("11"));
} else {
  asumeFalse("SOLR-12759 JDK 11 RCs are not expected to work, apparently they 
do now, test should be updated",
 System.getProperty("java.version").startsWith("11"));
}{code}

> Disable ExtractingRequestHandlerTest on JDK 11
> --
>
> Key: SOLR-12759
> URL: https://issues.apache.org/jira/browse/SOLR-12759
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: contrib - Solr Cell (Tika extraction)
> Environment: JDK 11 and Tika 1.x
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Minor
> Fix For: 7.6
>
>
> ExtractingRequestHandlerTest has failed on a JDK 11 RC due to two conspiring 
> problems: (A) Tika 1.x sometimes calls Date.toString() when extracting 
> metadata (unreleased 2.x will fix this), (B) JDK 11 RC has a bug in some 
> locales like Arabic in which a Date.toString() will have a timezone offset 
> using its locale's characters for the digits instead of using EN_US.  
> I'll add an "assume" check so we don't see failures about this.



--
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-8482) Boosting by geo distance

[Adrien Grand (JIRA)]

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

Adrien Grand commented on LUCENE-8482:
--

bq. New patch where we approximate using a box query which removes the need of 
sampling too often and increase the performance.

Woohoo!

Given the positive effect of approximating using a box, I'm wondering what the 
performance is if we skip the byte[] comparisons in IntersectVisitor#visit() 
and all all doc IDs that are greater than the current doc ID?

Patch looks good overall. I agree that binary searching is easier than 
inverting the distance computation. I'm not sure it's right to use 
EARTH_MEAN_RADIUS_METERS as an initial distance though, should it rather be 
something like EARTH_MEAN_RADIUS_METERS * Math.PI?

bq. On the other hand, I was trying to develop a random test that compares the 
results from boosting and from sorting. This test sporadically fails because 
for points which are very close, distance is slightly different but the score 
is the same due to rounding errors.

I think that's expected. If we want to build such a test, maybe we could sort 
by a custom FieldComparator (SortField allows to do that) that computes the 
expected scores as a float? This way the accuracy loss would be the same on 
both sides?

> Boosting by geo distance
> 
>
> Key: LUCENE-8482
> URL: https://issues.apache.org/jira/browse/LUCENE-8482
> Project: Lucene - Core
>  Issue Type: New Feature
>Reporter: Adrien Grand
>Priority: Minor
> Attachments: LUCENE-8482.patch, LUCENE-8482.patch
>
>
> Similarly to LUCENE-8340 it would be nice to have an easy and efficient way 
> to fold geo distance into scoring formulas in order to boost by proximity.



--
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: Collection creation via CLI sets maxShardsPerNode as -1

[Jan Høydahl]

There is already several JIRAs on this bug, see SOLR-11807 
, SOLR-11823 
, SOLR-12489 
, SOLR-11676 
, and should be fixed with 
the upcoming 7.5 release.

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

> 17. sep. 2018 kl. 22:25 skrev Edward Ribeiro :
> 
> Jeez, I should have posted this on user@ mailing list, sorry about that.
> 
> On Mon, Sep 17, 2018 at 4:35 PM, Edward Ribeiro  > wrote:
> When using the CLI to create a collection on a single cloud node with the 
> following command:
> 
> $ bin/solr create -c test -shards 1 -replicationFactor 1
> 
> It creates the collection with maxShardsPerNode as -1 as seen here: 
> https://github.com/apache/lucene-solr/blob/c97f27b06c1d7c250e9596a9bc7bf5ca11ef6ad3/solr/core/src/java/org/apache/solr/util/SolrCLI.java#L1530-L1534
>  
> 
> 
> As we can see, it even allows the setting of maxShardsPerNode as a parameter, 
> but according to 7.4 documentation the default value would be 1 instead of -1 
> (see https://lucene.apache.org/solr/guide/7_4/collections-api.html 
>  ). If I 
> create the collection directly via HTTP request
> 
> curl -X POST 
> 'http://localhost:8983/solr/admin/collections?action=CREATE&name=test2&numShards=1&replicationFactor=1
>  
> '
> 
> It creates the collection with the default maxShardsPerNode of 1.
> 
> It seems that the fix is trivial (either code or docs), but I would like to 
> know if this is really a bug or not, that is, should I provide a fix or leave 
> it as-is?
> 
> PS: As a bit of context, I was bited by this when demo-ing Solr 
> backup/restore capabilities and it refused to recover a collection with 
> maxShardsPerNode == -1.
> 
> Best regards,
> Edward
> 

Re: Collection creation via CLI sets maxShardsPerNode as -1

[Edward Ribeiro]

Jeez, I should have posted this on user@ mailing list, sorry about that.

On Mon, Sep 17, 2018 at 4:35 PM, Edward Ribeiro 
wrote:

> When using the CLI to create a collection on a single cloud node with the
> following command:
>
> $ bin/solr create -c test -shards 1 -replicationFactor 1
>
> It creates the collection with maxShardsPerNode as -1 as seen here:
> https://github.com/apache/lucene-solr/blob/c97f27b06c1d7c250e9596a9bc7bf5
> ca11ef6ad3/solr/core/src/java/org/apache/solr/util/SolrCLI.
> java#L1530-L1534
>
> As we can see, it even allows the setting of maxShardsPerNode as a
> parameter, but according to 7.4 documentation the default value would be 1
> instead of -1 (see https://lucene.apache.org/solr/guide/7_4/collections-
> api.html ). If I create the collection directly via HTTP request
>
> curl -X POST 'http://localhost:8983/solr/admin/collections?action=
> CREATE&name=test2&numShards=1&replicationFactor=1'
>
> It creates the collection with the default maxShardsPerNode of 1.
>
> It seems that the fix is trivial (either code or docs), but I would like
> to know if this is really a bug or not, that is, should I provide a fix or
> leave it as-is?
>
> PS: As a bit of context, I was bited by this when demo-ing Solr
> backup/restore capabilities and it refused to recover a collection with
> maxShardsPerNode == -1.
>
> Best regards,
> Edward
>

[JENKINS] Lucene-Solr-repro - Build # 1491 - Still Unstable

[Apache Jenkins Server]

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

[...truncated 28 lines...]
[repro] Jenkins log URL: 
https://builds.apache.org/job/Lucene-Solr-BadApples-Tests-master/156/consoleText

[repro] Revision: b2b597b0383eec0b1bf4059922cf367fdee2be21

[repro] Repro line:  ant test  -Dtestcase=TestSimComputePlanAction 
-Dtests.method=testNodeAdded -Dtests.seed=70CD874E72CE4A70 -Dtests.multiplier=2 
-Dtests.slow=true -Dtests.badapples=true -Dtests.locale=sr-BA 
-Dtests.timezone=Europe/Busingen -Dtests.asserts=true 
-Dtests.file.encoding=US-ASCII

[repro] git rev-parse --abbrev-ref HEAD
[repro] git rev-parse HEAD
[repro] Initial local git branch/revision: 
7d0a7782fa7e99250bccfb4d3e995485c3f0ca19
[repro] git fetch
[repro] git checkout b2b597b0383eec0b1bf4059922cf367fdee2be21

[...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]   TestSimComputePlanAction
[repro] ant compile-test

[...truncated 3423 lines...]
[repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=5 
-Dtests.class="*.TestSimComputePlanAction" -Dtests.showOutput=onerror  
-Dtests.seed=70CD874E72CE4A70 -Dtests.multiplier=2 -Dtests.slow=true 
-Dtests.badapples=true -Dtests.locale=sr-BA -Dtests.timezone=Europe/Busingen 
-Dtests.asserts=true -Dtests.file.encoding=US-ASCII

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

[repro] Failures:
[repro]   1/5 failed: 
org.apache.solr.cloud.autoscaling.sim.TestSimComputePlanAction
[repro] git checkout 7d0a7782fa7e99250bccfb4d3e995485c3f0ca19

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

[...truncated 5 lines...]

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

[GitHub] lucene-solr pull request #451: LUCENE-8496: Add selective indexing to BKD/PO...

[jpountz]

Github user jpountz commented on a diff in the pull request:

https://github.com/apache/lucene-solr/pull/451#discussion_r218184521
  
--- Diff: 
lucene/codecs/src/java/org/apache/lucene/codecs/simpletext/SimpleTextBKDReader.java
 ---
@@ -53,15 +54,16 @@
   final int version;
   protected final int packedBytesLength;
 
-  public SimpleTextBKDReader(IndexInput in, int numDims, int 
maxPointsInLeafNode, int bytesPerDim, long[] leafBlockFPs, byte[] 
splitPackedValues,
+  public SimpleTextBKDReader(IndexInput in, int numDataDims, int 
numIndexDims, int maxPointsInLeafNode, int bytesPerDim, long[] leafBlockFPs, 
byte[] splitPackedValues,
  byte[] minPackedValue, byte[] maxPackedValue, 
long pointCount, int docCount) throws IOException {
 this.in = in;
-this.numDims = numDims;
+this.numDataDims = numDataDims;
+this.numIndexDims = numIndexDims;
 this.maxPointsInLeafNode = maxPointsInLeafNode;
 this.bytesPerDim = bytesPerDim;
 // no version check here because callers of this API (SimpleText) have 
no back compat:
-bytesPerIndexEntry = numDims == 1 ? bytesPerDim : bytesPerDim + 1;
-packedBytesLength = numDims * bytesPerDim;
+bytesPerIndexEntry = numDataDims == 1 ? bytesPerDim : bytesPerDim + 1;
+packedBytesLength = numDataDims * bytesPerDim;
--- End diff --

can we make it numIndexDims on the two above lines?


---

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

[GitHub] lucene-solr pull request #451: LUCENE-8496: Add selective indexing to BKD/PO...

[jpountz]

Github user jpountz commented on a diff in the pull request:

https://github.com/apache/lucene-solr/pull/451#discussion_r218197102
  
--- Diff: 
lucene/core/src/java/org/apache/lucene/codecs/lucene60/Lucene60FieldInfosFormat.java
 ---
@@ -149,9 +149,14 @@ public FieldInfos read(Directory directory, 
SegmentInfo segmentInfo, String segm
 attributes = lastAttributes;
   }
   lastAttributes = attributes;
-  int pointDimensionCount = input.readVInt();
+  int packedDimensionCount = input.readVInt();
+  int pointDataDimensionCount = 0x & packedDimensionCount;
+  int pointIndexDimensionCount = packedDimensionCount >>> 16;
+  if (pointIndexDimensionCount == 0) {
+pointIndexDimensionCount = pointDataDimensionCount;
+  }
--- End diff --

could we use a new version number instead to handle backcompat?


---

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

[GitHub] lucene-solr pull request #451: LUCENE-8496: Add selective indexing to BKD/PO...

[jpountz]

Github user jpountz commented on a diff in the pull request:

https://github.com/apache/lucene-solr/pull/451#discussion_r218199848
  
--- Diff: lucene/core/src/java/org/apache/lucene/util/bkd/BKDReader.java ---
@@ -52,10 +53,17 @@
   /** Caller must pre-seek the provided {@link IndexInput} to the index 
location that {@link BKDWriter#finish} returned */
   public BKDReader(IndexInput in) throws IOException {
 version = CodecUtil.checkHeader(in, BKDWriter.CODEC_NAME, 
BKDWriter.VERSION_START, BKDWriter.VERSION_CURRENT);
-numDims = in.readVInt();
+int packedDims = in.readVInt();
+if (version >= BKDWriter.VERSION_LEAF_STORES_BOUNDS) {
+  numDataDims = packedDims & 0x;
+  numIndexDims = packedDims >>> 16;
--- End diff --

let's read two vints instead?


---

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

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

[Policeman Jenkins Server]

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

1 tests failed.
FAILED:  org.apache.solr.cloud.MoveReplicaHDFSTest.testFailedMove

Error Message:
No live SolrServers available to handle this 
request:[https://127.0.0.1:44075/solr/MoveReplicaHDFSTest_failed_coll_true, 
https://127.0.0.1:35785/solr/MoveReplicaHDFSTest_failed_coll_true]

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: No live SolrServers available 
to handle this 
request:[https://127.0.0.1:44075/solr/MoveReplicaHDFSTest_failed_coll_true, 
https://127.0.0.1:35785/solr/MoveReplicaHDFSTest_failed_coll_true]
at 
__randomizedtesting.SeedInfo.seed([A437A7F62AD99B8A:EFA74049D0A4E5A]:0)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:462)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1107)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:884)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:994)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:817)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:194)
at org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:942)
at 
org.apache.solr.cloud.MoveReplicaTest.testFailedMove(MoveReplicaTest.java:289)
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:1742)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:935)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:971)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:985)
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:944)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:830)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:891)
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.evalu

Collection creation via CLI sets maxShardsPerNode as -1

[Edward Ribeiro]

When using the CLI to create a collection on a single cloud node with the
following command:

$ bin/solr create -c test -shards 1 -replicationFactor 1

It creates the collection with maxShardsPerNode as -1 as seen here:
https://github.com/apache/lucene-solr/blob/c97f27b06c1d7c250e9596a9bc7bf5ca11ef6ad3/solr/core/src/java/org/apache/solr/util/SolrCLI.java#L1530-L1534

As we can see, it even allows the setting of maxShardsPerNode as a
parameter, but according to 7.4 documentation the default value would be 1
instead of -1 (see
https://lucene.apache.org/solr/guide/7_4/collections-api.html ). If I
create the collection directly via HTTP request

curl -X POST '
http://localhost:8983/solr/admin/collections?action=CREATE&name=test2&numShards=1&replicationFactor=1
'

It creates the collection with the default maxShardsPerNode of 1.

It seems that the fix is trivial (either code or docs), but I would like to
know if this is really a bug or not, that is, should I provide a fix or
leave it as-is?

PS: As a bit of context, I was bited by this when demo-ing Solr
backup/restore capabilities and it refused to recover a collection with
maxShardsPerNode == -1.

Best regards,
Edward

[jira] [Commented] (SOLR-12549) Settle a location for the log4j2.xml file

[Alexandre Rafalovitch (JIRA)]

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

Alexandre Rafalovitch commented on SOLR-12549:
--

7.5 Release notes still refer to the 12008, but now that it is deleted, nobody 
would be able to find further details on it. Not sure what the best way to fix 
it is. Maybe just relink it to this one?

> Settle a location for the log4j2.xml file
> -
>
> Key: SOLR-12549
> URL: https://issues.apache.org/jira/browse/SOLR-12549
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: logging
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Major
> Fix For: 7.5, master (8.0)
>
> Attachments: SOLR-12008-7x-test-fail-fix.patch, SOLR-12008.patch, 
> SOLR-12008.patch, SOLR-12008.patch, SOLR-12008.patch, SOLR-12008.patch
>
>
> CLONED from SOLR-12008 since 12008 couldn't be closed.
> As part of SOLR-11934 I started looking at log4j.properties files. Waaay back 
> in 2015, the %C in "/solr/server/resources/log4j.properties" was changed to 
> use %c, but the file in "solr/example/resources/log4j.properties" was not 
> changed. That got me to looking around and there are a bunch of 
> log4j.properties files:
> ./solr/core/src/test-files/log4j.properties
> ./solr/example/resources/log4j.properties
> ./solr/solrj/src/test-files/log4j.properties
> ./solr/server/resources/log4j.properties
> ./solr/server/scripts/cloud-scripts/log4j.properties
> ./solr/contrib/dataimporthandler/src/test-files/log4j.properties
> ./solr/contrib/clustering/src/test-files/log4j.properties
> ./solr/contrib/ltr/src/test-files/log4j.properties
> ./solr/test-framework/src/test-files/log4j.properties
> Why do we have so many? After the log4j2 ticket gets checked in (SOLR-7887) I 
> propose the logging configuration files get consolidated. The question is 
> "how far"? 
> I at least want to get rid of the one in solr/example, users should use the 
> one in server/resources. Having to maintain these two separately is asking 
> for trouble.
> [~markrmil...@gmail.com] Do you have any wisdom on the properties file in 
> server/scripts/cloud-scripts?
> Anyone else who has a clue about why the other properties files were created, 
> especially the ones in contrib?
> And what about all the ones in various test-files directories? People didn't 
> create them for no reason, and I don't want to rediscover that it's a real 
> pain to try to re-use the one in server/resources for instance.



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

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

Re: Lucene/Solr 7.5

[Alexandre Rafalovitch]

Just a note that SOLR-12395 (SignificantTermsQParserPlugin) probably
does not need to be mentioned in the Upgrade Notes section, as that
particular QParserPlugin is not actually documented or even supposed
to be end-user visible (it is backing the stream component). See
SOLR-12569 for the full discussion on it.

Regards,
   Alex.

On 17 September 2018 at 11:57, Adrien Grand  wrote:
> We don't enforce anything but out-of-order releases introduce blind spots
> for backward compatibility testing of the index format. For instance if we
> release 7.4.1 after 7.5.0, there is no test that checked whether 7.5.0 could
> read indices created with 7.4.1 since the release process only tested
> backward compatibility with versions that were already released at the time
> of the release of 7.5.0. This is also why we avoid running multiple votes at
> the same time since we can't easily verify that one release candidate can
> read indices created by the other release candidate. We could add more
> testing for these cases, but it's probably easier to avoid out-of-order
> releases and do the testing manually when we don't have the choice, such as
> fixing bad bugs in the previous major version (given that upgrading to a new
> major is often not an easy task).
>
> Le lun. 17 sept. 2018 à 16:47, Steve Rowe  a écrit :
>>
>> Hi Jim,
>>
>> > On Sep 17, 2018, at 10:07 AM, jim ferenczi 
>> > wrote:
>> >
>> > Unless we cancel 7.5 there is no need to backport to 7.4 since we cannot
>> > publish 7.4.1 after 7.5.0.
>>
>> I’m not sure what you mean?  Point releases can be published at any time.
>>
>> --
>> Steve
>> www.lucidworks.com
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>

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

[jira] [Resolved] (SOLR-12771) Improve Autoscaling Policy and Preferences documentation

[Steve Rowe (JIRA)]

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

Steve Rowe resolved SOLR-12771.
---
   Resolution: Fixed
Fix Version/s: master (8.0)
   7.6
   7.5

Thanks Hoss, committed, including to branch_7_5.

> Improve Autoscaling Policy and Preferences documentation
> 
>
> Key: SOLR-12771
> URL: https://issues.apache.org/jira/browse/SOLR-12771
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: AutoScaling, documentation
>Reporter: Steve Rowe
>Assignee: Steve Rowe
>Priority: Major
> Fix For: 7.5, 7.6, master (8.0)
>
> Attachments: SOLR-12771.patch, SOLR-12771.patch
>
>
> Tweaks to autoscaling overview and policy/preferences pages in the ref guide.



--
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-12771) Improve Autoscaling Policy and Preferences documentation

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-12771:


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

SOLR-12771: add CHANGES entry


> Improve Autoscaling Policy and Preferences documentation
> 
>
> Key: SOLR-12771
> URL: https://issues.apache.org/jira/browse/SOLR-12771
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: AutoScaling, documentation
>Reporter: Steve Rowe
>Assignee: Steve Rowe
>Priority: Major
> Attachments: SOLR-12771.patch, SOLR-12771.patch
>
>
> Tweaks to autoscaling overview and policy/preferences pages in the ref guide.



--
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-12771) Improve Autoscaling Policy and Preferences documentation

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-12771:


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

SOLR-12771: Improve Autoscaling Policy and Preferences documentation


> Improve Autoscaling Policy and Preferences documentation
> 
>
> Key: SOLR-12771
> URL: https://issues.apache.org/jira/browse/SOLR-12771
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: AutoScaling, documentation
>Reporter: Steve Rowe
>Assignee: Steve Rowe
>Priority: Major
> Attachments: SOLR-12771.patch, SOLR-12771.patch
>
>
> Tweaks to autoscaling overview and policy/preferences pages in the ref guide.



--
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-12771) Improve Autoscaling Policy and Preferences documentation

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-12771:


Commit b5bf70b7e32d7ddd9742cc821d471c5fabd4e3df in lucene-solr's branch 
refs/heads/branch_7_5 from [~steve_rowe]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=b5bf70b ]

SOLR-12771: add CHANGES entry


> Improve Autoscaling Policy and Preferences documentation
> 
>
> Key: SOLR-12771
> URL: https://issues.apache.org/jira/browse/SOLR-12771
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: AutoScaling, documentation
>Reporter: Steve Rowe
>Assignee: Steve Rowe
>Priority: Major
> Attachments: SOLR-12771.patch, SOLR-12771.patch
>
>
> Tweaks to autoscaling overview and policy/preferences pages in the ref guide.



--
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-12771) Improve Autoscaling Policy and Preferences documentation

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-12771:


Commit bc2297418d268c4e54452cabe344ad25d95d1cc5 in lucene-solr's branch 
refs/heads/branch_7_5 from [~steve_rowe]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=bc22974 ]

SOLR-12771: Improve Autoscaling Policy and Preferences documentation


> Improve Autoscaling Policy and Preferences documentation
> 
>
> Key: SOLR-12771
> URL: https://issues.apache.org/jira/browse/SOLR-12771
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: AutoScaling, documentation
>Reporter: Steve Rowe
>Assignee: Steve Rowe
>Priority: Major
> Attachments: SOLR-12771.patch, SOLR-12771.patch
>
>
> Tweaks to autoscaling overview and policy/preferences pages in the ref guide.



--
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-12771) Improve Autoscaling Policy and Preferences documentation

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-12771:


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

SOLR-12771: Improve Autoscaling Policy and Preferences documentation


> Improve Autoscaling Policy and Preferences documentation
> 
>
> Key: SOLR-12771
> URL: https://issues.apache.org/jira/browse/SOLR-12771
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: AutoScaling, documentation
>Reporter: Steve Rowe
>Assignee: Steve Rowe
>Priority: Major
> Attachments: SOLR-12771.patch, SOLR-12771.patch
>
>
> Tweaks to autoscaling overview and policy/preferences pages in the ref guide.



--
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-12771) Improve Autoscaling Policy and Preferences documentation

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-12771:


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

SOLR-12771: add CHANGES entry


> Improve Autoscaling Policy and Preferences documentation
> 
>
> Key: SOLR-12771
> URL: https://issues.apache.org/jira/browse/SOLR-12771
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: AutoScaling, documentation
>Reporter: Steve Rowe
>Assignee: Steve Rowe
>Priority: Major
> Attachments: SOLR-12771.patch, SOLR-12771.patch
>
>
> Tweaks to autoscaling overview and policy/preferences pages in the ref guide.



--
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-12771) Improve Autoscaling Policy and Preferences documentation

[Hoss Man (JIRA)]

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

Hoss Man commented on SOLR-12771:
-

+1

> Improve Autoscaling Policy and Preferences documentation
> 
>
> Key: SOLR-12771
> URL: https://issues.apache.org/jira/browse/SOLR-12771
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: AutoScaling, documentation
>Reporter: Steve Rowe
>Assignee: Steve Rowe
>Priority: Major
> Attachments: SOLR-12771.patch, SOLR-12771.patch
>
>
> Tweaks to autoscaling overview and policy/preferences pages in the ref guide.



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

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

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

[Apache Jenkins Server]

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

[...truncated 39 lines...]
[repro] Jenkins log URL: 
https://builds.apache.org/job/Lucene-Solr-Tests-master/2814/consoleText

[repro] Revision: b2b597b0383eec0b1bf4059922cf367fdee2be21

[repro] Repro line:  ant test  -Dtestcase=TestSimTriggerIntegration 
-Dtests.method=testEventQueue -Dtests.seed=E0D54D87EDEB4355 
-Dtests.multiplier=2 -Dtests.slow=true -Dtests.locale=es-US 
-Dtests.timezone=Pacific/Niue -Dtests.asserts=true 
-Dtests.file.encoding=US-ASCII

[repro] git rev-parse --abbrev-ref HEAD
[repro] git rev-parse HEAD
[repro] Initial local git branch/revision: 
895bff46b2c3d3d027e693e11a2feac9f518191d
[repro] git fetch
[repro] git checkout b2b597b0383eec0b1bf4059922cf367fdee2be21

[...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]   TestSimTriggerIntegration
[repro] ant compile-test

[...truncated 3423 lines...]
[repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=5 
-Dtests.class="*.TestSimTriggerIntegration" -Dtests.showOutput=onerror  
-Dtests.seed=E0D54D87EDEB4355 -Dtests.multiplier=2 -Dtests.slow=true 
-Dtests.locale=es-US -Dtests.timezone=Pacific/Niue -Dtests.asserts=true 
-Dtests.file.encoding=US-ASCII

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

[repro] Failures:
[repro]   2/5 failed: 
org.apache.solr.cloud.autoscaling.sim.TestSimTriggerIntegration
[repro] git checkout 895bff46b2c3d3d027e693e11a2feac9f518191d

[...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-NightlyTests-master - Build # 1645 - Unstable

[Apache Jenkins Server]

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

2 tests failed.
FAILED:  org.apache.lucene.store.TestByteBuffersDirectory.testSeekPastEOF 
{impl=byte array (heap)}

Error Message:
Unexpected exception type, expected EOFException but got 
java.lang.ArrayIndexOutOfBoundsException: 1881

Stack Trace:
junit.framework.AssertionFailedError: Unexpected exception type, expected 
EOFException but got java.lang.ArrayIndexOutOfBoundsException: 1881
at 
__randomizedtesting.SeedInfo.seed([90B07B6267E63464:70F6B09B67634AF5]:0)
at 
org.apache.lucene.util.LuceneTestCase.expectThrows(LuceneTestCase.java:2683)
at 
org.apache.lucene.util.LuceneTestCase.expectThrows(LuceneTestCase.java:2672)
at 
org.apache.lucene.store.BaseDirectoryTestCase.testSeekPastEOF(BaseDirectoryTestCase.java:516)
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:1742)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:935)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:971)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:985)
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:944)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:830)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:891)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:748)
Caused by: java.lang.ArrayIndexOutOfBoundsException: 1881
at 
org.apache.lucene.store.ByteArrayIndexInput.readByte(ByteArrayIndexInput.java:145)
at 
org.apache.lucene.store.BaseDirectoryTestCase.lambda$testSeekPastEOF$12(BaseDirectoryTestCase.java:518)
at 
org.apache.lucene.util.LuceneTestCase.expectThrows(LuceneTestCase.java:2678)
... 38 more


FAILED:  
org.apache.solr.handler.component.TestDistributedStatsComp

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

[Apache Jenkins Server]

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

All tests passed

Build Log:
[...truncated 16144 lines...]
   [junit4] JVM J0: stdout was not empty, see: 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.x/checkout/solr/build/solr-core/test/temp/junit4-J0-20180917_151830_3657738156242610548478.sysout
   [junit4] >>> JVM J0 emitted unexpected output (verbatim) 
   [junit4] java.lang.OutOfMemoryError: Java heap space
   [junit4] Dumping heap to 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.x/checkout/heapdumps/java_pid3815.hprof
 ...
   [junit4] Heap dump file created [658406233 bytes in 45.618 secs]
   [junit4] <<< JVM J0: EOF 

[...truncated 8869 lines...]
BUILD FAILED
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.x/checkout/build.xml:651:
 The following error occurred while executing this line:
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.x/checkout/build.xml:585:
 Some of the tests produced a heap dump, but did not fail. Maybe a suppressed 
OutOfMemoryError? Dumps created:
* java_pid3815.hprof

Total time: 492 minutes 5 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

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

[Policeman Jenkins Server]

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

1 tests failed.
FAILED:  org.apache.solr.cloud.autoscaling.ScheduledTriggerTest.testTrigger

Error Message:
expected:<3> but was:<2>

Stack Trace:
java.lang.AssertionError: expected:<3> but was:<2>
at 
__randomizedtesting.SeedInfo.seed([4C2CF97D84714382:2FE7CFFF1DBE30AF]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.failNotEquals(Assert.java:647)
at org.junit.Assert.assertEquals(Assert.java:128)
at org.junit.Assert.assertEquals(Assert.java:472)
at org.junit.Assert.assertEquals(Assert.java:456)
at 
org.apache.solr.cloud.autoscaling.ScheduledTriggerTest.scheduledTriggerTest(ScheduledTriggerTest.java:113)
at 
org.apache.solr.cloud.autoscaling.ScheduledTriggerTest.testTrigger(ScheduledTriggerTest.java:66)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1742)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:935)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:971)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:985)
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:944)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:830)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:891)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.base/java.lang.Thread.run(Thread.java:844)




Build Log:
[...truncated

[jira] [Commented] (SOLR-12771) Improve Autoscaling Policy and Preferences documentation

[Hoss Man (JIRA)]

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

Hoss Man commented on SOLR-12771:
-

This reads much smoother to me.


 A few nit pick suggestions...
 * I would move the "Using an exact integer value for count constraints is of 
limited utility..." info box until the end of the bulleted list, and add a 
sentence to it giving an equivilent example of a better alternative using 
percentages. ie: give people the full (uninterupted) list of legal expressions, 
including both integer constants and percentages, then explain why % is better 
then absolute.
 * the idea of "minimizing violations" is already mentioned elsewhere, but I 
would add a sentence to the section on {{strict}} mentioning it again since 
that's where it's particularly pertinent. End with something like...
{quote}If multiple rules declared to be `strict:false` can not be satisfied by 
some nodes, then a node will be chosen such that the number of such violations 
are minimized.
{quote}
 * The section "Manual Collection Creation with a Policy" is really just a 
large iterative example – not "instructional reference" content like other 
sections w/equivalent header levels ... perhaps rename "Example: Manual 
Collection Creation using Policies" ?

> Improve Autoscaling Policy and Preferences documentation
> 
>
> Key: SOLR-12771
> URL: https://issues.apache.org/jira/browse/SOLR-12771
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: AutoScaling, documentation
>Reporter: Steve Rowe
>Assignee: Steve Rowe
>Priority: Major
> Attachments: SOLR-12771.patch
>
>
> Tweaks to autoscaling overview and policy/preferences pages in the ref guide.



--
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-5163) edismax should throw exception when qf refers to nonexistent field

[Charles Sanders (JIRA)]

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

Charles Sanders commented on SOLR-5163:
---

[~eribeiro] Yes I am planning to get back to this.  Been busy and on vacation.  
I hope to get back to this within the next couple of weeks.  Thanks.

> edismax should throw exception when qf refers to nonexistent field
> --
>
> Key: SOLR-5163
> URL: https://issues.apache.org/jira/browse/SOLR-5163
> Project: Solr
>  Issue Type: Bug
>  Components: query parsers, search
>Affects Versions: 4.10.4
>Reporter: Steven Bower
>Assignee: David Smiley
>Priority: Major
>  Labels: newdev
> Attachments: SOLR-5163.patch
>
>
> query:
> q=foo AND bar
> qf=field1
> qf=field2
> defType=edismax
> Where field1 exists and field2 doesn't..
> will treat the AND as a term vs and operator



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

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

[jira] [Updated] (LUCENE-8506) TestAddIndexes.testAddIndicesWithSoftDeletes() failures

[Steve Rowe (JIRA)]

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

Steve Rowe updated LUCENE-8506:
---
Component/s: general/test
 core/index

> TestAddIndexes.testAddIndicesWithSoftDeletes() failures
> ---
>
> Key: LUCENE-8506
> URL: https://issues.apache.org/jira/browse/LUCENE-8506
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/index, general/test
>Reporter: Steve Rowe
>Priority: Major
>
> {{TestAddIndexes.testAddIndicesWithSoftDeletes()}} has failed a few times on 
> Jenkins (see below), but the seeds don't reproduce 100%: of the two I tested, 
> one didn't reproduce at all in 5 iterations, and the other reproduced 1/5 
> iterations.
> I beasted the suite on master 50 times using Miller's beasting script and it 
> failed just once:
> {noformat}
> ({{git show}} reports: {{commit 895bff46b2c3d3d027e693e11a2feac9f518191d}})
>[junit4]   2> NOTE: reproduce with: ant test  -Dtestcase=TestAddIndexes 
> -Dtests.method=testAddIndicesWithSoftDeletes -Dtests.seed=70F06A77576A75 
> -Dtests.slow=true -Dtests.badapples=true -Dtests.locale=ar-YE 
> -Dtests.timezone=Iceland -Dtests.asserts=true -Dtests.file.encoding=UTF-8
>[junit4] ERROR   0.40s | TestAddIndexes.testAddIndicesWithSoftDeletes <<<
>[junit4]> Throwable #1: java.lang.IndexOutOfBoundsException: Index: 1, 
> Size: 1
>[junit4]>at 
> __randomizedtesting.SeedInfo.seed([70F06A77576A75:2C240F2EC2524E6D]:0)
>[junit4]>at java.util.ArrayList.rangeCheck(ArrayList.java:657)
>[junit4]>at java.util.ArrayList.get(ArrayList.java:433)
>[junit4]>at 
> java.util.Collections$UnmodifiableList.get(Collections.java:1309)
>[junit4]>at 
> org.apache.lucene.index.TestAddIndexes.testAddIndicesWithSoftDeletes(TestAddIndexes.java:1452)
>[junit4]>at java.lang.Thread.run(Thread.java:748)
> [...]
>[junit4]   2> NOTE: test params are: codec=Asserting(Lucene80): 
> {c=BlockTreeOrds(blocksize=128), id=BlockTreeOrds(blocksize=128), 
> f1=BlockTreeOrds(blocksize=128), f2=Lucene50(blocksize=128), 
> version=Lucene50(blocksize=128), content=FSTOrd50}, 
> docValues:{dv=DocValuesFormat(name=Asserting), 
> soft_delete=DocValuesFormat(name=Lucene70), 
> doc=DocValuesFormat(name=Lucene70), id=DocValuesFormat(name=Direct), 
> content=DocValuesFormat(name=Lucene70), 
> doc2d=DocValuesFormat(name=Asserting)}, maxPointsInLeafNode=69, 
> maxMBSortInHeap=5.930450658985216, 
> sim=Asserting(org.apache.lucene.search.similarities.AssertingSimilarity@35111f6),
>  locale=ar-YE, timezone=Iceland
>[junit4]   2> NOTE: Linux 4.1.0-custom2-amd64 amd64/Oracle Corporation 
> 1.8.0_171 (64-bit)/cpus=16,threads=1,free=490798376,total=511180800
> {noformat}
> Jenkins failures (all on branch_7x):
> From [https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Solaris/814/]:
> {noformat}
> Checking out Revision 0789a77c2590f716fc3cedb247309068c3fc5d85 
> (refs/remotes/origin/branch_7x)
> [...]
>   [junit4]   2> NOTE: reproduce with: ant test  -Dtestcase=TestAddIndexes 
> -Dtests.method=testAddIndicesWithSoftDeletes -Dtests.seed=B80C15673B91141 
> -Dtests.slow=true -Dtests.locale=es-SV -Dtests.timezone=Asia/Jakarta 
> -Dtests.asserts=true -Dtests.file.encoding=UTF-8
>   [junit4] ERROR   0.02s J0 | TestAddIndexes.testAddIndicesWithSoftDeletes <<<
>   [junit4]> Throwable #1: java.lang.IndexOutOfBoundsException: Index: 2, 
> Size: 2
>   [junit4]>   at 
> __randomizedtesting.SeedInfo.seed([B80C15673B91141:27D43E12C6BC3559]:0)
>   [junit4]>   at java.util.ArrayList.rangeCheck(ArrayList.java:657)
>   [junit4]>   at java.util.ArrayList.get(ArrayList.java:433)
>   [junit4]>   at 
> java.util.Collections$UnmodifiableList.get(Collections.java:1309)
>   [junit4]>   at 
> org.apache.lucene.index.TestAddIndexes.testAddIndicesWithSoftDeletes(TestAddIndexes.java:1455)
>   [junit4]>   at java.lang.Thread.run(Thread.java:748)
> [...]
>   [junit4]   2> NOTE: test params are: codec=Asserting(Lucene70): 
> {c=PostingsFormat(name=LuceneVarGapDocFreqInterval), 
> id=PostingsFormat(name=LuceneVarGapDocFreqInterval), 
> f1=PostingsFormat(name=LuceneVarGapDocFreqInterval), f2=FSTOrd50, 
> version=FSTOrd50, content=BlockTreeOrds(blocksize=128)}, 
> docValues:{dv=DocValuesFormat(name=Direct), 
> soft_delete=DocValuesFormat(name=Asserting), 
> doc=DocValuesFormat(name=Asserting), id=DocValuesFormat(name=Lucene70), 
> content=DocValuesFormat(name=Memory), doc2d=DocValuesFormat(name=Direct)}, 
> maxPointsInLeafNode=584, maxMBSortInHeap=7.761726159162388, 
> sim=RandomSimilarity(queryNorm=true): {foo=DFR I(ne)BZ(0.3), id=DFR GL2, 
> content=IB SPL-L1}, locale=es-SV, timezone=Asia/Jakarta
>   [junit4]   2> NOTE: SunOS 5.11 amd64/Oracle

[jira] [Updated] (LUCENE-8506) TestAddIndexes.testAddIndicesWithSoftDeletes() failures

[Steve Rowe (JIRA)]

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

Steve Rowe updated LUCENE-8506:
---
Issue Type: Bug  (was: Improvement)

> TestAddIndexes.testAddIndicesWithSoftDeletes() failures
> ---
>
> Key: LUCENE-8506
> URL: https://issues.apache.org/jira/browse/LUCENE-8506
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Steve Rowe
>Priority: Major
>
> {{TestAddIndexes.testAddIndicesWithSoftDeletes()}} has failed a few times on 
> Jenkins (see below), but the seeds don't reproduce 100%: of the two I tested, 
> one didn't reproduce at all in 5 iterations, and the other reproduced 1/5 
> iterations.
> I beasted the suite on master 50 times using Miller's beasting script and it 
> failed just once:
> {noformat}
> ({{git show}} reports: {{commit 895bff46b2c3d3d027e693e11a2feac9f518191d}})
>[junit4]   2> NOTE: reproduce with: ant test  -Dtestcase=TestAddIndexes 
> -Dtests.method=testAddIndicesWithSoftDeletes -Dtests.seed=70F06A77576A75 
> -Dtests.slow=true -Dtests.badapples=true -Dtests.locale=ar-YE 
> -Dtests.timezone=Iceland -Dtests.asserts=true -Dtests.file.encoding=UTF-8
>[junit4] ERROR   0.40s | TestAddIndexes.testAddIndicesWithSoftDeletes <<<
>[junit4]> Throwable #1: java.lang.IndexOutOfBoundsException: Index: 1, 
> Size: 1
>[junit4]>at 
> __randomizedtesting.SeedInfo.seed([70F06A77576A75:2C240F2EC2524E6D]:0)
>[junit4]>at java.util.ArrayList.rangeCheck(ArrayList.java:657)
>[junit4]>at java.util.ArrayList.get(ArrayList.java:433)
>[junit4]>at 
> java.util.Collections$UnmodifiableList.get(Collections.java:1309)
>[junit4]>at 
> org.apache.lucene.index.TestAddIndexes.testAddIndicesWithSoftDeletes(TestAddIndexes.java:1452)
>[junit4]>at java.lang.Thread.run(Thread.java:748)
> [...]
>[junit4]   2> NOTE: test params are: codec=Asserting(Lucene80): 
> {c=BlockTreeOrds(blocksize=128), id=BlockTreeOrds(blocksize=128), 
> f1=BlockTreeOrds(blocksize=128), f2=Lucene50(blocksize=128), 
> version=Lucene50(blocksize=128), content=FSTOrd50}, 
> docValues:{dv=DocValuesFormat(name=Asserting), 
> soft_delete=DocValuesFormat(name=Lucene70), 
> doc=DocValuesFormat(name=Lucene70), id=DocValuesFormat(name=Direct), 
> content=DocValuesFormat(name=Lucene70), 
> doc2d=DocValuesFormat(name=Asserting)}, maxPointsInLeafNode=69, 
> maxMBSortInHeap=5.930450658985216, 
> sim=Asserting(org.apache.lucene.search.similarities.AssertingSimilarity@35111f6),
>  locale=ar-YE, timezone=Iceland
>[junit4]   2> NOTE: Linux 4.1.0-custom2-amd64 amd64/Oracle Corporation 
> 1.8.0_171 (64-bit)/cpus=16,threads=1,free=490798376,total=511180800
> {noformat}
> Jenkins failures (all on branch_7x):
> From [https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Solaris/814/]:
> {noformat}
> Checking out Revision 0789a77c2590f716fc3cedb247309068c3fc5d85 
> (refs/remotes/origin/branch_7x)
> [...]
>   [junit4]   2> NOTE: reproduce with: ant test  -Dtestcase=TestAddIndexes 
> -Dtests.method=testAddIndicesWithSoftDeletes -Dtests.seed=B80C15673B91141 
> -Dtests.slow=true -Dtests.locale=es-SV -Dtests.timezone=Asia/Jakarta 
> -Dtests.asserts=true -Dtests.file.encoding=UTF-8
>   [junit4] ERROR   0.02s J0 | TestAddIndexes.testAddIndicesWithSoftDeletes <<<
>   [junit4]> Throwable #1: java.lang.IndexOutOfBoundsException: Index: 2, 
> Size: 2
>   [junit4]>   at 
> __randomizedtesting.SeedInfo.seed([B80C15673B91141:27D43E12C6BC3559]:0)
>   [junit4]>   at java.util.ArrayList.rangeCheck(ArrayList.java:657)
>   [junit4]>   at java.util.ArrayList.get(ArrayList.java:433)
>   [junit4]>   at 
> java.util.Collections$UnmodifiableList.get(Collections.java:1309)
>   [junit4]>   at 
> org.apache.lucene.index.TestAddIndexes.testAddIndicesWithSoftDeletes(TestAddIndexes.java:1455)
>   [junit4]>   at java.lang.Thread.run(Thread.java:748)
> [...]
>   [junit4]   2> NOTE: test params are: codec=Asserting(Lucene70): 
> {c=PostingsFormat(name=LuceneVarGapDocFreqInterval), 
> id=PostingsFormat(name=LuceneVarGapDocFreqInterval), 
> f1=PostingsFormat(name=LuceneVarGapDocFreqInterval), f2=FSTOrd50, 
> version=FSTOrd50, content=BlockTreeOrds(blocksize=128)}, 
> docValues:{dv=DocValuesFormat(name=Direct), 
> soft_delete=DocValuesFormat(name=Asserting), 
> doc=DocValuesFormat(name=Asserting), id=DocValuesFormat(name=Lucene70), 
> content=DocValuesFormat(name=Memory), doc2d=DocValuesFormat(name=Direct)}, 
> maxPointsInLeafNode=584, maxMBSortInHeap=7.761726159162388, 
> sim=RandomSimilarity(queryNorm=true): {foo=DFR I(ne)BZ(0.3), id=DFR GL2, 
> content=IB SPL-L1}, locale=es-SV, timezone=Asia/Jakarta
>   [junit4]   2> NOTE: SunOS 5.11 amd64/Oracle Corporation 1.8.0_172 
> (64-bit)/cpus=3,threads=1,free=350279888

[jira] [Created] (LUCENE-8506) TestAddIndexes.testAddIndicesWithSoftDeletes() failures

[Steve Rowe (JIRA)]

Steve Rowe created LUCENE-8506:
--

 Summary: TestAddIndexes.testAddIndicesWithSoftDeletes() failures
 Key: LUCENE-8506
 URL: https://issues.apache.org/jira/browse/LUCENE-8506
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Steve Rowe


{{TestAddIndexes.testAddIndicesWithSoftDeletes()}} has failed a few times on 
Jenkins (see below), but the seeds don't reproduce 100%: of the two I tested, 
one didn't reproduce at all in 5 iterations, and the other reproduced 1/5 
iterations.

I beasted the suite on master 50 times using Miller's beasting script and it 
failed just once:

{noformat}
({{git show}} reports: {{commit 895bff46b2c3d3d027e693e11a2feac9f518191d}})
   [junit4]   2> NOTE: reproduce with: ant test  -Dtestcase=TestAddIndexes 
-Dtests.method=testAddIndicesWithSoftDeletes -Dtests.seed=70F06A77576A75 
-Dtests.slow=true -Dtests.badapples=true -Dtests.locale=ar-YE 
-Dtests.timezone=Iceland -Dtests.asserts=true -Dtests.file.encoding=UTF-8
   [junit4] ERROR   0.40s | TestAddIndexes.testAddIndicesWithSoftDeletes <<<
   [junit4]> Throwable #1: java.lang.IndexOutOfBoundsException: Index: 1, 
Size: 1
   [junit4]>at 
__randomizedtesting.SeedInfo.seed([70F06A77576A75:2C240F2EC2524E6D]:0)
   [junit4]>at java.util.ArrayList.rangeCheck(ArrayList.java:657)
   [junit4]>at java.util.ArrayList.get(ArrayList.java:433)
   [junit4]>at 
java.util.Collections$UnmodifiableList.get(Collections.java:1309)
   [junit4]>at 
org.apache.lucene.index.TestAddIndexes.testAddIndicesWithSoftDeletes(TestAddIndexes.java:1452)
   [junit4]>at java.lang.Thread.run(Thread.java:748)
[...]
   [junit4]   2> NOTE: test params are: codec=Asserting(Lucene80): 
{c=BlockTreeOrds(blocksize=128), id=BlockTreeOrds(blocksize=128), 
f1=BlockTreeOrds(blocksize=128), f2=Lucene50(blocksize=128), 
version=Lucene50(blocksize=128), content=FSTOrd50}, 
docValues:{dv=DocValuesFormat(name=Asserting), 
soft_delete=DocValuesFormat(name=Lucene70), doc=DocValuesFormat(name=Lucene70), 
id=DocValuesFormat(name=Direct), content=DocValuesFormat(name=Lucene70), 
doc2d=DocValuesFormat(name=Asserting)}, maxPointsInLeafNode=69, 
maxMBSortInHeap=5.930450658985216, 
sim=Asserting(org.apache.lucene.search.similarities.AssertingSimilarity@35111f6),
 locale=ar-YE, timezone=Iceland
   [junit4]   2> NOTE: Linux 4.1.0-custom2-amd64 amd64/Oracle Corporation 
1.8.0_171 (64-bit)/cpus=16,threads=1,free=490798376,total=511180800
{noformat}

Jenkins failures (all on branch_7x):

>From [https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Solaris/814/]:

{noformat}
Checking out Revision 0789a77c2590f716fc3cedb247309068c3fc5d85 
(refs/remotes/origin/branch_7x)
[...]
  [junit4]   2> NOTE: reproduce with: ant test  -Dtestcase=TestAddIndexes 
-Dtests.method=testAddIndicesWithSoftDeletes -Dtests.seed=B80C15673B91141 
-Dtests.slow=true -Dtests.locale=es-SV -Dtests.timezone=Asia/Jakarta 
-Dtests.asserts=true -Dtests.file.encoding=UTF-8
  [junit4] ERROR   0.02s J0 | TestAddIndexes.testAddIndicesWithSoftDeletes <<<
  [junit4]> Throwable #1: java.lang.IndexOutOfBoundsException: Index: 2, 
Size: 2
  [junit4]> at 
__randomizedtesting.SeedInfo.seed([B80C15673B91141:27D43E12C6BC3559]:0)
  [junit4]> at java.util.ArrayList.rangeCheck(ArrayList.java:657)
  [junit4]> at java.util.ArrayList.get(ArrayList.java:433)
  [junit4]> at 
java.util.Collections$UnmodifiableList.get(Collections.java:1309)
  [junit4]> at 
org.apache.lucene.index.TestAddIndexes.testAddIndicesWithSoftDeletes(TestAddIndexes.java:1455)
  [junit4]> at java.lang.Thread.run(Thread.java:748)
[...]
  [junit4]   2> NOTE: test params are: codec=Asserting(Lucene70): 
{c=PostingsFormat(name=LuceneVarGapDocFreqInterval), 
id=PostingsFormat(name=LuceneVarGapDocFreqInterval), 
f1=PostingsFormat(name=LuceneVarGapDocFreqInterval), f2=FSTOrd50, 
version=FSTOrd50, content=BlockTreeOrds(blocksize=128)}, 
docValues:{dv=DocValuesFormat(name=Direct), 
soft_delete=DocValuesFormat(name=Asserting), 
doc=DocValuesFormat(name=Asserting), id=DocValuesFormat(name=Lucene70), 
content=DocValuesFormat(name=Memory), doc2d=DocValuesFormat(name=Direct)}, 
maxPointsInLeafNode=584, maxMBSortInHeap=7.761726159162388, 
sim=RandomSimilarity(queryNorm=true): {foo=DFR I(ne)BZ(0.3), id=DFR GL2, 
content=IB SPL-L1}, locale=es-SV, timezone=Asia/Jakarta
  [junit4]   2> NOTE: SunOS 5.11 amd64/Oracle Corporation 1.8.0_172 
(64-bit)/cpus=3,threads=1,free=350279888,total=518979584
{noformat}

>From [https://builds.apache.org/job/Lucene-Solr-SmokeRelease-7.x/317/]:

{noformat}
Checking out Revision ae6ceb5cb302b6db17637b5097f5f07740287fb3 
(refs/remotes/origin/branch_7x)
[...]
   [smoker][junit4]   2> NOTE: reproduce with: ant test  
-Dtestcase=TestAddIndexes -Dtests.method=testAddIndicesWithSoftDeletes 
-Dtests.seed=4B54629

[jira] [Commented] (LUCENE-8505) IndexWriter#addIndices should not sort indices if they are not already sorted

[Jim Ferenczi (JIRA)]

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

Jim Ferenczi commented on LUCENE-8505:
--

yes only master

> IndexWriter#addIndices should not sort indices if they are not already sorted
> -
>
> Key: LUCENE-8505
> URL: https://issues.apache.org/jira/browse/LUCENE-8505
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Jim Ferenczi
>Priority: Minor
> Attachments: LUCENE-8505.patch
>
>
> Today IndexWriter#addIndices silently re-sort non-sorted indices when they 
> are added in a sorted index. This is not safe because the sort is done 
> entirely in memory and cannot handle big segments efficiently. This leniency 
> was added because prior to 6.5, segments produced by flushes were not sorted, 
> they had to wait for a merge to apply the index sorting. Now that segments 
> are always sorted (LUCENE-7579) we should remove this ability and throw an 
> error if the sort of the current index does not match with the candidate.



--
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-8505) IndexWriter#addIndices should not sort indices if they are not already sorted

[Adrien Grand (JIRA)]

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

Adrien Grand commented on LUCENE-8505:
--

+1 You only plan to merge this to master, right? We still need the ability to 
re-sort segments for backward-compatibility with early 6.x indices?

> IndexWriter#addIndices should not sort indices if they are not already sorted
> -
>
> Key: LUCENE-8505
> URL: https://issues.apache.org/jira/browse/LUCENE-8505
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Jim Ferenczi
>Priority: Minor
> Attachments: LUCENE-8505.patch
>
>
> Today IndexWriter#addIndices silently re-sort non-sorted indices when they 
> are added in a sorted index. This is not safe because the sort is done 
> entirely in memory and cannot handle big segments efficiently. This leniency 
> was added because prior to 6.5, segments produced by flushes were not sorted, 
> they had to wait for a merge to apply the index sorting. Now that segments 
> are always sorted (LUCENE-7579) we should remove this ability and throw an 
> error if the sort of the current index does not match with the candidate.



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

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

Re: Lucene/Solr 7.5

[Adrien Grand]

We don't enforce anything but out-of-order releases introduce blind spots
for backward compatibility testing of the index format. For instance if we
release 7.4.1 after 7.5.0, there is no test that checked whether 7.5.0
could read indices created with 7.4.1 since the release process only tested
backward compatibility with versions that were already released at the time
of the release of 7.5.0. This is also why we avoid running multiple votes
at the same time since we can't easily verify that one release candidate
can read indices created by the other release candidate. We could add more
testing for these cases, but it's probably easier to avoid out-of-order
releases and do the testing manually when we don't have the choice, such as
fixing bad bugs in the previous major version (given that upgrading to a
new major is often not an easy task).

Le lun. 17 sept. 2018 à 16:47, Steve Rowe  a écrit :

> Hi Jim,
>
> > On Sep 17, 2018, at 10:07 AM, jim ferenczi 
> wrote:
> >
> > Unless we cancel 7.5 there is no need to backport to 7.4 since we cannot
> publish 7.4.1 after 7.5.0.
>
> I’m not sure what you mean?  Point releases can be published at any time.
>
> --
> Steve
> www.lucidworks.com
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

[JENKINS-EA] Lucene-Solr-7.x-Linux (64bit/jdk-11-ea+28) - Build # 2759 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/2759/
Java: 64bit/jdk-11-ea+28 -XX:-UseCompressedOops -XX:+UseParallelGC

1 tests failed.
FAILED:  org.apache.solr.TestDistributedGrouping.test

Error Message:
Error from server at https://127.0.0.1:44101/i_/i/collection1: ERROR: [doc=1] 
unknown field 'a_idv'

Stack Trace:
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at https://127.0.0.1:44101/i_/i/collection1: ERROR: [doc=1] unknown 
field 'a_idv'
at 
__randomizedtesting.SeedInfo.seed([9A800F53024D591C:12D43089ACB134E4]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:643)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:255)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:244)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:194)
at org.apache.solr.client.solrj.SolrClient.add(SolrClient.java:173)
at org.apache.solr.client.solrj.SolrClient.add(SolrClient.java:138)
at org.apache.solr.client.solrj.SolrClient.add(SolrClient.java:152)
at 
org.apache.solr.BaseDistributedSearchTestCase.indexDoc(BaseDistributedSearchTestCase.java:483)
at 
org.apache.solr.BaseDistributedSearchTestCase.indexr(BaseDistributedSearchTestCase.java:465)
at 
org.apache.solr.TestDistributedGrouping.test(TestDistributedGrouping.java:75)
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:1742)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:935)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:971)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:985)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsRepeatStatement.callStatement(BaseDistributedSearchTestCase.java:1034)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:983)
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:944)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:830)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:891)
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

[GitHub] lucene-solr pull request #451: LUCENE-8496: Add selective indexing to BKD/PO...

[iverase]

Github user iverase commented on a diff in the pull request:

https://github.com/apache/lucene-solr/pull/451#discussion_r218112746
  
--- Diff: lucene/core/src/test/org/apache/lucene/util/bkd/TestBKD.java ---
@@ -1063,7 +1064,7 @@ public void testWastedLeadingBytes() throws Exception 
{
 
 Directory dir = newFSDirectory(createTempDir());
 int numDocs = 10;
-BKDWriter w = new BKDWriter(numDocs+1, dir, "tmp", numDims, 
bytesPerDim, 32, 1f, numDocs, true);
+BKDWriter w = new BKDWriter(numDocs+1, dir, "tmp", numDims, numDims, 
bytesPerDim, 32, 1f, numDocs, true);
--- End diff --

I have just seen there is already a test using different index and data 
dimensions, still it would be worthy to check if possible that data dimensions 
are properly propagated.


---

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

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

[Policeman Jenkins Server]

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

1 tests failed.
FAILED:  
org.apache.solr.cloud.autoscaling.sim.TestSimPolicyCloud.testCreateCollectionAddReplica

Error Message:
Timeout waiting for collection to become active Live Nodes: 
[127.0.0.1:10001_solr, 127.0.0.1:10004_solr, 127.0.0.1:1_solr, 
127.0.0.1:10002_solr, 127.0.0.1:10003_solr] Last available state: 
DocCollection(testCreateCollectionAddReplica//clusterstate.json/23)={   
"replicationFactor":"1",   "pullReplicas":"0",   
"router":{"name":"compositeId"},   "maxShardsPerNode":"1",   
"autoAddReplicas":"false",   "nrtReplicas":"1",   "tlogReplicas":"0",   
"autoCreated":"true",   "policy":"c1",   "shards":{"shard1":{   
"replicas":{"core_node1":{   
"core":"testCreateCollectionAddReplica_shard1_replica_n1",   
"SEARCHER.searcher.maxDoc":0,   "SEARCHER.searcher.deletedDocs":0,  
 "INDEX.sizeInBytes":10240,   "node_name":"127.0.0.1:10001_solr",   
"state":"active",   "type":"NRT",   
"INDEX.sizeInGB":9.5367431640625E-6,   "SEARCHER.searcher.numDocs":0}}, 
  "range":"8000-7fff",   "state":"active"}}}

Stack Trace:
java.lang.AssertionError: Timeout waiting for collection to become active
Live Nodes: [127.0.0.1:10001_solr, 127.0.0.1:10004_solr, 127.0.0.1:1_solr, 
127.0.0.1:10002_solr, 127.0.0.1:10003_solr]
Last available state: 
DocCollection(testCreateCollectionAddReplica//clusterstate.json/23)={
  "replicationFactor":"1",
  "pullReplicas":"0",
  "router":{"name":"compositeId"},
  "maxShardsPerNode":"1",
  "autoAddReplicas":"false",
  "nrtReplicas":"1",
  "tlogReplicas":"0",
  "autoCreated":"true",
  "policy":"c1",
  "shards":{"shard1":{
  "replicas":{"core_node1":{
  "core":"testCreateCollectionAddReplica_shard1_replica_n1",
  "SEARCHER.searcher.maxDoc":0,
  "SEARCHER.searcher.deletedDocs":0,
  "INDEX.sizeInBytes":10240,
  "node_name":"127.0.0.1:10001_solr",
  "state":"active",
  "type":"NRT",
  "INDEX.sizeInGB":9.5367431640625E-6,
  "SEARCHER.searcher.numDocs":0}},
  "range":"8000-7fff",
  "state":"active"}}}
at 
__randomizedtesting.SeedInfo.seed([7C056A298B5F7FEC:FC250F079A1C974A]:0)
at 
org.apache.solr.cloud.CloudTestUtils.waitForState(CloudTestUtils.java:70)
at 
org.apache.solr.cloud.autoscaling.sim.TestSimPolicyCloud.testCreateCollectionAddReplica(TestSimPolicyCloud.java:123)
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:1742)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:935)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:971)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:985)
at 
org.junit.rules.ExpectedException$ExpectedExceptionStatement.evaluate(ExpectedException.java:110)
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:944)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:830)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:891)
at 
com.carrotsearch.randomizedtesting.rules.StatementAda

Re: Lucene/Solr 7.5

[Steve Rowe]

Hi Jim,

> On Sep 17, 2018, at 10:07 AM, jim ferenczi  wrote:
> 
> Unless we cancel 7.5 there is no need to backport to 7.4 since we cannot 
> publish 7.4.1 after 7.5.0.

I’m not sure what you mean?  Point releases can be published at any time.

--
Steve
www.lucidworks.com


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

[GitHub] lucene-solr pull request #456: Corrected equals method of QueryValueSource

[rozuur]

GitHub user rozuur opened a pull request:

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

Corrected equals method of QueryValueSource

Fixes the comparison of an extended class of QueryValueSource

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

$ git pull https://github.com/rozuur/lucene-solr patch-1

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

https://github.com/apache/lucene-solr/pull/456.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #456


commit 452f7537258a74225525bcd99b1bae7d7e0cb4de
Author: Naveen Vardhi 
Date:   2018-09-17T14:41:59Z

Corrected equals method

Fixes the comparison of an extended class of QueryValueSource




---

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

[jira] [Closed] (SOLR-12284) WordBreakSolrSpellChecker incorrectly adds parenthesis when breaking words

[James Dyer (JIRA)]

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

James Dyer closed SOLR-12284.
-

> WordBreakSolrSpellChecker incorrectly adds parenthesis when breaking words
> --
>
> Key: SOLR-12284
> URL: https://issues.apache.org/jira/browse/SOLR-12284
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: spellchecker
>Affects Versions: 7.3
>Reporter: James Dyer
>Assignee: James Dyer
>Priority: Minor
> Fix For: 7.4
>
> Attachments: SOLR-12284.patch
>
>
> When using WordBreakSolrSpellChecker to break single words into multiple, the 
> collation queries include parenthesis around the original term.  In some 
> cases, this causes required terms to become optional and users get spurious 
> nonsensical collation results.
> For instance, if I search: +eward +smith 
> ...If +ward +smith is a match, it might give a collation like: (+e +ward) 
> +smith
> ...This requires either the "e" or the "ward" to exist, but not both.  But 
> users are more likely to want both terms to be required, so it would be 
> better if it was not adding parenthesis.
> This might be the cause of SOLR-5995 and [this SO 
> issue|https://stackoverflow.com/questions/23849747/solr-wordbreak-spellchecker-breaking-words-into-letters-excessive-breaking]



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

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

[jira] [Resolved] (SOLR-12284) WordBreakSolrSpellChecker incorrectly adds parenthesis when breaking words

[James Dyer (JIRA)]

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

James Dyer resolved SOLR-12284.
---
   Resolution: Fixed
Fix Version/s: 7.4

resolving, forgot to resolve when issue was committed.

> WordBreakSolrSpellChecker incorrectly adds parenthesis when breaking words
> --
>
> Key: SOLR-12284
> URL: https://issues.apache.org/jira/browse/SOLR-12284
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: spellchecker
>Affects Versions: 7.3
>Reporter: James Dyer
>Assignee: James Dyer
>Priority: Minor
> Fix For: 7.4
>
> Attachments: SOLR-12284.patch
>
>
> When using WordBreakSolrSpellChecker to break single words into multiple, the 
> collation queries include parenthesis around the original term.  In some 
> cases, this causes required terms to become optional and users get spurious 
> nonsensical collation results.
> For instance, if I search: +eward +smith 
> ...If +ward +smith is a match, it might give a collation like: (+e +ward) 
> +smith
> ...This requires either the "e" or the "ward" to exist, but not both.  But 
> users are more likely to want both terms to be required, so it would be 
> better if it was not adding parenthesis.
> This might be the cause of SOLR-5995 and [this SO 
> issue|https://stackoverflow.com/questions/23849747/solr-wordbreak-spellchecker-breaking-words-into-letters-excessive-breaking]



--
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-8503) Simplify unwrapping Filter*Reader

[ASF subversion and git services (JIRA)]

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

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

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

Add missing changes entries for LUCENE-8502 and LUCENE-8503


> Simplify unwrapping Filter*Reader
> -
>
> Key: LUCENE-8503
> URL: https://issues.apache.org/jira/browse/LUCENE-8503
> Project: Lucene - Core
>  Issue Type: Improvement
>Affects Versions: 7.5, master (8.0)
>Reporter: Simon Willnauer
>Priority: Major
> Fix For: 7.5, master (8.0)
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
>  Today we have 3 different kinds of FilterIndexReader. While 
> FilterDirecotryReader
> and FilterLeafReader are simple to distinguish, FilterCodecReader make 
> decision harder
> since now we need instanceof checks to deside which unwrap method we 
> should call. This
> adds a simple interface that allows to build generic unwrap methods to 
> access the delegat
> of each of the filtering readers.



--
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-8503) Simplify unwrapping Filter*Reader

[ASF subversion and git services (JIRA)]

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

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

Commit e61f6961cc09b708a438f2fc41a653de0ea0de17 in lucene-solr's branch 
refs/heads/branch_7_5 from [~simonw]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=e61f696 ]

Add missing changes entries for LUCENE-8502 and LUCENE-8503


> Simplify unwrapping Filter*Reader
> -
>
> Key: LUCENE-8503
> URL: https://issues.apache.org/jira/browse/LUCENE-8503
> Project: Lucene - Core
>  Issue Type: Improvement
>Affects Versions: 7.5, master (8.0)
>Reporter: Simon Willnauer
>Priority: Major
> Fix For: 7.5, master (8.0)
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
>  Today we have 3 different kinds of FilterIndexReader. While 
> FilterDirecotryReader
> and FilterLeafReader are simple to distinguish, FilterCodecReader make 
> decision harder
> since now we need instanceof checks to deside which unwrap method we 
> should call. This
> adds a simple interface that allows to build generic unwrap methods to 
> access the delegat
> of each of the filtering readers.



--
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-8503) Simplify unwrapping Filter*Reader

[Simon Willnauer (JIRA)]

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

Simon Willnauer resolved LUCENE-8503.
-
   Resolution: Fixed
Fix Version/s: (was: 7.6)
   7.5

> Simplify unwrapping Filter*Reader
> -
>
> Key: LUCENE-8503
> URL: https://issues.apache.org/jira/browse/LUCENE-8503
> Project: Lucene - Core
>  Issue Type: Improvement
>Affects Versions: 7.5, master (8.0)
>Reporter: Simon Willnauer
>Priority: Major
> Fix For: 7.5, master (8.0)
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
>  Today we have 3 different kinds of FilterIndexReader. While 
> FilterDirecotryReader
> and FilterLeafReader are simple to distinguish, FilterCodecReader make 
> decision harder
> since now we need instanceof checks to deside which unwrap method we 
> should call. This
> adds a simple interface that allows to build generic unwrap methods to 
> access the delegat
> of each of the filtering readers.



--
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-8502) Allow access to delegate in FilterCodecReader

[ASF subversion and git services (JIRA)]

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

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

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

Add missing changes entries for LUCENE-8502 and LUCENE-8503


>  Allow access to delegate in FilterCodecReader
> --
>
> Key: LUCENE-8502
> URL: https://issues.apache.org/jira/browse/LUCENE-8502
> Project: Lucene - Core
>  Issue Type: Bug
>Affects Versions: 7.5, master (8.0)
>Reporter: Simon Willnauer
>Priority: Major
> Fix For: 7.5, master (8.0)
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
>  FilterCodecReader doesn't allow access to it's delegate like other
> filter readers. This adds a new getDelegate method to access the
> wrapped reader.



--
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-8502) Allow access to delegate in FilterCodecReader

[ASF subversion and git services (JIRA)]

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

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

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

Add missing changes entries for LUCENE-8502 and LUCENE-8503


>  Allow access to delegate in FilterCodecReader
> --
>
> Key: LUCENE-8502
> URL: https://issues.apache.org/jira/browse/LUCENE-8502
> Project: Lucene - Core
>  Issue Type: Bug
>Affects Versions: 7.5, master (8.0)
>Reporter: Simon Willnauer
>Priority: Major
> Fix For: 7.5, master (8.0)
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
>  FilterCodecReader doesn't allow access to it's delegate like other
> filter readers. This adds a new getDelegate method to access the
> wrapped reader.



--
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-8503) Simplify unwrapping Filter*Reader

[ASF subversion and git services (JIRA)]

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

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

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

Add missing changes entries for LUCENE-8502 and LUCENE-8503


> Simplify unwrapping Filter*Reader
> -
>
> Key: LUCENE-8503
> URL: https://issues.apache.org/jira/browse/LUCENE-8503
> Project: Lucene - Core
>  Issue Type: Improvement
>Affects Versions: 7.5, master (8.0)
>Reporter: Simon Willnauer
>Priority: Major
> Fix For: 7.5, master (8.0)
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
>  Today we have 3 different kinds of FilterIndexReader. While 
> FilterDirecotryReader
> and FilterLeafReader are simple to distinguish, FilterCodecReader make 
> decision harder
> since now we need instanceof checks to deside which unwrap method we 
> should call. This
> adds a simple interface that allows to build generic unwrap methods to 
> access the delegat
> of each of the filtering readers.



--
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-8502) Allow access to delegate in FilterCodecReader

[ASF subversion and git services (JIRA)]

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

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

Commit e61f6961cc09b708a438f2fc41a653de0ea0de17 in lucene-solr's branch 
refs/heads/branch_7_5 from [~simonw]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=e61f696 ]

Add missing changes entries for LUCENE-8502 and LUCENE-8503


>  Allow access to delegate in FilterCodecReader
> --
>
> Key: LUCENE-8502
> URL: https://issues.apache.org/jira/browse/LUCENE-8502
> Project: Lucene - Core
>  Issue Type: Bug
>Affects Versions: 7.5, master (8.0)
>Reporter: Simon Willnauer
>Priority: Major
> Fix For: 7.5, master (8.0)
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
>  FilterCodecReader doesn't allow access to it's delegate like other
> filter readers. This adds a new getDelegate method to access the
> wrapped reader.



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

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

Re: Lucene/Solr 7.5

[jim ferenczi]

Thanks Andrzej and Simon. Unless we cancel 7.5 there is no need to backport
to 7.4 since we cannot publish 7.4.1 after 7.5.0.
I created the draft release notes for the wiki:
https://wiki.apache.org/lucene-java/ReleaseNote75
https://wiki.apache.org/solr/ReleaseNote75
I picked some items from Solr's change logs but someone more familiar with
these changes should review. Same for Lucene.
I still plan to build the first RC tomorrow morning so feel free to
backport any urgent bug fixes before the end of the day.

Thanks


Le lun. 17 sept. 2018 à 15:46, Andrzej Białecki  a écrit :

> SOLR-12765 has been committed now to master, branch_7x, branch_7_5 and
> branch_7_4. Thanks!
>
> On 17 Sep 2018, at 14:14, jim ferenczi  wrote:
>
> Hi,
>
> Andrzej, there is another issue in the queue (LUCENE-8502) so I'll wait
> one more day to build the first RC., please backport the fix for the JMX
> beans. Cassandra, I backported the Tika version change in the docs, if
> SOLR-12771 is merged today I'll include it in the RC tomorrow.
>
> Le lun. 17 sept. 2018 à 13:57, Andrzej Białecki  a écrit :
>
>> Hi Jim,
>>
>> I’d like to commit a fix for SOLR-12765 where a side-effect from other
>> issue changed the format of some JMX beans.
>>
>> On 14 Sep 2018, at 23:25, jim ferenczi  wrote:
>>
>> Sorry for the late reply. I built the first RC earlier today and had some
>> issues to pass the smoke tests. Most of the issue were on my end but I had
>> to open https://issues.apache.org/jira/browse/LUCENE-8500 to fix an
>> actual bug. SCassandra, the issue is in the smoke tester so I don't know if
>> we need a respin but I didn't send the artifacts so I can just rebuild RC1
>> with LUCENE-8500 when it's merged. In the meantime don't hesitate to merge
>> the doc changes regarding Tika. Steve I can wait Tuesday to rebuild RC1 if
>> you think it's worth waiting, otherwise if the smoke tests are fixed I'll
>> proceed on Monday.
>>
>> Le ven. 14 sept. 2018 à 21:01, Steve Rowe  a écrit :
>>
>>> Hi Jim,
>>>
>>> I put the Solr ref guide edits Cassandra referred to in a patch on
>>> SOLR-12771, but as I mentioned in a comment there, I’d like to get Hoss’ss
>>> input before I commit, and he’s taking today off, so it’ll probably be
>>> Monday before he’ll have a chance to look at it.
>>>
>>> So in short, please don’t delay building the RC for SOLR-12771.
>>>
>>> --
>>> Steve
>>> www.lucidworks.com
>>>
>>> > On Sep 14, 2018, at 8:40 AM, Cassandra Targett 
>>> wrote:
>>> >
>>> > Hi Jim,
>>> >
>>> > Are you working on the RC now? Overnight I discovered two really minor
>>> things: first, there's an error in CHANGES.txt regarding the Tika version
>>> that I mentioned in SOLR-12551 - Erick told me offline to go ahead and fix
>>> it. Second, Steve has some edits he'd like to get in for the Solr Ref Guide
>>> he also sent me offline.
>>> >
>>> > Neither have very much impact, but both could probably wait until/if
>>> there is a respin of the RC - basically if you haven't started the RC yet
>>> I'll push those through. But if you have started I'll wait.
>>> >
>>> > Thanks,
>>> > Cassandra
>>> >
>>> > On Thu, Sep 13, 2018 at 3:30 AM jim ferenczi 
>>> wrote:
>>> > Sure you can backport Tomás, the first RC is planned for tomorrow.
>>> >
>>> > Le jeu. 13 sept. 2018 à 00:10, Tomás Fernández Löbbe <
>>> tomasflo...@gmail.com> a écrit :
>>> > Hi Jim,
>>> > I'd like to commit SOLR-12766 to 7.5. SOLR-11881 added retries for
>>> internal requests, but the backoff time in cases with multiple updates can
>>> become big, and cause clients to timeout. The change is minimal, just
>>> backoff once for a retry batch instead of for every doc.
>>> >
>>> > I'm testing a patch and plan to commit later today, if there aren't
>>> any issues or objections.
>>> >
>>> > On Wed, Sep 12, 2018 at 5:39 AM jim ferenczi 
>>> wrote:
>>> > Thanks !
>>> >
>>> > Le mer. 12 sept. 2018 à 11:49, Adrien Grand  a
>>> écrit :
>>> > Hey Jim,
>>> >
>>> > I added you to the hudson-jobadmin group so that you can do it next
>>> time.
>>> >
>>> > Steve, thanks for taking care of setting up the builds!
>>> >
>>> > Le mar. 11 sept. 2018 à 17:32, jim ferenczi 
>>> a écrit :
>>> > No worries at all Cassandra. What do you think of building the first
>>> RC on Friday and start the vote on Monday next week ? This will leave some
>>> > room to finish the missing bits.
>>> > Could someone help to setup the Jenkins releases build ? It seems that
>>> I cannot create jobs with my account.
>>> >
>>> > Le mar. 11 sept. 2018 à 14:08, Cassandra Targett <
>>> casstarg...@gmail.com> a écrit :
>>> > Sorry, Jim, I should have replied yesterday about the state of things
>>> with the Ref Guide - it's close. I'm doing the last bit of big review I
>>> need to do and am nearly done with that, then I have a couple more small
>>> things done (including SOLR-12763 which I just created since I forgot to do
>>> it earlier). My goal is to be done by the end of my day today so you could
>>> do the RC tomorrow, but who knows what the day wil

[jira] [Commented] (LUCENE-8503) Simplify unwrapping Filter*Reader

[ASF subversion and git services (JIRA)]

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

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

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

LUCENE-8503: Call #getDelegate instead of direct member access during unwrap

Filter*Reader instances access the member or the delegate directly instead of
calling getDelegate(). In order to track access of the delegate these methods
should call #getDelegat()


> Simplify unwrapping Filter*Reader
> -
>
> Key: LUCENE-8503
> URL: https://issues.apache.org/jira/browse/LUCENE-8503
> Project: Lucene - Core
>  Issue Type: Improvement
>Affects Versions: 7.5, master (8.0)
>Reporter: Simon Willnauer
>Priority: Major
> Fix For: 7.6, master (8.0)
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
>  Today we have 3 different kinds of FilterIndexReader. While 
> FilterDirecotryReader
> and FilterLeafReader are simple to distinguish, FilterCodecReader make 
> decision harder
> since now we need instanceof checks to deside which unwrap method we 
> should call. This
> adds a simple interface that allows to build generic unwrap methods to 
> access the delegat
> of each of the filtering readers.



--
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-8503) Simplify unwrapping Filter*Reader

[ASF subversion and git services (JIRA)]

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

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

Commit d98e4929a0ea55e8cae4f791ad705f6b776c7c7f in lucene-solr's branch 
refs/heads/branch_7_5 from [~simonw]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=d98e492 ]

LUCENE-8503: Call #getDelegate instead of direct member access during unwrap

Filter*Reader instances access the member or the delegate directly instead of
calling getDelegate(). In order to track access of the delegate these methods
should call #getDelegat()


> Simplify unwrapping Filter*Reader
> -
>
> Key: LUCENE-8503
> URL: https://issues.apache.org/jira/browse/LUCENE-8503
> Project: Lucene - Core
>  Issue Type: Improvement
>Affects Versions: 7.5, master (8.0)
>Reporter: Simon Willnauer
>Priority: Major
> Fix For: 7.6, master (8.0)
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
>  Today we have 3 different kinds of FilterIndexReader. While 
> FilterDirecotryReader
> and FilterLeafReader are simple to distinguish, FilterCodecReader make 
> decision harder
> since now we need instanceof checks to deside which unwrap method we 
> should call. This
> adds a simple interface that allows to build generic unwrap methods to 
> access the delegat
> of each of the filtering readers.



--
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 pull request #454: LUCENE-8503: Call #getDelegate instead of dir...

[asfgit]

Github user asfgit closed the pull request at:

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


---

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

[jira] [Commented] (LUCENE-8503) Simplify unwrapping Filter*Reader

[ASF subversion and git services (JIRA)]

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

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

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

LUCENE-8503: Call #getDelegate instead of direct member access during unwrap

Filter*Reader instances access the member or the delegate directly instead of
calling getDelegate(). In order to track access of the delegate these methods
should call #getDelegat()


> Simplify unwrapping Filter*Reader
> -
>
> Key: LUCENE-8503
> URL: https://issues.apache.org/jira/browse/LUCENE-8503
> Project: Lucene - Core
>  Issue Type: Improvement
>Affects Versions: 7.5, master (8.0)
>Reporter: Simon Willnauer
>Priority: Major
> Fix For: 7.6, master (8.0)
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
>  Today we have 3 different kinds of FilterIndexReader. While 
> FilterDirecotryReader
> and FilterLeafReader are simple to distinguish, FilterCodecReader make 
> decision harder
> since now we need instanceof checks to deside which unwrap method we 
> should call. This
> adds a simple interface that allows to build generic unwrap methods to 
> access the delegat
> of each of the filtering readers.



--
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-8501) An ability to define the sum method for custom term frequencies

[Adrien Grand (JIRA)]

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

Adrien Grand commented on LUCENE-8501:
--

bq. In my case I'd be a bit worried about the loss of precision with the 16 bit 
encoding

Do you know how many values per field you expect at most? For instance using 24 
bits by shifting the bits of the float representation right by 7 instead of 15 
would retain more accuracy while allowing for about 128 values per field per 
document. In general scoring doesn't focus on accuracy: we are happy with 
recording lengths on a single byte, using Math.log(1+x) rather than 
Math.log1p(x) or tweaking scoring formulas to add ones if it can help avoid 
dividing by zero. Better accuracy doesn't improve ranking significantly.

bq. I'm still wondering would it make sense to allow the users to overwrite the 
sum function for different use-cases.

It might... but such extension points have a significant impact on the API and 
testing. In general we'd rather not add them unless there is a strong case to 
introduce them. Also there are ramifications: if we change the way that the 
length is computed, then we also need to change the way that frequencies are 
combined when a field has the same value twice, we also need to worry about how 
to reflect it on index statistics like totalTermFreq and sumTotalTermFreq, etc.



> An ability to define the sum method for custom term frequencies
> ---
>
> Key: LUCENE-8501
> URL: https://issues.apache.org/jira/browse/LUCENE-8501
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/index
>Reporter: Olli Kuonanoja
>Priority: Major
>
> Custom term frequencies allows expert users to index and score in custom 
> ways, however, _DefaultIndexingChain_ adds a limitation to this as the sum of 
> frequencies can't overflow
> {code:java}
> try {
> invertState.length = Math.addExact(invertState.length, 
> invertState.termFreqAttribute.getTermFrequency());
> } catch (ArithmeticException ae) {
> throw new IllegalArgumentException("too many tokens for field \"" + 
> field.name() + "\"");
> }
> {code}
> This might become an issue if for example the frequency data is encoded in a 
> different way, say the specific scorer works with float frequencies.
> The sum method can be added to _TermFrequencyAttribute_ to get something like
> {code:java}
> invertState.length = 
> invertState.termFreqAttribute.addFrequency(invertState.length);
> {code}
> so users may define the summing method and avoid the owerflow exceptions.



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

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

Re: Lucene/Solr 7.5

[Andrzej Białecki]

SOLR-12765 has been committed now to master, branch_7x, branch_7_5 and 
branch_7_4. Thanks!

> On 17 Sep 2018, at 14:14, jim ferenczi  wrote:
> 
> Hi,
> 
> Andrzej, there is another issue in the queue (LUCENE-8502) so I'll wait one 
> more day to build the first RC., please backport the fix for the JMX beans. 
> Cassandra, I backported the Tika version change in the docs, if SOLR-12771 is 
> merged today I'll include it in the RC tomorrow. 
> 
> Le lun. 17 sept. 2018 à 13:57, Andrzej Białecki  > a écrit :
> Hi Jim,
> 
> I’d like to commit a fix for SOLR-12765 where a side-effect from other issue 
> changed the format of some JMX beans.
> 
>> On 14 Sep 2018, at 23:25, jim ferenczi > > wrote:
>> 
>> Sorry for the late reply. I built the first RC earlier today and had some 
>> issues to pass the smoke tests. Most of the issue were on my end but I had 
>> to open https://issues.apache.org/jira/browse/LUCENE-8500 
>>  to fix an actual bug. 
>> SCassandra, the issue is in the smoke tester so I don't know if we need a 
>> respin but I didn't send the artifacts so I can just rebuild RC1 with 
>> LUCENE-8500 when it's merged. In the meantime don't hesitate to merge the 
>> doc changes regarding Tika. Steve I can wait Tuesday to rebuild RC1 if you 
>> think it's worth waiting, otherwise if the smoke tests are fixed I'll 
>> proceed on Monday.
>> 
>> Le ven. 14 sept. 2018 à 21:01, Steve Rowe > > a écrit :
>> Hi Jim,
>> 
>> I put the Solr ref guide edits Cassandra referred to in a patch on 
>> SOLR-12771, but as I mentioned in a comment there, I’d like to get Hoss’ss 
>> input before I commit, and he’s taking today off, so it’ll probably be 
>> Monday before he’ll have a chance to look at it.
>> 
>> So in short, please don’t delay building the RC for SOLR-12771.
>> 
>> --
>> Steve
>> www.lucidworks.com 
>> 
>> > On Sep 14, 2018, at 8:40 AM, Cassandra Targett > > > wrote:
>> > 
>> > Hi Jim, 
>> > 
>> > Are you working on the RC now? Overnight I discovered two really minor 
>> > things: first, there's an error in CHANGES.txt regarding the Tika version 
>> > that I mentioned in SOLR-12551 - Erick told me offline to go ahead and fix 
>> > it. Second, Steve has some edits he'd like to get in for the Solr Ref 
>> > Guide he also sent me offline.
>> > 
>> > Neither have very much impact, but both could probably wait until/if there 
>> > is a respin of the RC - basically if you haven't started the RC yet I'll 
>> > push those through. But if you have started I'll wait.
>> > 
>> > Thanks,
>> > Cassandra
>> > 
>> > On Thu, Sep 13, 2018 at 3:30 AM jim ferenczi > > > wrote:
>> > Sure you can backport Tomás, the first RC is planned for tomorrow.
>> > 
>> > Le jeu. 13 sept. 2018 à 00:10, Tomás Fernández Löbbe 
>> > mailto:tomasflo...@gmail.com>> a écrit :
>> > Hi Jim,
>> > I'd like to commit SOLR-12766 to 7.5. SOLR-11881 added retries for 
>> > internal requests, but the backoff time in cases with multiple updates can 
>> > become big, and cause clients to timeout. The change is minimal, just 
>> > backoff once for a retry batch instead of for every doc.
>> > 
>> > I'm testing a patch and plan to commit later today, if there aren't any 
>> > issues or objections. 
>> > 
>> > On Wed, Sep 12, 2018 at 5:39 AM jim ferenczi > > > wrote:
>> > Thanks !
>> > 
>> > Le mer. 12 sept. 2018 à 11:49, Adrien Grand > > > a écrit :
>> > Hey Jim,
>> > 
>> > I added you to the hudson-jobadmin group so that you can do it next time.
>> > 
>> > Steve, thanks for taking care of setting up the builds!
>> > 
>> > Le mar. 11 sept. 2018 à 17:32, jim ferenczi > > > a écrit :
>> > No worries at all Cassandra. What do you think of building the first RC on 
>> > Friday and start the vote on Monday next week ? This will leave some
>> > room to finish the missing bits. 
>> > Could someone help to setup the Jenkins releases build ? It seems that I 
>> > cannot create jobs with my account.
>> > 
>> > Le mar. 11 sept. 2018 à 14:08, Cassandra Targett > > > a écrit :
>> > Sorry, Jim, I should have replied yesterday about the state of things with 
>> > the Ref Guide - it's close. I'm doing the last bit of big review I need to 
>> > do and am nearly done with that, then I have a couple more small things 
>> > done (including SOLR-12763 which I just created since I forgot to do it 
>> > earlier). My goal is to be done by the end of my day today so you could do 
>> > the RC tomorrow, but who knows what the day will bring work-wise, so I'll 
>> > send another mail at the end of the day my time to let you know for sure.
>> > 
>> > On Mon, Sep 10, 2018 at 9:07 AM jim ferenczi > > > wrote:
>> > I just fixed the inv

[jira] [Commented] (SOLR-12765) Possibly incorrect format in JMX cache stats

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-12765:


Commit 8cfc86b419d0db5cd2bc692a144e32bbdee7ae2f in lucene-solr's branch 
refs/heads/branch_7_4 from Andrzej Bialecki
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=8cfc86b ]

SOLR-12765: Incorrect format of JMX cache stats.


> Possibly incorrect format in JMX cache stats
> 
>
> Key: SOLR-12765
> URL: https://issues.apache.org/jira/browse/SOLR-12765
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: metrics
>Affects Versions: 7.4, 7.5, master (8.0)
>Reporter: Bojan Smid
>Assignee: Andrzej Bialecki 
>Priority: Major
> Attachments: SOLR-12765.patch
>
>
> I posted a question on ML 
> [https://mail-archives.apache.org/mod_mbox/lucene-solr-user/201809.mbox/%3CCAGniRXR4Ps%3D03X0uiByCn5ecUT2VY4TLV4iNcxCde3dxBnmC-w%40mail.gmail.com%3E|https://mail-archives.apache.org/mod_mbox/lucene-solr-user/201809.mbox/%3CCAGniRXR4Ps%3D03X0uiByCn5ecUT2VY4TLV4iNcxCde3dxBnmC-w%40mail.gmail.com%3E),]
>  , but didn't get feedback. Since it looks like a possible bug, I am opening 
> a ticket.
>  
>   It seems the format of cache mbeans changed with 7.4.0.  And from what I 
> see similar change wasn't made for other mbeans, which may mean it was 
> accidental and may be a bug.
>  
>   In Solr 7.3.* format was (each attribute on its own, numeric type):
>  
> mbean:
> solr:dom1=core,dom2=gettingstarted,dom3=shard1,dom4=replica_n1,category=CACHE,scope=searcher,name=filterCache
>  
> attributes:
>   lookups java.lang.Long = 0
>   hits java.lang.Long = 0
>   cumulative_evictions java.lang.Long = 0
>   size java.lang.Long = 0
>   hitratio java.lang.Float = 0.0
>   evictions java.lang.Long = 0
>   cumulative_lookups java.lang.Long = 0
>   cumulative_hitratio java.lang.Float = 0.0
>   warmupTime java.lang.Long = 0
>   inserts java.lang.Long = 0
>   cumulative_inserts java.lang.Long = 0
>   cumulative_hits java.lang.Long = 0
>  
>   With 7.4.0 there is a single attribute "Value" (java.lang.Object):
>  
> mbean:
> solr:dom1=core,dom2=gettingstarted,dom3=shard1,dom4=replica_n1,category=CACHE,scope=searcher,name=filterCache
>  
> attributes:
>   Value java.lang.Object = \{lookups=0, evictions=0, 
> cumulative_inserts=0, cumulative_hits=0, hits=0, cumulative_evictions=0, 
> size=0, hitratio=0.0, cumulative_lookups=0, cumulative_hitratio=0.0, 
> warmupTime=0, inserts=0}
>  



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

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

[jira] [Commented] (SOLR-12765) Possibly incorrect format in JMX cache stats

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-12765:


Commit 922e016245f6dde5f87a908ee0555ef3df60c8ac in lucene-solr's branch 
refs/heads/branch_7x from Andrzej Bialecki
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=922e016 ]

SOLR-12765: Incorrect format of JMX cache stats.


> Possibly incorrect format in JMX cache stats
> 
>
> Key: SOLR-12765
> URL: https://issues.apache.org/jira/browse/SOLR-12765
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: metrics
>Affects Versions: 7.4, 7.5, master (8.0)
>Reporter: Bojan Smid
>Assignee: Andrzej Bialecki 
>Priority: Major
> Attachments: SOLR-12765.patch
>
>
> I posted a question on ML 
> [https://mail-archives.apache.org/mod_mbox/lucene-solr-user/201809.mbox/%3CCAGniRXR4Ps%3D03X0uiByCn5ecUT2VY4TLV4iNcxCde3dxBnmC-w%40mail.gmail.com%3E|https://mail-archives.apache.org/mod_mbox/lucene-solr-user/201809.mbox/%3CCAGniRXR4Ps%3D03X0uiByCn5ecUT2VY4TLV4iNcxCde3dxBnmC-w%40mail.gmail.com%3E),]
>  , but didn't get feedback. Since it looks like a possible bug, I am opening 
> a ticket.
>  
>   It seems the format of cache mbeans changed with 7.4.0.  And from what I 
> see similar change wasn't made for other mbeans, which may mean it was 
> accidental and may be a bug.
>  
>   In Solr 7.3.* format was (each attribute on its own, numeric type):
>  
> mbean:
> solr:dom1=core,dom2=gettingstarted,dom3=shard1,dom4=replica_n1,category=CACHE,scope=searcher,name=filterCache
>  
> attributes:
>   lookups java.lang.Long = 0
>   hits java.lang.Long = 0
>   cumulative_evictions java.lang.Long = 0
>   size java.lang.Long = 0
>   hitratio java.lang.Float = 0.0
>   evictions java.lang.Long = 0
>   cumulative_lookups java.lang.Long = 0
>   cumulative_hitratio java.lang.Float = 0.0
>   warmupTime java.lang.Long = 0
>   inserts java.lang.Long = 0
>   cumulative_inserts java.lang.Long = 0
>   cumulative_hits java.lang.Long = 0
>  
>   With 7.4.0 there is a single attribute "Value" (java.lang.Object):
>  
> mbean:
> solr:dom1=core,dom2=gettingstarted,dom3=shard1,dom4=replica_n1,category=CACHE,scope=searcher,name=filterCache
>  
> attributes:
>   Value java.lang.Object = \{lookups=0, evictions=0, 
> cumulative_inserts=0, cumulative_hits=0, hits=0, cumulative_evictions=0, 
> size=0, hitratio=0.0, cumulative_lookups=0, cumulative_hitratio=0.0, 
> warmupTime=0, inserts=0}
>  



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

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

[jira] [Commented] (LUCENE-8503) Simplify unwrapping Filter*Reader

[Adrien Grand (JIRA)]

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

Adrien Grand commented on LUCENE-8503:
--

+1

> Simplify unwrapping Filter*Reader
> -
>
> Key: LUCENE-8503
> URL: https://issues.apache.org/jira/browse/LUCENE-8503
> Project: Lucene - Core
>  Issue Type: Improvement
>Affects Versions: 7.5, master (8.0)
>Reporter: Simon Willnauer
>Priority: Major
> Fix For: 7.6, master (8.0)
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
>  Today we have 3 different kinds of FilterIndexReader. While 
> FilterDirecotryReader
> and FilterLeafReader are simple to distinguish, FilterCodecReader make 
> decision harder
> since now we need instanceof checks to deside which unwrap method we 
> should call. This
> adds a simple interface that allows to build generic unwrap methods to 
> access the delegat
> of each of the filtering readers.



--
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-12765) Possibly incorrect format in JMX cache stats

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-12765:


Commit f9b2f09393557d39216e348b2147808e799be74d in lucene-solr's branch 
refs/heads/branch_7_5 from Andrzej Bialecki
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=f9b2f09 ]

SOLR-12765: Incorrect format of JMX cache stats.


> Possibly incorrect format in JMX cache stats
> 
>
> Key: SOLR-12765
> URL: https://issues.apache.org/jira/browse/SOLR-12765
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: metrics
>Affects Versions: 7.4, 7.5, master (8.0)
>Reporter: Bojan Smid
>Assignee: Andrzej Bialecki 
>Priority: Major
> Attachments: SOLR-12765.patch
>
>
> I posted a question on ML 
> [https://mail-archives.apache.org/mod_mbox/lucene-solr-user/201809.mbox/%3CCAGniRXR4Ps%3D03X0uiByCn5ecUT2VY4TLV4iNcxCde3dxBnmC-w%40mail.gmail.com%3E|https://mail-archives.apache.org/mod_mbox/lucene-solr-user/201809.mbox/%3CCAGniRXR4Ps%3D03X0uiByCn5ecUT2VY4TLV4iNcxCde3dxBnmC-w%40mail.gmail.com%3E),]
>  , but didn't get feedback. Since it looks like a possible bug, I am opening 
> a ticket.
>  
>   It seems the format of cache mbeans changed with 7.4.0.  And from what I 
> see similar change wasn't made for other mbeans, which may mean it was 
> accidental and may be a bug.
>  
>   In Solr 7.3.* format was (each attribute on its own, numeric type):
>  
> mbean:
> solr:dom1=core,dom2=gettingstarted,dom3=shard1,dom4=replica_n1,category=CACHE,scope=searcher,name=filterCache
>  
> attributes:
>   lookups java.lang.Long = 0
>   hits java.lang.Long = 0
>   cumulative_evictions java.lang.Long = 0
>   size java.lang.Long = 0
>   hitratio java.lang.Float = 0.0
>   evictions java.lang.Long = 0
>   cumulative_lookups java.lang.Long = 0
>   cumulative_hitratio java.lang.Float = 0.0
>   warmupTime java.lang.Long = 0
>   inserts java.lang.Long = 0
>   cumulative_inserts java.lang.Long = 0
>   cumulative_hits java.lang.Long = 0
>  
>   With 7.4.0 there is a single attribute "Value" (java.lang.Object):
>  
> mbean:
> solr:dom1=core,dom2=gettingstarted,dom3=shard1,dom4=replica_n1,category=CACHE,scope=searcher,name=filterCache
>  
> attributes:
>   Value java.lang.Object = \{lookups=0, evictions=0, 
> cumulative_inserts=0, cumulative_hits=0, hits=0, cumulative_evictions=0, 
> size=0, hitratio=0.0, cumulative_lookups=0, cumulative_hitratio=0.0, 
> warmupTime=0, inserts=0}
>  



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

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

[jira] [Updated] (LUCENE-8502) Allow access to delegate in FilterCodecReader

[Jim Ferenczi (JIRA)]

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

Jim Ferenczi updated LUCENE-8502:
-
Fix Version/s: (was: 7.6)
   (was: 7.5.1)
   7.5

>  Allow access to delegate in FilterCodecReader
> --
>
> Key: LUCENE-8502
> URL: https://issues.apache.org/jira/browse/LUCENE-8502
> Project: Lucene - Core
>  Issue Type: Bug
>Affects Versions: 7.5, master (8.0)
>Reporter: Simon Willnauer
>Priority: Major
> Fix For: 7.5, master (8.0)
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
>  FilterCodecReader doesn't allow access to it's delegate like other
> filter readers. This adds a new getDelegate method to access the
> wrapped reader.



--
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-12765) Possibly incorrect format in JMX cache stats

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-12765:


Commit 36eae571636426148ea25028c5b0e0149ce45f88 in lucene-solr's branch 
refs/heads/master from Andrzej Bialecki
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=36eae57 ]

SOLR-12765: Incorrect format of JMX cache stats.


> Possibly incorrect format in JMX cache stats
> 
>
> Key: SOLR-12765
> URL: https://issues.apache.org/jira/browse/SOLR-12765
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: metrics
>Affects Versions: 7.4, 7.5, master (8.0)
>Reporter: Bojan Smid
>Assignee: Andrzej Bialecki 
>Priority: Major
> Attachments: SOLR-12765.patch
>
>
> I posted a question on ML 
> [https://mail-archives.apache.org/mod_mbox/lucene-solr-user/201809.mbox/%3CCAGniRXR4Ps%3D03X0uiByCn5ecUT2VY4TLV4iNcxCde3dxBnmC-w%40mail.gmail.com%3E|https://mail-archives.apache.org/mod_mbox/lucene-solr-user/201809.mbox/%3CCAGniRXR4Ps%3D03X0uiByCn5ecUT2VY4TLV4iNcxCde3dxBnmC-w%40mail.gmail.com%3E),]
>  , but didn't get feedback. Since it looks like a possible bug, I am opening 
> a ticket.
>  
>   It seems the format of cache mbeans changed with 7.4.0.  And from what I 
> see similar change wasn't made for other mbeans, which may mean it was 
> accidental and may be a bug.
>  
>   In Solr 7.3.* format was (each attribute on its own, numeric type):
>  
> mbean:
> solr:dom1=core,dom2=gettingstarted,dom3=shard1,dom4=replica_n1,category=CACHE,scope=searcher,name=filterCache
>  
> attributes:
>   lookups java.lang.Long = 0
>   hits java.lang.Long = 0
>   cumulative_evictions java.lang.Long = 0
>   size java.lang.Long = 0
>   hitratio java.lang.Float = 0.0
>   evictions java.lang.Long = 0
>   cumulative_lookups java.lang.Long = 0
>   cumulative_hitratio java.lang.Float = 0.0
>   warmupTime java.lang.Long = 0
>   inserts java.lang.Long = 0
>   cumulative_inserts java.lang.Long = 0
>   cumulative_hits java.lang.Long = 0
>  
>   With 7.4.0 there is a single attribute "Value" (java.lang.Object):
>  
> mbean:
> solr:dom1=core,dom2=gettingstarted,dom3=shard1,dom4=replica_n1,category=CACHE,scope=searcher,name=filterCache
>  
> attributes:
>   Value java.lang.Object = \{lookups=0, evictions=0, 
> cumulative_inserts=0, cumulative_hits=0, hits=0, cumulative_evictions=0, 
> size=0, hitratio=0.0, cumulative_lookups=0, cumulative_hitratio=0.0, 
> warmupTime=0, inserts=0}
>  



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

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

Re: Lucene/Solr 7.5

[Simon Willnauer]

LUCENE-8502 is in and backported

On Mon, Sep 17, 2018 at 2:14 PM jim ferenczi  wrote:

> Hi,
>
> Andrzej, there is another issue in the queue (LUCENE-8502) so I'll wait
> one more day to build the first RC., please backport the fix for the JMX
> beans. Cassandra, I backported the Tika version change in the docs, if
> SOLR-12771 is merged today I'll include it in the RC tomorrow.
>
> Le lun. 17 sept. 2018 à 13:57, Andrzej Białecki  a écrit :
>
>> Hi Jim,
>>
>> I’d like to commit a fix for SOLR-12765 where a side-effect from other
>> issue changed the format of some JMX beans.
>>
>> On 14 Sep 2018, at 23:25, jim ferenczi  wrote:
>>
>> Sorry for the late reply. I built the first RC earlier today and had some
>> issues to pass the smoke tests. Most of the issue were on my end but I had
>> to open https://issues.apache.org/jira/browse/LUCENE-8500 to fix an
>> actual bug. SCassandra, the issue is in the smoke tester so I don't know if
>> we need a respin but I didn't send the artifacts so I can just rebuild RC1
>> with LUCENE-8500 when it's merged. In the meantime don't hesitate to merge
>> the doc changes regarding Tika. Steve I can wait Tuesday to rebuild RC1 if
>> you think it's worth waiting, otherwise if the smoke tests are fixed I'll
>> proceed on Monday.
>>
>> Le ven. 14 sept. 2018 à 21:01, Steve Rowe  a écrit :
>>
>>> Hi Jim,
>>>
>>> I put the Solr ref guide edits Cassandra referred to in a patch on
>>> SOLR-12771, but as I mentioned in a comment there, I’d like to get Hoss’ss
>>> input before I commit, and he’s taking today off, so it’ll probably be
>>> Monday before he’ll have a chance to look at it.
>>>
>>> So in short, please don’t delay building the RC for SOLR-12771.
>>>
>>> --
>>> Steve
>>> www.lucidworks.com
>>>
>>> > On Sep 14, 2018, at 8:40 AM, Cassandra Targett 
>>> wrote:
>>> >
>>> > Hi Jim,
>>> >
>>> > Are you working on the RC now? Overnight I discovered two really minor
>>> things: first, there's an error in CHANGES.txt regarding the Tika version
>>> that I mentioned in SOLR-12551 - Erick told me offline to go ahead and fix
>>> it. Second, Steve has some edits he'd like to get in for the Solr Ref Guide
>>> he also sent me offline.
>>> >
>>> > Neither have very much impact, but both could probably wait until/if
>>> there is a respin of the RC - basically if you haven't started the RC yet
>>> I'll push those through. But if you have started I'll wait.
>>> >
>>> > Thanks,
>>> > Cassandra
>>> >
>>> > On Thu, Sep 13, 2018 at 3:30 AM jim ferenczi 
>>> wrote:
>>> > Sure you can backport Tomás, the first RC is planned for tomorrow.
>>> >
>>> > Le jeu. 13 sept. 2018 à 00:10, Tomás Fernández Löbbe <
>>> tomasflo...@gmail.com> a écrit :
>>> > Hi Jim,
>>> > I'd like to commit SOLR-12766 to 7.5. SOLR-11881 added retries for
>>> internal requests, but the backoff time in cases with multiple updates can
>>> become big, and cause clients to timeout. The change is minimal, just
>>> backoff once for a retry batch instead of for every doc.
>>> >
>>> > I'm testing a patch and plan to commit later today, if there aren't
>>> any issues or objections.
>>> >
>>> > On Wed, Sep 12, 2018 at 5:39 AM jim ferenczi 
>>> wrote:
>>> > Thanks !
>>> >
>>> > Le mer. 12 sept. 2018 à 11:49, Adrien Grand  a
>>> écrit :
>>> > Hey Jim,
>>> >
>>> > I added you to the hudson-jobadmin group so that you can do it next
>>> time.
>>> >
>>> > Steve, thanks for taking care of setting up the builds!
>>> >
>>> > Le mar. 11 sept. 2018 à 17:32, jim ferenczi 
>>> a écrit :
>>> > No worries at all Cassandra. What do you think of building the first
>>> RC on Friday and start the vote on Monday next week ? This will leave some
>>> > room to finish the missing bits.
>>> > Could someone help to setup the Jenkins releases build ? It seems that
>>> I cannot create jobs with my account.
>>> >
>>> > Le mar. 11 sept. 2018 à 14:08, Cassandra Targett <
>>> casstarg...@gmail.com> a écrit :
>>> > Sorry, Jim, I should have replied yesterday about the state of things
>>> with the Ref Guide - it's close. I'm doing the last bit of big review I
>>> need to do and am nearly done with that, then I have a couple more small
>>> things done (including SOLR-12763 which I just created since I forgot to do
>>> it earlier). My goal is to be done by the end of my day today so you could
>>> do the RC tomorrow, but who knows what the day will bring work-wise, so
>>> I'll send another mail at the end of the day my time to let you know for
>>> sure.
>>> >
>>> > On Mon, Sep 10, 2018 at 9:07 AM jim ferenczi 
>>> wrote:
>>> > I just fixed the invalid version (7.5.1) that I added in master and
>>> 7x. The next version on these branches should be 7.6.0, sorry for the noise.
>>> >
>>> > Le lun. 10 sept. 2018 à 09:26, jim ferenczi 
>>> a écrit :
>>> > Hi,
>>> >
>>> > Feature freeze for 7.5 has started, I just created a branch_7_5.:
>>> >
>>> > * No new features may be committed to the branch.
>>> > * Documentation patches, build patches and serious bug fixes may be
>>> committed t

[jira] [Commented] (SOLR-6280) Collapse QParser should give error for multiValued field

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-6280:
---

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

SOLR-6280: CollapseQParser now throws an error when pointing to a multi-valued 
field.

(cherry picked from commit ac7969e3c05cf9db28dbe52d0911d64a864d8c97)


> Collapse QParser should give error for multiValued field
> 
>
> Key: SOLR-6280
> URL: https://issues.apache.org/jira/browse/SOLR-6280
> Project: Solr
>  Issue Type: Improvement
>  Components: search
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Minor
> Attachments: SOLR-6280.patch, SOLR-6280.patch
>
>
> The Collapse QParser does give results if you collapse on a multi-valued 
> field, but the document->value is somewhat arbitrarily chosen based on the 
> internals of the FieldCache (FieldCacheImpl.SortedDocValuesCache).
> Note that the Grouping functionality accesses values via 
> FieldType.getValueSource which is a layer of abstraction above that includes 
> a multiValued error check.
> Collapse should throw an error here.
> p.s. easy to test with exampledocs collapsing on "cat"



--
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-6280) Collapse QParser should give error for multiValued field

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-6280:
---

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

SOLR-6280: CollapseQParser now throws an error when pointing to a multi-valued 
field.


> Collapse QParser should give error for multiValued field
> 
>
> Key: SOLR-6280
> URL: https://issues.apache.org/jira/browse/SOLR-6280
> Project: Solr
>  Issue Type: Improvement
>  Components: search
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Minor
> Attachments: SOLR-6280.patch, SOLR-6280.patch
>
>
> The Collapse QParser does give results if you collapse on a multi-valued 
> field, but the document->value is somewhat arbitrarily chosen based on the 
> internals of the FieldCache (FieldCacheImpl.SortedDocValuesCache).
> Note that the Grouping functionality accesses values via 
> FieldType.getValueSource which is a layer of abstraction above that includes 
> a multiValued error check.
> Collapse should throw an error here.
> p.s. easy to test with exampledocs collapsing on "cat"



--
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 issue #455: WIP: SOLR-12638

[moshebla]

Github user moshebla commented on the issue:

https://github.com/apache/lucene-solr/pull/455
  
Currently Some Solr Core tests do not pass.
I will work on those, since this is a WIP.
The test that concerns me the most is ConvertedLegacyTest, which fails only 
if VersionInfo#lookupVersion is called.


---

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

[GitHub] lucene-solr pull request #455: SOLR-12638

[moshebla]

GitHub user moshebla opened a pull request:

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

SOLR-12638



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

$ git pull https://github.com/moshebla/lucene-solr SOLR-12638

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

https://github.com/apache/lucene-solr/pull/455.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #455


commit 34e2b0b3fac2f8fb6c085fe4db23130a0b634924
Author: Moshe 
Date:   2018-08-23T08:11:57Z

SOLR-12638: first unittest

commit ce09bdb208b5cd8d9fb69a7c22377752d3c19200
Author: Moshe 
Date:   2018-08-30T06:36:32Z

SOLR-12638: start working on RTG fetch block

commit 1fb442915ed16f6a6d844ebffb89bdfbda641c0d
Author: Moshe 
Date:   2018-09-06T07:13:16Z

SOLR-12638: tests for child docs atomic updates

commit a9d759546784d2ed3674bcc0a85342466b7cc9ad
Author: Moshe 
Date:   2018-09-16T13:10:10Z

SOLR-12638: edit tests and delete old block by version if exists

commit 8a840a3e56ffc525250389aceae1149eedf336fc
Author: Moshe 
Date:   2018-09-17T05:16:16Z

SOLR-12638: minor fixes

commit 5617013725a67002914f59acc064fe09c937c07f
Author: Moshe 
Date:   2018-09-17T11:42:41Z

SOLR-12368: separate configs for atomic block update tests

commit 06b3436e929165cf7df68643f480995bbe2e5c76
Author: Moshe 
Date:   2018-09-17T13:05:09Z

SOLR-12368: tidy up for PR




---

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

[jira] [Commented] (LUCENE-8501) An ability to define the sum method for custom term frequencies

[Olli Kuonanoja (JIRA)]

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

Olli Kuonanoja commented on LUCENE-8501:


Thanks for the pointer [~jpountz]. In my case I'd be a bit worried about the 
loss of precision with the 16 bit encoding, can't say for sure without proper 
testing how much it would affect the results. However, the storage efficiency 
has not been an issue for me in practise. One more issue I forgot to point out 
in the original description is the value of _invertState.length_ becomes 
useless for similarities as it is always the sum of the integer 
representations. Using a fixed point encoding would be a workaround for that 
but I'm still wondering would it make sense to allow the users to overwrite the 
sum function for different use-cases.

> An ability to define the sum method for custom term frequencies
> ---
>
> Key: LUCENE-8501
> URL: https://issues.apache.org/jira/browse/LUCENE-8501
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/index
>Reporter: Olli Kuonanoja
>Priority: Major
>
> Custom term frequencies allows expert users to index and score in custom 
> ways, however, _DefaultIndexingChain_ adds a limitation to this as the sum of 
> frequencies can't overflow
> {code:java}
> try {
> invertState.length = Math.addExact(invertState.length, 
> invertState.termFreqAttribute.getTermFrequency());
> } catch (ArithmeticException ae) {
> throw new IllegalArgumentException("too many tokens for field \"" + 
> field.name() + "\"");
> }
> {code}
> This might become an issue if for example the frequency data is encoded in a 
> different way, say the specific scorer works with float frequencies.
> The sum method can be added to _TermFrequencyAttribute_ to get something like
> {code:java}
> invertState.length = 
> invertState.termFreqAttribute.addFrequency(invertState.length);
> {code}
> so users may define the summing method and avoid the owerflow exceptions.



--
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] (LUCENE-8505) IndexWriter#addIndices should not sort indices if they are not already sorted

[Jim Ferenczi (JIRA)]

Jim Ferenczi created LUCENE-8505:


 Summary: IndexWriter#addIndices should not sort indices if they 
are not already sorted
 Key: LUCENE-8505
 URL: https://issues.apache.org/jira/browse/LUCENE-8505
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Jim Ferenczi


Today IndexWriter#addIndices silently re-sort non-sorted indices when they are 
added in a sorted index. This is not safe because the sort is done entirely in 
memory and cannot handle big segments efficiently. This leniency was added 
because prior to 6.5, segments produced by flushes were not sorted, they had to 
wait for a merge to apply the index sorting. Now that segments are always 
sorted (LUCENE-7579) we should remove this ability and throw an error if the 
sort of the current index does not match with the candidate.



--
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-12775) Add a deprecated implementation of LowerCaseTokenizer

[David Smiley (JIRA)]

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

David Smiley commented on SOLR-12775:
-

A rolling upgrade would be change the schema 1st – use 
{{UnicodeWhitespaceTokenizer}} followed by {{LowerCaseFilterFactory}} and 2nd 
use the next Solr version.  A _code_ level deprecation would be nice, but I 
don't think required.  We will certainly mention how to upgrade in CHANGES.txt. 
 I'm trying to avoid extra work on ourselves to remove old stuff when there's 
an easy path, and furthermore avoid adding technical debt for some future major 
reversion to remove something that we might actually not pay down.

> Add a deprecated implementation of LowerCaseTokenizer
> -
>
> Key: SOLR-12775
> URL: https://issues.apache.org/jira/browse/SOLR-12775
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Alan Woodward
>Priority: Blocker
> Fix For: master (8.0)
>
> Attachments: SOLR-12775.patch
>
>
> LUCENE-8498 will remove LowerCaseTokenizer and LowerCaseTokenizerFactory from 
> lucene 8.  To make upgrading from Solr 7.x to Solr 8 easier for users who 
> have schemas that use LowerCaseTokenizerFactory, we should add a deprecated 
> copy of the code to the {{org.apache.solr.analysis}} package.



--
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-12765) Possibly incorrect format in JMX cache stats

[Andrzej Bialecki (JIRA)]

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

Andrzej Bialecki  updated SOLR-12765:
-
Affects Version/s: master (8.0)

> Possibly incorrect format in JMX cache stats
> 
>
> Key: SOLR-12765
> URL: https://issues.apache.org/jira/browse/SOLR-12765
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: metrics
>Affects Versions: 7.4, 7.5, master (8.0)
>Reporter: Bojan Smid
>Assignee: Andrzej Bialecki 
>Priority: Major
> Attachments: SOLR-12765.patch
>
>
> I posted a question on ML 
> [https://mail-archives.apache.org/mod_mbox/lucene-solr-user/201809.mbox/%3CCAGniRXR4Ps%3D03X0uiByCn5ecUT2VY4TLV4iNcxCde3dxBnmC-w%40mail.gmail.com%3E|https://mail-archives.apache.org/mod_mbox/lucene-solr-user/201809.mbox/%3CCAGniRXR4Ps%3D03X0uiByCn5ecUT2VY4TLV4iNcxCde3dxBnmC-w%40mail.gmail.com%3E),]
>  , but didn't get feedback. Since it looks like a possible bug, I am opening 
> a ticket.
>  
>   It seems the format of cache mbeans changed with 7.4.0.  And from what I 
> see similar change wasn't made for other mbeans, which may mean it was 
> accidental and may be a bug.
>  
>   In Solr 7.3.* format was (each attribute on its own, numeric type):
>  
> mbean:
> solr:dom1=core,dom2=gettingstarted,dom3=shard1,dom4=replica_n1,category=CACHE,scope=searcher,name=filterCache
>  
> attributes:
>   lookups java.lang.Long = 0
>   hits java.lang.Long = 0
>   cumulative_evictions java.lang.Long = 0
>   size java.lang.Long = 0
>   hitratio java.lang.Float = 0.0
>   evictions java.lang.Long = 0
>   cumulative_lookups java.lang.Long = 0
>   cumulative_hitratio java.lang.Float = 0.0
>   warmupTime java.lang.Long = 0
>   inserts java.lang.Long = 0
>   cumulative_inserts java.lang.Long = 0
>   cumulative_hits java.lang.Long = 0
>  
>   With 7.4.0 there is a single attribute "Value" (java.lang.Object):
>  
> mbean:
> solr:dom1=core,dom2=gettingstarted,dom3=shard1,dom4=replica_n1,category=CACHE,scope=searcher,name=filterCache
>  
> attributes:
>   Value java.lang.Object = \{lookups=0, evictions=0, 
> cumulative_inserts=0, cumulative_hits=0, hits=0, cumulative_evictions=0, 
> size=0, hitratio=0.0, cumulative_lookups=0, cumulative_hitratio=0.0, 
> warmupTime=0, inserts=0}
>  



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

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

[jira] [Commented] (SOLR-12777) Solr server directory needs to be writable by the user running solr

[JIRA]

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

Jan Høydahl commented on SOLR-12777:


It is not so that the server directory needs to be writeable. But the PID and 
LOGS directories need to be, and they are by default located relative to the 
server directory. All of this is works as documented in 
[https://lucene.apache.org/solr/guide/7_4/taking-solr-to-production.html] and 
thus do not classify as a bug. The linux installer configures these and gives 
you a R/O server directory by default.

I'm not completely sure what you are proposing with this JIRA? More command 
args to the bin/start script so you don't need to configure solr.in.sh?

> Solr server directory needs to be writable by the user running solr
> ---
>
> Key: SOLR-12777
> URL: https://issues.apache.org/jira/browse/SOLR-12777
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: scripts and tools
>Affects Versions: 7.3.1
>Reporter: Pete Ryland
>Priority: Major
>
> When starting solr, an optional {{-d}} parameter can be provided.  This 
> specifies the "Solr server directory" which needs to be the {{server}} 
> directory from the raw distribution.  This clearly contains the program 
> files, so as per common practice should not be writable by the user running 
> the program.  However, when specified, an error results because it tries to 
> create a log directory within the program directory!  This is really really 
> bad practice.  One should be able to specify a directory for the runtime 
> files and log files on the command line.  It would be even better if the 
> defaults conformed to the filesystem hierarchy standard when run on a Linux 
> system.  I understand that you want to make it easy for developers to use 
> your software, but when deploying on actual production systems, these things 
> are really important.  It's also important to understand that the people 
> deploying your software to production are different to the ones who develop 
> with your software, and a deep understanding of your software shouldn't be 
> necessary for the former to be able to deploy it.
> A wholly-unsatisfactory workaround is to set the pid and log directories by 
> environment variable before starting the server:
> {{$ export SOLR_PID_DIR=/var/lib/celum-search}}
> {{$ export SOLR_LOGS_DIR=/var/log/celum-search}}
> This can also be done in {{/etc/default/solr.in.sh}}.



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

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

[jira] [Resolved] (SOLR-7909) ZK ACL credential provider cannot be set from JVM params as documented

[JIRA]

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

Jan Høydahl resolved SOLR-7909.
---
Resolution: Cannot Reproduce

This now works, so it must have been fixed sometime since 5.5

> ZK ACL credential provider cannot be set from JVM params as documented
> --
>
> Key: SOLR-7909
> URL: https://issues.apache.org/jira/browse/SOLR-7909
> Project: Solr
>  Issue Type: Bug
>  Components: security
>Affects Versions: 5.2.1
>Reporter: Jan Høydahl
>Priority: Major
> Fix For: 5.5
>
>
> In RefGuide 
> https://cwiki.apache.org/confluence/display/solr/ZooKeeper+Access+Control you 
> are told to setup ZK security provider classes with system properties, but as 
> noted in the comments to that page, that no longer works, and you need to set 
> these in solr.xml.



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

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

Re: Lucene/Solr 7.5

[jim ferenczi]

Hi,

Andrzej, there is another issue in the queue (LUCENE-8502) so I'll wait one
more day to build the first RC., please backport the fix for the JMX beans.
Cassandra, I backported the Tika version change in the docs, if SOLR-12771
is merged today I'll include it in the RC tomorrow.

Le lun. 17 sept. 2018 à 13:57, Andrzej Białecki  a écrit :

> Hi Jim,
>
> I’d like to commit a fix for SOLR-12765 where a side-effect from other
> issue changed the format of some JMX beans.
>
> On 14 Sep 2018, at 23:25, jim ferenczi  wrote:
>
> Sorry for the late reply. I built the first RC earlier today and had some
> issues to pass the smoke tests. Most of the issue were on my end but I had
> to open https://issues.apache.org/jira/browse/LUCENE-8500 to fix an
> actual bug. SCassandra, the issue is in the smoke tester so I don't know if
> we need a respin but I didn't send the artifacts so I can just rebuild RC1
> with LUCENE-8500 when it's merged. In the meantime don't hesitate to merge
> the doc changes regarding Tika. Steve I can wait Tuesday to rebuild RC1 if
> you think it's worth waiting, otherwise if the smoke tests are fixed I'll
> proceed on Monday.
>
> Le ven. 14 sept. 2018 à 21:01, Steve Rowe  a écrit :
>
>> Hi Jim,
>>
>> I put the Solr ref guide edits Cassandra referred to in a patch on
>> SOLR-12771, but as I mentioned in a comment there, I’d like to get Hoss’ss
>> input before I commit, and he’s taking today off, so it’ll probably be
>> Monday before he’ll have a chance to look at it.
>>
>> So in short, please don’t delay building the RC for SOLR-12771.
>>
>> --
>> Steve
>> www.lucidworks.com
>>
>> > On Sep 14, 2018, at 8:40 AM, Cassandra Targett 
>> wrote:
>> >
>> > Hi Jim,
>> >
>> > Are you working on the RC now? Overnight I discovered two really minor
>> things: first, there's an error in CHANGES.txt regarding the Tika version
>> that I mentioned in SOLR-12551 - Erick told me offline to go ahead and fix
>> it. Second, Steve has some edits he'd like to get in for the Solr Ref Guide
>> he also sent me offline.
>> >
>> > Neither have very much impact, but both could probably wait until/if
>> there is a respin of the RC - basically if you haven't started the RC yet
>> I'll push those through. But if you have started I'll wait.
>> >
>> > Thanks,
>> > Cassandra
>> >
>> > On Thu, Sep 13, 2018 at 3:30 AM jim ferenczi 
>> wrote:
>> > Sure you can backport Tomás, the first RC is planned for tomorrow.
>> >
>> > Le jeu. 13 sept. 2018 à 00:10, Tomás Fernández Löbbe <
>> tomasflo...@gmail.com> a écrit :
>> > Hi Jim,
>> > I'd like to commit SOLR-12766 to 7.5. SOLR-11881 added retries for
>> internal requests, but the backoff time in cases with multiple updates can
>> become big, and cause clients to timeout. The change is minimal, just
>> backoff once for a retry batch instead of for every doc.
>> >
>> > I'm testing a patch and plan to commit later today, if there aren't any
>> issues or objections.
>> >
>> > On Wed, Sep 12, 2018 at 5:39 AM jim ferenczi 
>> wrote:
>> > Thanks !
>> >
>> > Le mer. 12 sept. 2018 à 11:49, Adrien Grand  a
>> écrit :
>> > Hey Jim,
>> >
>> > I added you to the hudson-jobadmin group so that you can do it next
>> time.
>> >
>> > Steve, thanks for taking care of setting up the builds!
>> >
>> > Le mar. 11 sept. 2018 à 17:32, jim ferenczi  a
>> écrit :
>> > No worries at all Cassandra. What do you think of building the first RC
>> on Friday and start the vote on Monday next week ? This will leave some
>> > room to finish the missing bits.
>> > Could someone help to setup the Jenkins releases build ? It seems that
>> I cannot create jobs with my account.
>> >
>> > Le mar. 11 sept. 2018 à 14:08, Cassandra Targett 
>> a écrit :
>> > Sorry, Jim, I should have replied yesterday about the state of things
>> with the Ref Guide - it's close. I'm doing the last bit of big review I
>> need to do and am nearly done with that, then I have a couple more small
>> things done (including SOLR-12763 which I just created since I forgot to do
>> it earlier). My goal is to be done by the end of my day today so you could
>> do the RC tomorrow, but who knows what the day will bring work-wise, so
>> I'll send another mail at the end of the day my time to let you know for
>> sure.
>> >
>> > On Mon, Sep 10, 2018 at 9:07 AM jim ferenczi 
>> wrote:
>> > I just fixed the invalid version (7.5.1) that I added in master and 7x.
>> The next version on these branches should be 7.6.0, sorry for the noise.
>> >
>> > Le lun. 10 sept. 2018 à 09:26, jim ferenczi  a
>> écrit :
>> > Hi,
>> >
>> > Feature freeze for 7.5 has started, I just created a branch_7_5.:
>> >
>> > * No new features may be committed to the branch.
>> > * Documentation patches, build patches and serious bug fixes may be
>> committed to the branch. However, you should submit all patches you want to
>> commit to Jira first to give others the chance to review and possibly vote
>> against the patch. Keep in mind that it is our main intention to keep the
>> branch as stabl

Re: Lucene/Solr 7.5

[Andrzej Białecki]

Hi Jim,

I’d like to commit a fix for SOLR-12765 where a side-effect from other issue 
changed the format of some JMX beans.

> On 14 Sep 2018, at 23:25, jim ferenczi  wrote:
> 
> Sorry for the late reply. I built the first RC earlier today and had some 
> issues to pass the smoke tests. Most of the issue were on my end but I had to 
> open https://issues.apache.org/jira/browse/LUCENE-8500 
>  to fix an actual bug. 
> SCassandra, the issue is in the smoke tester so I don't know if we need a 
> respin but I didn't send the artifacts so I can just rebuild RC1 with 
> LUCENE-8500 when it's merged. In the meantime don't hesitate to merge the doc 
> changes regarding Tika. Steve I can wait Tuesday to rebuild RC1 if you think 
> it's worth waiting, otherwise if the smoke tests are fixed I'll proceed on 
> Monday.
> 
> Le ven. 14 sept. 2018 à 21:01, Steve Rowe  > a écrit :
> Hi Jim,
> 
> I put the Solr ref guide edits Cassandra referred to in a patch on 
> SOLR-12771, but as I mentioned in a comment there, I’d like to get Hoss’ss 
> input before I commit, and he’s taking today off, so it’ll probably be Monday 
> before he’ll have a chance to look at it.
> 
> So in short, please don’t delay building the RC for SOLR-12771.
> 
> --
> Steve
> www.lucidworks.com 
> 
> > On Sep 14, 2018, at 8:40 AM, Cassandra Targett  > > wrote:
> > 
> > Hi Jim, 
> > 
> > Are you working on the RC now? Overnight I discovered two really minor 
> > things: first, there's an error in CHANGES.txt regarding the Tika version 
> > that I mentioned in SOLR-12551 - Erick told me offline to go ahead and fix 
> > it. Second, Steve has some edits he'd like to get in for the Solr Ref Guide 
> > he also sent me offline.
> > 
> > Neither have very much impact, but both could probably wait until/if there 
> > is a respin of the RC - basically if you haven't started the RC yet I'll 
> > push those through. But if you have started I'll wait.
> > 
> > Thanks,
> > Cassandra
> > 
> > On Thu, Sep 13, 2018 at 3:30 AM jim ferenczi  > > wrote:
> > Sure you can backport Tomás, the first RC is planned for tomorrow.
> > 
> > Le jeu. 13 sept. 2018 à 00:10, Tomás Fernández Löbbe  > > a écrit :
> > Hi Jim,
> > I'd like to commit SOLR-12766 to 7.5. SOLR-11881 added retries for internal 
> > requests, but the backoff time in cases with multiple updates can become 
> > big, and cause clients to timeout. The change is minimal, just backoff once 
> > for a retry batch instead of for every doc.
> > 
> > I'm testing a patch and plan to commit later today, if there aren't any 
> > issues or objections. 
> > 
> > On Wed, Sep 12, 2018 at 5:39 AM jim ferenczi  > > wrote:
> > Thanks !
> > 
> > Le mer. 12 sept. 2018 à 11:49, Adrien Grand  > > a écrit :
> > Hey Jim,
> > 
> > I added you to the hudson-jobadmin group so that you can do it next time.
> > 
> > Steve, thanks for taking care of setting up the builds!
> > 
> > Le mar. 11 sept. 2018 à 17:32, jim ferenczi  > > a écrit :
> > No worries at all Cassandra. What do you think of building the first RC on 
> > Friday and start the vote on Monday next week ? This will leave some
> > room to finish the missing bits. 
> > Could someone help to setup the Jenkins releases build ? It seems that I 
> > cannot create jobs with my account.
> > 
> > Le mar. 11 sept. 2018 à 14:08, Cassandra Targett  > > a écrit :
> > Sorry, Jim, I should have replied yesterday about the state of things with 
> > the Ref Guide - it's close. I'm doing the last bit of big review I need to 
> > do and am nearly done with that, then I have a couple more small things 
> > done (including SOLR-12763 which I just created since I forgot to do it 
> > earlier). My goal is to be done by the end of my day today so you could do 
> > the RC tomorrow, but who knows what the day will bring work-wise, so I'll 
> > send another mail at the end of the day my time to let you know for sure.
> > 
> > On Mon, Sep 10, 2018 at 9:07 AM jim ferenczi  > > wrote:
> > I just fixed the invalid version (7.5.1) that I added in master and 7x. The 
> > next version on these branches should be 7.6.0, sorry for the noise.
> > 
> > Le lun. 10 sept. 2018 à 09:26, jim ferenczi  > > a écrit :
> > Hi,
> > 
> > Feature freeze for 7.5 has started, I just created a branch_7_5.:
> > 
> > * No new features may be committed to the branch.
> > * Documentation patches, build patches and serious bug fixes may be 
> > committed to the branch. However, you should submit all patches you want to 
> > commit to Jira first to give others the chance to review and possibly vote 
> > against the patch. Keep in mind that it is our main intention to 

[jira] [Commented] (SOLR-12765) Possibly incorrect format in JMX cache stats

[Andrzej Bialecki (JIRA)]

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

Andrzej Bialecki  commented on SOLR-12765:
--

This patch restores the previous format of the beans. I'd like to include this 
in 7.5 and backport to 7.4.x.

> Possibly incorrect format in JMX cache stats
> 
>
> Key: SOLR-12765
> URL: https://issues.apache.org/jira/browse/SOLR-12765
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: metrics
>Affects Versions: 7.4, 7.5
>Reporter: Bojan Smid
>Assignee: Andrzej Bialecki 
>Priority: Major
> Attachments: SOLR-12765.patch
>
>
> I posted a question on ML 
> [https://mail-archives.apache.org/mod_mbox/lucene-solr-user/201809.mbox/%3CCAGniRXR4Ps%3D03X0uiByCn5ecUT2VY4TLV4iNcxCde3dxBnmC-w%40mail.gmail.com%3E|https://mail-archives.apache.org/mod_mbox/lucene-solr-user/201809.mbox/%3CCAGniRXR4Ps%3D03X0uiByCn5ecUT2VY4TLV4iNcxCde3dxBnmC-w%40mail.gmail.com%3E),]
>  , but didn't get feedback. Since it looks like a possible bug, I am opening 
> a ticket.
>  
>   It seems the format of cache mbeans changed with 7.4.0.  And from what I 
> see similar change wasn't made for other mbeans, which may mean it was 
> accidental and may be a bug.
>  
>   In Solr 7.3.* format was (each attribute on its own, numeric type):
>  
> mbean:
> solr:dom1=core,dom2=gettingstarted,dom3=shard1,dom4=replica_n1,category=CACHE,scope=searcher,name=filterCache
>  
> attributes:
>   lookups java.lang.Long = 0
>   hits java.lang.Long = 0
>   cumulative_evictions java.lang.Long = 0
>   size java.lang.Long = 0
>   hitratio java.lang.Float = 0.0
>   evictions java.lang.Long = 0
>   cumulative_lookups java.lang.Long = 0
>   cumulative_hitratio java.lang.Float = 0.0
>   warmupTime java.lang.Long = 0
>   inserts java.lang.Long = 0
>   cumulative_inserts java.lang.Long = 0
>   cumulative_hits java.lang.Long = 0
>  
>   With 7.4.0 there is a single attribute "Value" (java.lang.Object):
>  
> mbean:
> solr:dom1=core,dom2=gettingstarted,dom3=shard1,dom4=replica_n1,category=CACHE,scope=searcher,name=filterCache
>  
> attributes:
>   Value java.lang.Object = \{lookups=0, evictions=0, 
> cumulative_inserts=0, cumulative_hits=0, hits=0, cumulative_evictions=0, 
> size=0, hitratio=0.0, cumulative_lookups=0, cumulative_hitratio=0.0, 
> warmupTime=0, inserts=0}
>  



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

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

[jira] [Updated] (SOLR-12765) Possibly incorrect format in JMX cache stats

[Andrzej Bialecki (JIRA)]

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

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

> Possibly incorrect format in JMX cache stats
> 
>
> Key: SOLR-12765
> URL: https://issues.apache.org/jira/browse/SOLR-12765
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: metrics
>Affects Versions: 7.4, 7.5
>Reporter: Bojan Smid
>Assignee: Andrzej Bialecki 
>Priority: Major
> Attachments: SOLR-12765.patch
>
>
> I posted a question on ML 
> [https://mail-archives.apache.org/mod_mbox/lucene-solr-user/201809.mbox/%3CCAGniRXR4Ps%3D03X0uiByCn5ecUT2VY4TLV4iNcxCde3dxBnmC-w%40mail.gmail.com%3E|https://mail-archives.apache.org/mod_mbox/lucene-solr-user/201809.mbox/%3CCAGniRXR4Ps%3D03X0uiByCn5ecUT2VY4TLV4iNcxCde3dxBnmC-w%40mail.gmail.com%3E),]
>  , but didn't get feedback. Since it looks like a possible bug, I am opening 
> a ticket.
>  
>   It seems the format of cache mbeans changed with 7.4.0.  And from what I 
> see similar change wasn't made for other mbeans, which may mean it was 
> accidental and may be a bug.
>  
>   In Solr 7.3.* format was (each attribute on its own, numeric type):
>  
> mbean:
> solr:dom1=core,dom2=gettingstarted,dom3=shard1,dom4=replica_n1,category=CACHE,scope=searcher,name=filterCache
>  
> attributes:
>   lookups java.lang.Long = 0
>   hits java.lang.Long = 0
>   cumulative_evictions java.lang.Long = 0
>   size java.lang.Long = 0
>   hitratio java.lang.Float = 0.0
>   evictions java.lang.Long = 0
>   cumulative_lookups java.lang.Long = 0
>   cumulative_hitratio java.lang.Float = 0.0
>   warmupTime java.lang.Long = 0
>   inserts java.lang.Long = 0
>   cumulative_inserts java.lang.Long = 0
>   cumulative_hits java.lang.Long = 0
>  
>   With 7.4.0 there is a single attribute "Value" (java.lang.Object):
>  
> mbean:
> solr:dom1=core,dom2=gettingstarted,dom3=shard1,dom4=replica_n1,category=CACHE,scope=searcher,name=filterCache
>  
> attributes:
>   Value java.lang.Object = \{lookups=0, evictions=0, 
> cumulative_inserts=0, cumulative_hits=0, hits=0, cumulative_evictions=0, 
> size=0, hitratio=0.0, cumulative_lookups=0, cumulative_hitratio=0.0, 
> warmupTime=0, inserts=0}
>  



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

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

[jira] [Commented] (SOLR-7909) ZK ACL credential provider cannot be set from JVM params as documented

[JIRA]

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

Jan Høydahl commented on SOLR-7909:
---

Anyone know if this now works? I will try to test

> ZK ACL credential provider cannot be set from JVM params as documented
> --
>
> Key: SOLR-7909
> URL: https://issues.apache.org/jira/browse/SOLR-7909
> Project: Solr
>  Issue Type: Bug
>  Components: security
>Affects Versions: 5.2.1
>Reporter: Jan Høydahl
>Priority: Major
> Fix For: 5.5
>
>
> In RefGuide 
> https://cwiki.apache.org/confluence/display/solr/ZooKeeper+Access+Control you 
> are told to setup ZK security provider classes with system properties, but as 
> noted in the comments to that page, that no longer works, and you need to set 
> these in solr.xml.



--
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-7892) Allow configuring ZK credentials and ACL outside of solr.xml

[JIRA]

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

Jan Høydahl updated SOLR-7892:
--
Description: 
See [https://cwiki.apache.org/confluence/display/solr/ZooKeeper+Access+Control]

To get {{zkCredientialsProvider}} you need to parse {{solr.xml}}, but since 
{{solr.xml}} now can live in ZK, we need to have a way to keep various ZK setup 
and credentials elsewhere. By default in {{SolrDispatchFilter}} we'll use a 
{{SolrZkClient}} which reads zk creds/acl from VM params only, which should be 
fine.

After solr.xml is read from zookeeper, the properties from solr.xml are used 
instead. These will be the same as the initial VM param though, so since we 
need a way to discover these classes from VM params anyway, we can skip the 
{{solr.xml}} config for these and simplify.

  was:
See https://cwiki.apache.org/confluence/display/solr/ZooKeeper+Access+Control

To get {{zkCredientialsProvider}} you need to parse {{solr.xml}}, but since 
{{solr.xml}} now can live in ZK, we need to have a way to keep various ZK setup 
and credentials elsewhere, e.g. in {{solr.properties}}. When SOLR-7909 is 
solved, you could pass the provider through VM params and thus keep it in 
{{solr.in.sh}}, but for consistency we should support solr.properties too.


> Allow configuring ZK credentials and ACL outside of solr.xml
> 
>
> Key: SOLR-7892
> URL: https://issues.apache.org/jira/browse/SOLR-7892
> Project: Solr
>  Issue Type: Sub-task
>  Components: security
>Reporter: Jan Høydahl
>Priority: Major
> Fix For: 6.0
>
>
> See 
> [https://cwiki.apache.org/confluence/display/solr/ZooKeeper+Access+Control]
> To get {{zkCredientialsProvider}} you need to parse {{solr.xml}}, but since 
> {{solr.xml}} now can live in ZK, we need to have a way to keep various ZK 
> setup and credentials elsewhere. By default in {{SolrDispatchFilter}} we'll 
> use a {{SolrZkClient}} which reads zk creds/acl from VM params only, which 
> should be fine.
> After solr.xml is read from zookeeper, the properties from solr.xml are used 
> instead. These will be the same as the initial VM param though, so since we 
> need a way to discover these classes from VM params anyway, we can skip the 
> {{solr.xml}} config for these and simplify.



--
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-12765) Possibly incorrect format in JMX cache stats

[Andrzej Bialecki (JIRA)]

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

Andrzej Bialecki  commented on SOLR-12765:
--

I've confirmed that this is a bug, most likely a side-effect of changes 
introduced in SOLR-11882, I'm looking into a fix.

> Possibly incorrect format in JMX cache stats
> 
>
> Key: SOLR-12765
> URL: https://issues.apache.org/jira/browse/SOLR-12765
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: metrics
>Affects Versions: 7.4, 7.5
>Reporter: Bojan Smid
>Assignee: Andrzej Bialecki 
>Priority: Major
>
> I posted a question on ML 
> [https://mail-archives.apache.org/mod_mbox/lucene-solr-user/201809.mbox/%3CCAGniRXR4Ps%3D03X0uiByCn5ecUT2VY4TLV4iNcxCde3dxBnmC-w%40mail.gmail.com%3E|https://mail-archives.apache.org/mod_mbox/lucene-solr-user/201809.mbox/%3CCAGniRXR4Ps%3D03X0uiByCn5ecUT2VY4TLV4iNcxCde3dxBnmC-w%40mail.gmail.com%3E),]
>  , but didn't get feedback. Since it looks like a possible bug, I am opening 
> a ticket.
>  
>   It seems the format of cache mbeans changed with 7.4.0.  And from what I 
> see similar change wasn't made for other mbeans, which may mean it was 
> accidental and may be a bug.
>  
>   In Solr 7.3.* format was (each attribute on its own, numeric type):
>  
> mbean:
> solr:dom1=core,dom2=gettingstarted,dom3=shard1,dom4=replica_n1,category=CACHE,scope=searcher,name=filterCache
>  
> attributes:
>   lookups java.lang.Long = 0
>   hits java.lang.Long = 0
>   cumulative_evictions java.lang.Long = 0
>   size java.lang.Long = 0
>   hitratio java.lang.Float = 0.0
>   evictions java.lang.Long = 0
>   cumulative_lookups java.lang.Long = 0
>   cumulative_hitratio java.lang.Float = 0.0
>   warmupTime java.lang.Long = 0
>   inserts java.lang.Long = 0
>   cumulative_inserts java.lang.Long = 0
>   cumulative_hits java.lang.Long = 0
>  
>   With 7.4.0 there is a single attribute "Value" (java.lang.Object):
>  
> mbean:
> solr:dom1=core,dom2=gettingstarted,dom3=shard1,dom4=replica_n1,category=CACHE,scope=searcher,name=filterCache
>  
> attributes:
>   Value java.lang.Object = \{lookups=0, evictions=0, 
> cumulative_inserts=0, cumulative_hits=0, hits=0, cumulative_evictions=0, 
> size=0, hitratio=0.0, cumulative_lookups=0, cumulative_hitratio=0.0, 
> warmupTime=0, inserts=0}
>  



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

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

[jira] [Updated] (SOLR-12765) Possibly incorrect format in JMX cache stats

[Andrzej Bialecki (JIRA)]

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

Andrzej Bialecki  updated SOLR-12765:
-
Affects Version/s: 7.5

> Possibly incorrect format in JMX cache stats
> 
>
> Key: SOLR-12765
> URL: https://issues.apache.org/jira/browse/SOLR-12765
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: metrics
>Affects Versions: 7.4, 7.5
>Reporter: Bojan Smid
>Assignee: Andrzej Bialecki 
>Priority: Major
>
> I posted a question on ML 
> [https://mail-archives.apache.org/mod_mbox/lucene-solr-user/201809.mbox/%3CCAGniRXR4Ps%3D03X0uiByCn5ecUT2VY4TLV4iNcxCde3dxBnmC-w%40mail.gmail.com%3E|https://mail-archives.apache.org/mod_mbox/lucene-solr-user/201809.mbox/%3CCAGniRXR4Ps%3D03X0uiByCn5ecUT2VY4TLV4iNcxCde3dxBnmC-w%40mail.gmail.com%3E),]
>  , but didn't get feedback. Since it looks like a possible bug, I am opening 
> a ticket.
>  
>   It seems the format of cache mbeans changed with 7.4.0.  And from what I 
> see similar change wasn't made for other mbeans, which may mean it was 
> accidental and may be a bug.
>  
>   In Solr 7.3.* format was (each attribute on its own, numeric type):
>  
> mbean:
> solr:dom1=core,dom2=gettingstarted,dom3=shard1,dom4=replica_n1,category=CACHE,scope=searcher,name=filterCache
>  
> attributes:
>   lookups java.lang.Long = 0
>   hits java.lang.Long = 0
>   cumulative_evictions java.lang.Long = 0
>   size java.lang.Long = 0
>   hitratio java.lang.Float = 0.0
>   evictions java.lang.Long = 0
>   cumulative_lookups java.lang.Long = 0
>   cumulative_hitratio java.lang.Float = 0.0
>   warmupTime java.lang.Long = 0
>   inserts java.lang.Long = 0
>   cumulative_inserts java.lang.Long = 0
>   cumulative_hits java.lang.Long = 0
>  
>   With 7.4.0 there is a single attribute "Value" (java.lang.Object):
>  
> mbean:
> solr:dom1=core,dom2=gettingstarted,dom3=shard1,dom4=replica_n1,category=CACHE,scope=searcher,name=filterCache
>  
> attributes:
>   Value java.lang.Object = \{lookups=0, evictions=0, 
> cumulative_inserts=0, cumulative_hits=0, hits=0, cumulative_evictions=0, 
> size=0, hitratio=0.0, cumulative_lookups=0, cumulative_hitratio=0.0, 
> warmupTime=0, inserts=0}
>  



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

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

[jira] [Updated] (SOLR-7892) Allow configuring ZK credentials and ACL outside of solr.xml

[JIRA]

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

Jan Høydahl updated SOLR-7892:
--
Summary: Allow configuring ZK credentials and ACL outside of solr.xml  
(was: Allow storing ZK ACL credentials in solr.properties)

> Allow configuring ZK credentials and ACL outside of solr.xml
> 
>
> Key: SOLR-7892
> URL: https://issues.apache.org/jira/browse/SOLR-7892
> Project: Solr
>  Issue Type: Sub-task
>  Components: security
>Reporter: Jan Høydahl
>Priority: Major
> Fix For: 6.0
>
>
> See https://cwiki.apache.org/confluence/display/solr/ZooKeeper+Access+Control
> To get {{zkCredientialsProvider}} you need to parse {{solr.xml}}, but since 
> {{solr.xml}} now can live in ZK, we need to have a way to keep various ZK 
> setup and credentials elsewhere, e.g. in {{solr.properties}}. When SOLR-7909 
> is solved, you could pass the provider through VM params and thus keep it in 
> {{solr.in.sh}}, but for consistency we should support solr.properties too.



--
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-8504) Update forbiddenapis to version 2.6

[Uwe Schindler (JIRA)]

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

Uwe Schindler resolved LUCENE-8504.
---
   Resolution: Fixed
 Assignee: Uwe Schindler
Fix Version/s: master (8.0)
   7.6

> Update forbiddenapis to version 2.6
> ---
>
> Key: LUCENE-8504
> URL: https://issues.apache.org/jira/browse/LUCENE-8504
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
>Priority: Major
> Fix For: 7.6, master (8.0)
>
>
> Forbiddenapis 2.6 was released today. The main change is support for Java 11. 
> It also fixes many bugs with Gradle, but this is not interesting to Lucene.
> I will just commit the update, the issue is just a placeholder.



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