[JENKINS] Lucene-Solr-7.x-Windows (64bit/jdk1.8.0_144) - Build # 551 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Windows/551/
Java: 64bit/jdk1.8.0_144 -XX:+UseCompressedOops -XX:+UseG1GC

5 tests failed.
FAILED:  org.apache.solr.handler.TestReplicationHandler.doTestStressReplication

Error Message:
found:2[index.20180419123338251, index.20180419123338491, index.properties, 
replication.properties, snapshot_metadata]

Stack Trace:
java.lang.AssertionError: found:2[index.20180419123338251, 
index.20180419123338491, index.properties, replication.properties, 
snapshot_metadata]
at 
__randomizedtesting.SeedInfo.seed([F38E89925782CC4A:2825895452AAA5F9]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.handler.TestReplicationHandler.checkForSingleIndex(TestReplicationHandler.java:968)
at 
org.apache.solr.handler.TestReplicationHandler.checkForSingleIndex(TestReplicationHandler.java:939)
at 
org.apache.solr.handler.TestReplicationHandler.doTestStressReplication(TestReplicationHandler.java:915)
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:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
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:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 

[jira] [Created] (SOLR-12239) Enabling index sorting causes "segment not sorted with indexSort=null"

[Ishan Chattopadhyaya (JIRA)]

Ishan Chattopadhyaya created SOLR-12239:
---

 Summary: Enabling index sorting causes "segment not sorted with 
indexSort=null"
 Key: SOLR-12239
 URL: https://issues.apache.org/jira/browse/SOLR-12239
 Project: Solr
  Issue Type: Improvement
  Security Level: Public (Default Security Level. Issues are Public)
Affects Versions: 7.1
Reporter: Ishan Chattopadhyaya


When index sorting is enabled on an existing collection/index (using 
SortingMergePolicy), the collection reload causes the following exception:

{code}
java.util.concurrent.ExecutionException: org.apache.solr.common.SolrException: 
Unable to create core [mycoll_shard1_replica_n1]
at java.util.concurrent.FutureTask.report(FutureTask.java:122)
at java.util.concurrent.FutureTask.get(FutureTask.java:192)
at 
org.apache.solr.core.CoreContainer.lambda$load$14(CoreContainer.java:671)
at 
com.codahale.metrics.InstrumentedExecutorService$InstrumentedRunnable.run(InstrumentedExecutorService.java:176)
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at 
org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:188)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
Caused by: org.apache.solr.common.SolrException: Unable to create core 
[mycoll_shard1_replica_n1]
at 
org.apache.solr.core.CoreContainer.createFromDescriptor(CoreContainer.java:1045)
at 
org.apache.solr.core.CoreContainer.lambda$load$13(CoreContainer.java:642)
at 
com.codahale.metrics.InstrumentedExecutorService$InstrumentedCallable.call(InstrumentedExecutorService.java:197)
... 5 more
Caused by: org.apache.solr.common.SolrException: Error opening new searcher
at org.apache.solr.core.SolrCore.(SolrCore.java:989)
at org.apache.solr.core.SolrCore.(SolrCore.java:844)
at 
org.apache.solr.core.CoreContainer.createFromDescriptor(CoreContainer.java:1029)
... 7 more
Caused by: org.apache.solr.common.SolrException: Error opening new searcher
at org.apache.solr.core.SolrCore.openNewSearcher(SolrCore.java:2076)
at org.apache.solr.core.SolrCore.getSearcher(SolrCore.java:2196)
at org.apache.solr.core.SolrCore.initSearcher(SolrCore.java:1072)
at org.apache.solr.core.SolrCore.(SolrCore.java:961)
... 9 more
Caused by: org.apache.lucene.index.CorruptIndexException: segment not sorted 
with indexSort=null (resource=_0(7.1.0):C1)
at 
org.apache.lucene.index.IndexWriter.validateIndexSort(IndexWriter.java:1185)
at org.apache.lucene.index.IndexWriter.(IndexWriter.java:1108)
at 
org.apache.solr.update.SolrIndexWriter.(SolrIndexWriter.java:119)
at 
org.apache.solr.update.SolrIndexWriter.create(SolrIndexWriter.java:94)
at 
org.apache.solr.update.DefaultSolrCoreState.createMainIndexWriter(DefaultSolrCoreState.java:257)
at 
org.apache.solr.update.DefaultSolrCoreState.getIndexWriter(DefaultSolrCoreState.java:131)
at org.apache.solr.core.SolrCore.openNewSearcher(SolrCore.java:2037)
... 12 more
{code}

This means that the user actually needs to delete the index segments, reload 
the collection and then re-index. This is bad user experience.



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

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

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

[Apache Jenkins Server]

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

No tests ran.

Build Log:
[...truncated 24176 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 2198 links (1753 relative) to 3011 anchors in 244 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

-dist-keys:
  [get] Getting: http://home.apache.org/keys/group/lucene.asc
  [get] To: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/solr/package/KEYS

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 = 

[jira] [Comment Edited] (LUCENE-7976) Make TieredMergePolicy respect maxSegmentSizeMB and allow singleton merges of very large segments

[David Smiley (JIRA)]

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

David Smiley edited comment on LUCENE-7976 at 4/19/18 4:17 AM:
---

{quote}On a relatively quick test, setting indexPctDeletedTarget to 20% causes 
about 10% more bytes to be written. Setting it to 10% causes 50% more bytes to 
be written. Setting it to 50% (which is kind of the default now) causes the 
number of bytes written to _drop_ by about 10%, but I consider that mostly 
noise.
{quote}
Just curious, how did you go about measuring that?  

FWIW I recently wrote a custom MergePolicy and along with it I wrote a fairly 
generic "MergePolicy simulator" that takes the MergePolicy and over many 
iterations feeds it dummy segments and as output records what merging it was 
told to do, then collect stats on all this like, critically, the "write 
amplification factor" (sum of all segments written / sum of new segments 
flushed).  It's able to do this extremely fast since no actual indexing/merging 
is done at all.  Maybe I should share it.  There's plenty more it could do to 
be improved; notably it doesn't have any deleted doc simulation.


was (Author: dsmiley):
{quote}On a relatively quick test, setting indexPctDeletedTarget to 20% causes 
about 10% more bytes to be written. Setting it to 10% causes 50% more bytes to 
be written. Setting it to 50% (which is kind of the default now) causes the 
number of bytes written to _drop_ by about 10%, but I consider that mostly 
noise.
{quote}
Just curious, how did you go about measuring that?  

FWIW I recently wrote a custom MergePolicy and along with it I wrote a fairly 
generic "MergePolicy simulator" that takes the MergePolicy and over many 
iterations feeds it dummy segments and as output records what merging it was 
told to do, then collect stats on all this.  The "write amplification factor" 
(sum of all segments written / sum of new segments flushed).  It's able to do 
this extremely fast since no actual indexing/merging is done at all.  Maybe I 
should share it.  There's plenty more it could do to be improved; notably it 
doesn't have any deleted doc simulation.

> Make TieredMergePolicy respect maxSegmentSizeMB and allow singleton merges of 
> very large segments
> -
>
> Key: LUCENE-7976
> URL: https://issues.apache.org/jira/browse/LUCENE-7976
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Major
> Attachments: LUCENE-7976.patch, LUCENE-7976.patch, LUCENE-7976.patch, 
> LUCENE-7976.patch
>
>
> We're seeing situations "in the wild" where there are very large indexes (on 
> disk) handled quite easily in a single Lucene index. This is particularly 
> true as features like docValues move data into MMapDirectory space. The 
> current TMP algorithm allows on the order of 50% deleted documents as per a 
> dev list conversation with Mike McCandless (and his blog here:  
> https://www.elastic.co/blog/lucenes-handling-of-deleted-documents).
> Especially in the current era of very large indexes in aggregate, (think many 
> TB) solutions like "you need to distribute your collection over more shards" 
> become very costly. Additionally, the tempting "optimize" button exacerbates 
> the issue since once you form, say, a 100G segment (by 
> optimizing/forceMerging) it is not eligible for merging until 97.5G of the 
> docs in it are deleted (current default 5G max segment size).
> The proposal here would be to add a new parameter to TMP, something like 
>  (no, that's not serious name, suggestions 
> welcome) which would default to 100 (or the same behavior we have now).
> So if I set this parameter to, say, 20%, and the max segment size stays at 
> 5G, the following would happen when segments were selected for merging:
> > any segment with > 20% deleted documents would be merged or rewritten NO 
> > MATTER HOW LARGE. There are two cases,
> >> the segment has < 5G "live" docs. In that case it would be merged with 
> >> smaller segments to bring the resulting segment up to 5G. If no smaller 
> >> segments exist, it would just be rewritten
> >> The segment has > 5G "live" docs (the result of a forceMerge or optimize). 
> >> It would be rewritten into a single segment removing all deleted docs no 
> >> matter how big it is to start. The 100G example above would be rewritten 
> >> to an 80G segment for instance.
> Of course this would lead to potentially much more I/O which is why the 
> default would be the same behavior we see now. As it stands now, though, 
> there's no way to recover from an optimize/forceMerge except to re-index from 
> scratch. We routinely see 200G-300G Lucene indexes at this point 

[jira] [Commented] (LUCENE-7976) Make TieredMergePolicy respect maxSegmentSizeMB and allow singleton merges of very large segments

[David Smiley (JIRA)]

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

David Smiley commented on LUCENE-7976:
--

{quote}On a relatively quick test, setting indexPctDeletedTarget to 20% causes 
about 10% more bytes to be written. Setting it to 10% causes 50% more bytes to 
be written. Setting it to 50% (which is kind of the default now) causes the 
number of bytes written to _drop_ by about 10%, but I consider that mostly 
noise.
{quote}
Just curious, how did you go about measuring that?  

FWIW I recently wrote a custom MergePolicy and along with it I wrote a fairly 
generic "MergePolicy simulator" that takes the MergePolicy and over many 
iterations feeds it dummy segments and as output records what merging it was 
told to do, then collect stats on all this.  The "write amplification factor" 
(sum of all segments written / sum of new segments flushed).  It's able to do 
this extremely fast since no actual indexing/merging is done at all.  Maybe I 
should share it.  There's plenty more it could do to be improved; notably it 
doesn't have any deleted doc simulation.

> Make TieredMergePolicy respect maxSegmentSizeMB and allow singleton merges of 
> very large segments
> -
>
> Key: LUCENE-7976
> URL: https://issues.apache.org/jira/browse/LUCENE-7976
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Major
> Attachments: LUCENE-7976.patch, LUCENE-7976.patch, LUCENE-7976.patch, 
> LUCENE-7976.patch
>
>
> We're seeing situations "in the wild" where there are very large indexes (on 
> disk) handled quite easily in a single Lucene index. This is particularly 
> true as features like docValues move data into MMapDirectory space. The 
> current TMP algorithm allows on the order of 50% deleted documents as per a 
> dev list conversation with Mike McCandless (and his blog here:  
> https://www.elastic.co/blog/lucenes-handling-of-deleted-documents).
> Especially in the current era of very large indexes in aggregate, (think many 
> TB) solutions like "you need to distribute your collection over more shards" 
> become very costly. Additionally, the tempting "optimize" button exacerbates 
> the issue since once you form, say, a 100G segment (by 
> optimizing/forceMerging) it is not eligible for merging until 97.5G of the 
> docs in it are deleted (current default 5G max segment size).
> The proposal here would be to add a new parameter to TMP, something like 
>  (no, that's not serious name, suggestions 
> welcome) which would default to 100 (or the same behavior we have now).
> So if I set this parameter to, say, 20%, and the max segment size stays at 
> 5G, the following would happen when segments were selected for merging:
> > any segment with > 20% deleted documents would be merged or rewritten NO 
> > MATTER HOW LARGE. There are two cases,
> >> the segment has < 5G "live" docs. In that case it would be merged with 
> >> smaller segments to bring the resulting segment up to 5G. If no smaller 
> >> segments exist, it would just be rewritten
> >> The segment has > 5G "live" docs (the result of a forceMerge or optimize). 
> >> It would be rewritten into a single segment removing all deleted docs no 
> >> matter how big it is to start. The 100G example above would be rewritten 
> >> to an 80G segment for instance.
> Of course this would lead to potentially much more I/O which is why the 
> default would be the same behavior we see now. As it stands now, though, 
> there's no way to recover from an optimize/forceMerge except to re-index from 
> scratch. We routinely see 200G-300G Lucene indexes at this point "in the 
> wild" with 10s of  shards replicated 3 or more times. And that doesn't even 
> include having these over HDFS.
> Alternatives welcome! Something like the above seems minimally invasive. A 
> new merge policy is certainly an alternative.



--
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-12142) EmbeddedSolrServer should use req.getContentWriter

[Noble Paul (JIRA)]

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

Noble Paul commented on SOLR-12142:
---

I'll reopen the ticket. You can post a patch with a testcase and I shall fix it

> EmbeddedSolrServer should use req.getContentWriter 
> ---
>
> Key: SOLR-12142
> URL: https://issues.apache.org/jira/browse/SOLR-12142
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: David Smiley
>Assignee: Noble Paul
>Priority: Major
> Fix For: 7.4
>
> Attachments: SOLR-12142.patch
>
>
> In SOLR-11380, SolrRequest.getContentWriter was introduced as a replacement 
> for getContentStreams.  However, EmbeddedSolrServer still calls 
> getContentStreams, and so clients who need to send POST data to it cannot yet 
> switch from the Deprecated API to the new API.  The SolrTextTagger is an 
> example of a project where one would want to do this.
> It seems EmbeddedSolrServer ought to check for getContentWriter and if 
> present then convert it into a ContentStream somehow.  For the time being, 
> ESS needs to call both since both APIs exist.
> CC [~noble.paul]



--
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-12142) EmbeddedSolrServer should use req.getContentWriter

[Noble Paul (JIRA)]

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

Noble Paul reopened SOLR-12142:
---

> EmbeddedSolrServer should use req.getContentWriter 
> ---
>
> Key: SOLR-12142
> URL: https://issues.apache.org/jira/browse/SOLR-12142
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: David Smiley
>Assignee: Noble Paul
>Priority: Major
> Fix For: 7.4
>
> Attachments: SOLR-12142.patch
>
>
> In SOLR-11380, SolrRequest.getContentWriter was introduced as a replacement 
> for getContentStreams.  However, EmbeddedSolrServer still calls 
> getContentStreams, and so clients who need to send POST data to it cannot yet 
> switch from the Deprecated API to the new API.  The SolrTextTagger is an 
> example of a project where one would want to do this.
> It seems EmbeddedSolrServer ought to check for getContentWriter and if 
> present then convert it into a ContentStream somehow.  For the time being, 
> ESS needs to call both since both APIs exist.
> CC [~noble.paul]



--
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-12233) QParserPlugin maintains a list of classes recreated every time a Solrcore object is created

[David Smiley (JIRA)]

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

David Smiley commented on SOLR-12233:
-

Sorry I didn't address your comments Shawn; I read them.  I've been working 
with Jeff and he's been measuring this stuff, and this issue right here was a 
huge chunk of time (as measured in profiling).  Sure maybe disabling some 
things altogether might help as well... but this is an unusual scenario to 
optimize for.  At least this issue seems pretty straight-forward & clean.  
Making some things disable-able might not be worth whatever 
maintenance/complexity in having that option; I don't know yet.  It seems like 
premature optimization right now.

BTW if I recall /update/csv etc. are actually still the Update request handler 
but simply have the content type auto-set to the appropriate mime-type.  
CSVRequestHandler doesn't exist anymore; instead those formats were moved to 
ContentStreamLoader subclasses. So this isn't a good example of excess weight 
to avoid.

> QParserPlugin maintains a list of classes recreated every time a Solrcore 
> object is created
> ---
>
> Key: SOLR-12233
> URL: https://issues.apache.org/jira/browse/SOLR-12233
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 7.1.1
>Reporter: Jeff Miller
>Assignee: Erick Erickson
>Priority: Minor
>  Labels: Performance, qparserplugin
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> QParserPlugin maintains a static map of Class Names to Class objects and 
> everytime we create a SolrCore object this causes a lot of overhead doing 
> classloader lookups.  Our system runs a lot of cores and the classloader gets 
> bogged down when a lot of threads are creating solrcore objects.  
> There's no need to create these objects every time, similar classes such as 
> TransformerFactory store the object one time and reference it over and over 
> again



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

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

[JENKINS] Lucene-Solr-master-Windows (64bit/jdk-10) - Build # 7274 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/7274/
Java: 64bit/jdk-10 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC

18 tests failed.
FAILED:  org.apache.solr.handler.TestReplicationHandler.doTestStressReplication

Error Message:
found:2[index.20180418164351380, index.20180418164352156, index.properties, 
replication.properties, snapshot_metadata]

Stack Trace:
java.lang.AssertionError: found:2[index.20180418164351380, 
index.20180418164352156, index.properties, replication.properties, 
snapshot_metadata]
at 
__randomizedtesting.SeedInfo.seed([DDFD6EA4455CD8D0:6566E624074B163]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.handler.TestReplicationHandler.checkForSingleIndex(TestReplicationHandler.java:968)
at 
org.apache.solr.handler.TestReplicationHandler.checkForSingleIndex(TestReplicationHandler.java:939)
at 
org.apache.solr.handler.TestReplicationHandler.doTestStressReplication(TestReplicationHandler.java:915)
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:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
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:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 

[jira] [Commented] (SOLR-12142) EmbeddedSolrServer should use req.getContentWriter

[David Smiley (JIRA)]

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

David Smiley commented on SOLR-12142:
-

I wasn't expecting this is in committable shape yet... I'll find out if this 
actually works over in the SolrTextTagger tests which has a test that posts 
plain text (not XML or JavaBin) to a custom RequestHandler.  That's what 
prompted this issue (and another).

https://github.com/OpenSextant/SolrTextTagger/blob/ab6951a1f77218f2b27ff00e9a13970fd70fffb3/src/test/java/org/opensextant/solrtexttagger/EmbeddedSolrNoSerializeTest.java#L106

BTW when I said "assuming BinaryRequestWriter().write is used? Then I guess 
don't use it."  I meant maybe then don't use this approach at all – no 
RequestWriter, no anonymous inner class of ContentStreamBase.

> EmbeddedSolrServer should use req.getContentWriter 
> ---
>
> Key: SOLR-12142
> URL: https://issues.apache.org/jira/browse/SOLR-12142
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: David Smiley
>Assignee: Noble Paul
>Priority: Major
> Fix For: 7.4
>
> Attachments: SOLR-12142.patch
>
>
> In SOLR-11380, SolrRequest.getContentWriter was introduced as a replacement 
> for getContentStreams.  However, EmbeddedSolrServer still calls 
> getContentStreams, and so clients who need to send POST data to it cannot yet 
> switch from the Deprecated API to the new API.  The SolrTextTagger is an 
> example of a project where one would want to do this.
> It seems EmbeddedSolrServer ought to check for getContentWriter and if 
> present then convert it into a ContentStream somehow.  For the time being, 
> ESS needs to call both since both APIs exist.
> CC [~noble.paul]



--
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-12142) EmbeddedSolrServer should use req.getContentWriter

[Noble Paul (JIRA)]

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

Noble Paul resolved SOLR-12142.
---
   Resolution: Fixed
Fix Version/s: 7.4

> EmbeddedSolrServer should use req.getContentWriter 
> ---
>
> Key: SOLR-12142
> URL: https://issues.apache.org/jira/browse/SOLR-12142
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: David Smiley
>Assignee: Noble Paul
>Priority: Major
> Fix For: 7.4
>
> Attachments: SOLR-12142.patch
>
>
> In SOLR-11380, SolrRequest.getContentWriter was introduced as a replacement 
> for getContentStreams.  However, EmbeddedSolrServer still calls 
> getContentStreams, and so clients who need to send POST data to it cannot yet 
> switch from the Deprecated API to the new API.  The SolrTextTagger is an 
> example of a project where one would want to do this.
> It seems EmbeddedSolrServer ought to check for getContentWriter and if 
> present then convert it into a ContentStream somehow.  For the time being, 
> ESS needs to call both since both APIs exist.
> CC [~noble.paul]



--
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-12142) EmbeddedSolrServer should use req.getContentWriter

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-12142:


Commit 9c8e527cd1b361e2f4ad8d4f71110142b411f0d8 in lucene-solr's branch 
refs/heads/branch_7x from noble
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=9c8e527 ]

SOLR-12142: EmbeddedSolrServer should use req.getContentWriter


> EmbeddedSolrServer should use req.getContentWriter 
> ---
>
> Key: SOLR-12142
> URL: https://issues.apache.org/jira/browse/SOLR-12142
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: David Smiley
>Assignee: Noble Paul
>Priority: Major
> Attachments: SOLR-12142.patch
>
>
> In SOLR-11380, SolrRequest.getContentWriter was introduced as a replacement 
> for getContentStreams.  However, EmbeddedSolrServer still calls 
> getContentStreams, and so clients who need to send POST data to it cannot yet 
> switch from the Deprecated API to the new API.  The SolrTextTagger is an 
> example of a project where one would want to do this.
> It seems EmbeddedSolrServer ought to check for getContentWriter and if 
> present then convert it into a ContentStream somehow.  For the time being, 
> ESS needs to call both since both APIs exist.
> CC [~noble.paul]



--
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-12142) EmbeddedSolrServer should use req.getContentWriter

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-12142:


Commit 1c8ab330d66557a289dd5398576726a43964c9e8 in lucene-solr's branch 
refs/heads/master from noble
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=1c8ab33 ]

SOLR-12142: EmbeddedSolrServer should use req.getContentWriter


> EmbeddedSolrServer should use req.getContentWriter 
> ---
>
> Key: SOLR-12142
> URL: https://issues.apache.org/jira/browse/SOLR-12142
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: David Smiley
>Assignee: Noble Paul
>Priority: Major
> Attachments: SOLR-12142.patch
>
>
> In SOLR-11380, SolrRequest.getContentWriter was introduced as a replacement 
> for getContentStreams.  However, EmbeddedSolrServer still calls 
> getContentStreams, and so clients who need to send POST data to it cannot yet 
> switch from the Deprecated API to the new API.  The SolrTextTagger is an 
> example of a project where one would want to do this.
> It seems EmbeddedSolrServer ought to check for getContentWriter and if 
> present then convert it into a ContentStream somehow.  For the time being, 
> ESS needs to call both since both APIs exist.
> CC [~noble.paul]



--
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+5) - Build # 21858 - Failure!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/21858/
Java: 64bit/jdk-11-ea+5 -XX:-UseCompressedOops -XX:+UseSerialGC

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

Error Message:
7 threads leaked from SUITE scope at 
org.apache.solr.cloud.ChaosMonkeyNothingIsSafeWithPullReplicasTest: 1) 
Thread[id=2678, name=zkCallback-658-thread-5, state=TIMED_WAITING, 
group=TGRP-ChaosMonkeyNothingIsSafeWithPullReplicasTest] at 
java.base@11-ea/jdk.internal.misc.Unsafe.park(Native Method) at 
java.base@11-ea/java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:234)
 at 
java.base@11-ea/java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:462)
 at 
java.base@11-ea/java.util.concurrent.SynchronousQueue$TransferStack.transfer(SynchronousQueue.java:361)
 at 
java.base@11-ea/java.util.concurrent.SynchronousQueue.poll(SynchronousQueue.java:937)
 at 
java.base@11-ea/java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1053)
 at 
java.base@11-ea/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1114)
 at 
java.base@11-ea/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
 at java.base@11-ea/java.lang.Thread.run(Thread.java:841)2) 
Thread[id=2360, 
name=TEST-ChaosMonkeyNothingIsSafeWithPullReplicasTest.test-seed#[23C7B0145EC71D10]-EventThread,
 state=WAITING, group=TGRP-ChaosMonkeyNothingIsSafeWithPullReplicasTest]
 at java.base@11-ea/jdk.internal.misc.Unsafe.park(Native Method) at 
java.base@11-ea/java.util.concurrent.locks.LockSupport.park(LockSupport.java:194)
 at 
java.base@11-ea/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2081)
 at 
java.base@11-ea/java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:433)
 at 
app//org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:502)3) 
Thread[id=2358, name=Connection evictor, state=TIMED_WAITING, 
group=TGRP-ChaosMonkeyNothingIsSafeWithPullReplicasTest] at 
java.base@11-ea/java.lang.Thread.sleep(Native Method) at 
app//org.apache.http.impl.client.IdleConnectionEvictor$1.run(IdleConnectionEvictor.java:66)
 at java.base@11-ea/java.lang.Thread.run(Thread.java:841)4) 
Thread[id=2664, name=zkCallback-658-thread-4, state=TIMED_WAITING, 
group=TGRP-ChaosMonkeyNothingIsSafeWithPullReplicasTest] at 
java.base@11-ea/jdk.internal.misc.Unsafe.park(Native Method) at 
java.base@11-ea/java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:234)
 at 
java.base@11-ea/java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:462)
 at 
java.base@11-ea/java.util.concurrent.SynchronousQueue$TransferStack.transfer(SynchronousQueue.java:361)
 at 
java.base@11-ea/java.util.concurrent.SynchronousQueue.poll(SynchronousQueue.java:937)
 at 
java.base@11-ea/java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1053)
 at 
java.base@11-ea/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1114)
 at 
java.base@11-ea/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
 at java.base@11-ea/java.lang.Thread.run(Thread.java:841)5) 
Thread[id=2359, 
name=TEST-ChaosMonkeyNothingIsSafeWithPullReplicasTest.test-seed#[23C7B0145EC71D10]-SendThread(127.0.0.1:34245),
 state=TIMED_WAITING, group=TGRP-ChaosMonkeyNothingIsSafeWithPullReplicasTest]  
   at java.base@11-ea/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)6) 
Thread[id=2679, name=zkCallback-658-thread-6, state=TIMED_WAITING, 
group=TGRP-ChaosMonkeyNothingIsSafeWithPullReplicasTest] at 
java.base@11-ea/jdk.internal.misc.Unsafe.park(Native Method) at 
java.base@11-ea/java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:234)
 at 
java.base@11-ea/java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:462)
 at 
java.base@11-ea/java.util.concurrent.SynchronousQueue$TransferStack.transfer(SynchronousQueue.java:361)
 at 
java.base@11-ea/java.util.concurrent.SynchronousQueue.poll(SynchronousQueue.java:937)
 at 
java.base@11-ea/java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1053)
 at 
java.base@11-ea/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1114)
 at 

[jira] [Commented] (LUCENE-7976) Make TieredMergePolicy respect maxSegmentSizeMB and allow singleton merges of very large segments

[Erick Erickson (JIRA)]

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

Erick Erickson commented on LUCENE-7976:


I'm much more optimisitc about this approach. What this approach does is 
extract the scoring loop from findMerges and call it from findMerges, 
findForcedDeletesMerges and findForcedMerges. 

Each of those methods creates a list of its peculiar version of eligible 
segments to merge and passes that (and some other info) to the extracted 
doFindMerges method.

So far it seems to work well.

Generally when it comes to large segments, here defined as anything over 
maxMergedSegmentBytes/2 live documents, they're ignoed unless the new parameter 
indexPctDeletedTarget is exceeded, which defaults to 20%. This means that if 
(and only if) the total number of deleted documents in the entire index is > 
20%, then segments with > maxMergedSegmentBytes/2 live docs are _eligible_ for 
merging. Whether they're merged or not depends on whether they are scored 
highest.

On a relatively quick test, setting indexPctDeletedTarget to 20% causes about 
10% more bytes to be written. Setting it to 10% causes 50% more bytes to be 
written. Setting it to 50% (which is kind of the default now) causes the number 
of bytes written to _drop_ by about 10%, but I consider that mostly noise.

forceMerge to 1 segment is possible, and continuing to index will gradually 
shrink that back as indexPctDeletedTarget gets exceeded as these large segments 
become eligible for merging.

So despite the size of the patch, the actual code differences are not nearly as 
great as it might seem. It's mostly moving some code around.

Comments welcome, I'm going to put this down for a few days. There are still a 
few nocommits and the like, but not many.

I do have one question: When should writer.numDeletesToMerge(info) be preferred 
over info.getDelCount()? The former seems more expensive.

Oh, and I haven't run precommit or test on it yet, just gathered stats on 
indexing to the new and old code.

> Make TieredMergePolicy respect maxSegmentSizeMB and allow singleton merges of 
> very large segments
> -
>
> Key: LUCENE-7976
> URL: https://issues.apache.org/jira/browse/LUCENE-7976
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Major
> Attachments: LUCENE-7976.patch, LUCENE-7976.patch, LUCENE-7976.patch, 
> LUCENE-7976.patch
>
>
> We're seeing situations "in the wild" where there are very large indexes (on 
> disk) handled quite easily in a single Lucene index. This is particularly 
> true as features like docValues move data into MMapDirectory space. The 
> current TMP algorithm allows on the order of 50% deleted documents as per a 
> dev list conversation with Mike McCandless (and his blog here:  
> https://www.elastic.co/blog/lucenes-handling-of-deleted-documents).
> Especially in the current era of very large indexes in aggregate, (think many 
> TB) solutions like "you need to distribute your collection over more shards" 
> become very costly. Additionally, the tempting "optimize" button exacerbates 
> the issue since once you form, say, a 100G segment (by 
> optimizing/forceMerging) it is not eligible for merging until 97.5G of the 
> docs in it are deleted (current default 5G max segment size).
> The proposal here would be to add a new parameter to TMP, something like 
>  (no, that's not serious name, suggestions 
> welcome) which would default to 100 (or the same behavior we have now).
> So if I set this parameter to, say, 20%, and the max segment size stays at 
> 5G, the following would happen when segments were selected for merging:
> > any segment with > 20% deleted documents would be merged or rewritten NO 
> > MATTER HOW LARGE. There are two cases,
> >> the segment has < 5G "live" docs. In that case it would be merged with 
> >> smaller segments to bring the resulting segment up to 5G. If no smaller 
> >> segments exist, it would just be rewritten
> >> The segment has > 5G "live" docs (the result of a forceMerge or optimize). 
> >> It would be rewritten into a single segment removing all deleted docs no 
> >> matter how big it is to start. The 100G example above would be rewritten 
> >> to an 80G segment for instance.
> Of course this would lead to potentially much more I/O which is why the 
> default would be the same behavior we see now. As it stands now, though, 
> there's no way to recover from an optimize/forceMerge except to re-index from 
> scratch. We routinely see 200G-300G Lucene indexes at this point "in the 
> wild" with 10s of  shards replicated 3 or more times. And that doesn't even 
> include having these over HDFS.
> Alternatives 

[jira] [Updated] (LUCENE-7976) Make TieredMergePolicy respect maxSegmentSizeMB and allow singleton merges of very large segments

[Erick Erickson (JIRA)]

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

Erick Erickson updated LUCENE-7976:
---
Attachment: LUCENE-7976.patch

> Make TieredMergePolicy respect maxSegmentSizeMB and allow singleton merges of 
> very large segments
> -
>
> Key: LUCENE-7976
> URL: https://issues.apache.org/jira/browse/LUCENE-7976
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Major
> Attachments: LUCENE-7976.patch, LUCENE-7976.patch, LUCENE-7976.patch, 
> LUCENE-7976.patch
>
>
> We're seeing situations "in the wild" where there are very large indexes (on 
> disk) handled quite easily in a single Lucene index. This is particularly 
> true as features like docValues move data into MMapDirectory space. The 
> current TMP algorithm allows on the order of 50% deleted documents as per a 
> dev list conversation with Mike McCandless (and his blog here:  
> https://www.elastic.co/blog/lucenes-handling-of-deleted-documents).
> Especially in the current era of very large indexes in aggregate, (think many 
> TB) solutions like "you need to distribute your collection over more shards" 
> become very costly. Additionally, the tempting "optimize" button exacerbates 
> the issue since once you form, say, a 100G segment (by 
> optimizing/forceMerging) it is not eligible for merging until 97.5G of the 
> docs in it are deleted (current default 5G max segment size).
> The proposal here would be to add a new parameter to TMP, something like 
>  (no, that's not serious name, suggestions 
> welcome) which would default to 100 (or the same behavior we have now).
> So if I set this parameter to, say, 20%, and the max segment size stays at 
> 5G, the following would happen when segments were selected for merging:
> > any segment with > 20% deleted documents would be merged or rewritten NO 
> > MATTER HOW LARGE. There are two cases,
> >> the segment has < 5G "live" docs. In that case it would be merged with 
> >> smaller segments to bring the resulting segment up to 5G. If no smaller 
> >> segments exist, it would just be rewritten
> >> The segment has > 5G "live" docs (the result of a forceMerge or optimize). 
> >> It would be rewritten into a single segment removing all deleted docs no 
> >> matter how big it is to start. The 100G example above would be rewritten 
> >> to an 80G segment for instance.
> Of course this would lead to potentially much more I/O which is why the 
> default would be the same behavior we see now. As it stands now, though, 
> there's no way to recover from an optimize/forceMerge except to re-index from 
> scratch. We routinely see 200G-300G Lucene indexes at this point "in the 
> wild" with 10s of  shards replicated 3 or more times. And that doesn't even 
> include having these over HDFS.
> Alternatives welcome! Something like the above seems minimally invasive. A 
> new merge policy is certainly an alternative.



--
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-12233) QParserPlugin maintains a list of classes recreated every time a Solrcore object is created

[Shawn Heisey (JIRA)]

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

Shawn Heisey commented on SOLR-12233:
-

Thanks for your analysis, [~dsmiley].  This issue has been an education!

What do you think of the idea of configuration to turn off implicit handlers? 
(needs a new issue)  For instance, I have no need for /update/csv, 
/update/json, or /update/json/docs.  I don't think the admin UI needs those 
handlers either.

Disabling some of the implicit handlers would make Solr start a little bit 
faster.  For my servers, with a couple dozen cores, the difference would be 
very small, but when there are thousands of cores, it could really add up.

I was thinking maybe we could create an umbrella issue for 
efficiency/scalability improvements outside of SolrCloud.  The issue I've just 
described, and this issue, could be children of the umbrella issue.

> QParserPlugin maintains a list of classes recreated every time a Solrcore 
> object is created
> ---
>
> Key: SOLR-12233
> URL: https://issues.apache.org/jira/browse/SOLR-12233
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 7.1.1
>Reporter: Jeff Miller
>Assignee: Erick Erickson
>Priority: Minor
>  Labels: Performance, qparserplugin
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> QParserPlugin maintains a static map of Class Names to Class objects and 
> everytime we create a SolrCore object this causes a lot of overhead doing 
> classloader lookups.  Our system runs a lot of cores and the classloader gets 
> bogged down when a lot of threads are creating solrcore objects.  
> There's no need to create these objects every time, similar classes such as 
> TransformerFactory store the object one time and reference it over and over 
> again



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

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

[JENKINS] Lucene-Solr-BadApples-Tests-7.x - Build # 43 - Still unstable

[Apache Jenkins Server]

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

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

Error Message:
The trigger did not fire at all

Stack Trace:
java.lang.AssertionError: The trigger did not fire at all
at 
__randomizedtesting.SeedInfo.seed([F4FDB65561595C5B:A9B5A8DCAE9FFA14]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.cloud.autoscaling.sim.TestTriggerIntegration.testSearchRate(TestTriggerIntegration.java:1199)
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:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
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:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
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.TestTriggerIntegration.testEventFromRestoredState

Error Message:
The trigger did not fire at all

Stack Trace:
java.lang.AssertionError: The trigger did not fire at all
at 
__randomizedtesting.SeedInfo.seed([F4FDB65561595C5B:F4CB02954854F831]:0)
at 

[jira] [Issue Comment Deleted] (SOLR-11191) Shard Split doesn't work on indexes that have nested documents

[Peng Xing (JIRA)]

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

Peng Xing updated SOLR-11191:
-
Comment: was deleted

(was: Hi [~varunthacker], I have met the same problem with you, after splitting 
the rested document shard, it will lost index data, maybe after splitting, the 
parent document has been send to shard1_0, the child document has been send to 
shard1_1, so the child document has not find its parent, then it will be 
invalid to be lost.
Have you found some method to avoid this problem? thanks!)

> Shard Split doesn't work on indexes that have nested documents
> --
>
> Key: SOLR-11191
> URL: https://issues.apache.org/jira/browse/SOLR-11191
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Varun Thacker
>Priority: Major
>
> The split shard command doesn't split a shard correctly when the index has 
> parent-child documents.
> The way split shard works is it goes through all documents id's in that shard 
> and then decides which sub-shard would it belong in . It is not aware of the 
> parent child relationship during this process
> So the parent-child documents could be orphaned and end up in different shard
> Secondly, even with the routing of parent and child documents were the same 
> split shards needs to re-index them as a block



--
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-12238) Synonym Query Style Boost By Payload

[Alessandro Benedetti (JIRA)]

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

Alessandro Benedetti commented on SOLR-12238:
-

[~softwaredoug] , [~dsmiley] and [~ehatcher] , when you have time it would be 
much appreciated if you let me know your view on this.
An initial patch with tests is attached.

Target of the functionality is to give users the ability to easy affect the 
synonym boost manually configuring the synonym.txt.
Being the patch at an initial stage I am happy to improve it and of course, 
feel free to motivate if you think it is not useful or handy for final users !

> Synonym Query Style Boost By Payload
> 
>
> Key: SOLR-12238
> URL: https://issues.apache.org/jira/browse/SOLR-12238
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: query parsers
>Reporter: Alessandro Benedetti
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> This improvement is built on top of the Synonym Query Style feature and 
> brings the possibility of boosting synonym queries using the payload 
> associated.
> It introduces two new modalities for the Synonym Query Style :
> PICK_BEST_BOOST_BY_PAYLOAD -> build a Disjunction query with the clauses 
> boosted by payload
> AS_DISTINCT_TERMS_BOOST_BY_PAYLOAD -> build a Boolean query with the clauses 
> boosted by payload
> This new synonym query styles will assume payloads are available so they must 
> be used in conjunction with a token filter able to produce payloads.
> An synonym.txt example could be :
> # Synonyms used by Payload Boost
> tiger => tiger|1.0, Big_Cat|0.8, Shere_Khan|0.9
> leopard => leopard, Big_Cat|0.8, Bagheera|0.9
> lion => lion|1.0, panthera leo|0.99, Simba|0.8
> snow_leopard => panthera uncia|0.99, snow leopard|1.0
> A simple token filter to populate the payloads from such synonym.txt is :
>  delimiter="|"/>



--
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 #357: [SOLR-12238] Synonym Queries boost by payload...

[alessandrobenedetti]

GitHub user alessandrobenedetti opened a pull request:

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

[SOLR-12238] Synonym Queries boost by payload 

This patch involves the synonym management in the query building/parser 
phase.
It adds the possibility of getting the payloads from a Graph Token Stream 
and then use the payload to build boost queries for terms and phrase queries.

Tests are included for a better understanding of the use cases.
This is an initial patch, happy to extend it or improve it !

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

$ git pull https://github.com/SeaseLtd/lucene-solr SOLR-12238

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

https://github.com/apache/lucene-solr/pull/357.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 #357


commit 74bbc02f71ec026eb4cee1c29dcad0bad1c664a6
Author: Alessandro Benedetti 
Date:   2018-04-19T01:38:13Z

[SOLR-12238] Synonym Queries boost by payload + tests

commit cacf48a162ffbe8af6c2a61d70ec580835b1f1fc
Author: Alessandro Benedetti 
Date:   2018-04-19T01:52:40Z

[SOLR-12238] query builder style revert




---

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

[JENKINS] Lucene-Solr-Tests-master - Build # 2494 - Still unstable

[Apache Jenkins Server]

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

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

Error Message:
action did not start

Stack Trace:
java.lang.AssertionError: action did not start
at 
__randomizedtesting.SeedInfo.seed([838C8AB42EF71B21:4A39C81A2790DDD4]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.cloud.autoscaling.sim.TestTriggerIntegration.testEventQueue(TestTriggerIntegration.java:641)
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:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
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:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:748)




Build Log:
[...truncated 14628 lines...]
   [junit4] Suite: org.apache.solr.cloud.autoscaling.sim.TestTriggerIntegration
   [junit4]   2> 3872273 INFO  
(SUITE-TestTriggerIntegration-seed#[838C8AB42EF71B21]-worker) [] 
o.a.s.SolrTestCaseJ4 SecureRandom sanity checks: 
test.solr.allowed.securerandom=null & 

[jira] [Created] (SOLR-12238) Synonym Query Style Boost By Payload

[Alessandro Benedetti (JIRA)]

Alessandro Benedetti created SOLR-12238:
---

 Summary: Synonym Query Style Boost By Payload
 Key: SOLR-12238
 URL: https://issues.apache.org/jira/browse/SOLR-12238
 Project: Solr
  Issue Type: Improvement
  Security Level: Public (Default Security Level. Issues are Public)
  Components: query parsers
Reporter: Alessandro Benedetti


This improvement is built on top of the Synonym Query Style feature and brings 
the possibility of boosting synonym queries using the payload associated.

It introduces two new modalities for the Synonym Query Style :



PICK_BEST_BOOST_BY_PAYLOAD -> build a Disjunction query with the clauses 
boosted by payload

AS_DISTINCT_TERMS_BOOST_BY_PAYLOAD -> build a Boolean query with the clauses 
boosted by payload

This new synonym query styles will assume payloads are available so they must 
be used in conjunction with a token filter able to produce payloads.

An synonym.txt example could be :

# Synonyms used by Payload Boost
tiger => tiger|1.0, Big_Cat|0.8, Shere_Khan|0.9
leopard => leopard, Big_Cat|0.8, Bagheera|0.9
lion => lion|1.0, panthera leo|0.99, Simba|0.8
snow_leopard => panthera uncia|0.99, snow leopard|1.0

A simple token filter to populate the payloads from such synonym.txt is :





--
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] [Assigned] (SOLR-12237) Fix incorrect SOLR_SSL_KEYSTORE_TYPE variable in solr start script

[Joel Bernstein (JIRA)]

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

Joel Bernstein reassigned SOLR-12237:
-

Assignee: Joel Bernstein

> Fix incorrect SOLR_SSL_KEYSTORE_TYPE variable in solr start script
> --
>
> Key: SOLR-12237
> URL: https://issues.apache.org/jira/browse/SOLR-12237
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 6.6, 6.6.1, 6.6.2, 6.6.3, 7.0, 7.1, 7.2
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
>Priority: Major
> Fix For: 7.4
>
>
> Currently the solr start script incorrectly has the variable 
> SOLR_SSL_KEYSTORE_TYPE.  The correct variable name is 
> SOLR_SSL_KEY_STORE_TYPE. Because of this mislabeled variable the key store 
> type is not set properly at startup.



--
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-12237) Fix incorrect SOLR_SSL_KEYSTORE_TYPE variable in solr start script

[Joel Bernstein (JIRA)]

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

Joel Bernstein updated SOLR-12237:
--
Affects Version/s: 6.6
   6.6.1
   6.6.2
   6.6.3
   7.0
   7.1
   7.2

> Fix incorrect SOLR_SSL_KEYSTORE_TYPE variable in solr start script
> --
>
> Key: SOLR-12237
> URL: https://issues.apache.org/jira/browse/SOLR-12237
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 6.6, 6.6.1, 6.6.2, 6.6.3, 7.0, 7.1, 7.2
>Reporter: Joel Bernstein
>Priority: Major
> Fix For: 7.4
>
>
> Currently the solr start script incorrectly has the variable 
> SOLR_SSL_KEYSTORE_TYPE.  The correct variable name is 
> SOLR_SSL_KEY_STORE_TYPE. Because of this mislabeled variable the key store 
> type is not set properly at startup.



--
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-12237) Fix incorrect SOLR_SSL_KEYSTORE_TYPE variable in solr start script

[Joel Bernstein (JIRA)]

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

Joel Bernstein updated SOLR-12237:
--
Fix Version/s: 7.4

> Fix incorrect SOLR_SSL_KEYSTORE_TYPE variable in solr start script
> --
>
> Key: SOLR-12237
> URL: https://issues.apache.org/jira/browse/SOLR-12237
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 6.6, 6.6.1, 6.6.2, 6.6.3, 7.0, 7.1, 7.2
>Reporter: Joel Bernstein
>Priority: Major
> Fix For: 7.4
>
>
> Currently the solr start script incorrectly has the variable 
> SOLR_SSL_KEYSTORE_TYPE.  The correct variable name is 
> SOLR_SSL_KEY_STORE_TYPE. Because of this mislabeled variable the key store 
> type is not set properly at startup.



--
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-12237) Fix incorrect SOLR_SSL_KEYSTORE_TYPE variable in solr start script

[Joel Bernstein (JIRA)]

Joel Bernstein created SOLR-12237:
-

 Summary: Fix incorrect SOLR_SSL_KEYSTORE_TYPE variable in solr 
start script
 Key: SOLR-12237
 URL: https://issues.apache.org/jira/browse/SOLR-12237
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Joel Bernstein


Currently the solr start script incorrectly has the variable 
SOLR_SSL_KEYSTORE_TYPE.  The correct variable name is SOLR_SSL_KEY_STORE_TYPE. 
Because of this mislabeled variable the key store type is not set properly at 
startup.



--
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-12233) QParserPlugin maintains a list of classes recreated every time a Solrcore object is created

[David Smiley (JIRA)]

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

David Smiley updated SOLR-12233:

Issue Type: Improvement  (was: Bug)

> QParserPlugin maintains a list of classes recreated every time a Solrcore 
> object is created
> ---
>
> Key: SOLR-12233
> URL: https://issues.apache.org/jira/browse/SOLR-12233
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 7.1.1
>Reporter: Jeff Miller
>Assignee: Erick Erickson
>Priority: Minor
>  Labels: Performance, qparserplugin
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> QParserPlugin maintains a static map of Class Names to Class objects and 
> everytime we create a SolrCore object this causes a lot of overhead doing 
> classloader lookups.  Our system runs a lot of cores and the classloader gets 
> bogged down when a lot of threads are creating solrcore objects.  
> There's no need to create these objects every time, similar classes such as 
> TransformerFactory store the object one time and reference it over and over 
> again



--
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-12233) QParserPlugin maintains a list of classes recreated every time a Solrcore object is created

[David Smiley (JIRA)]

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

David Smiley commented on SOLR-12233:
-

+1 to the PR.

I think it makes sense to define QParserPlugin.standardPlugins in a way 
consistent with built-in registries of some of Solr's other abstractions:
 * TransformerFactory: TransformerFactory.defaultFactories
 * QueryResponseWriter: SolrCore.DEFAULT_RESPONSE_WRITERS
 * ValueSourceParser: ValueSourceParser.standardValueSourceParsers

That said, some are using the name to Class:
 * SearchComponent: SearchComponent.standard_components

One important factor to consider is SolrCoreAware.  None of the built-in 
QParserPlugins, TransformerFactories, or QueryResponseWriters implement 
SolrCoreAware, and so it's safe to have a global/static Map to an actual 
_instance_ of these built-in classes instead of holding the Class.  It wouldn't 
even make sense for the built-in or perhaps any QParserPlugin or 
TransformerFactory to be SolrCoreAware since these are both factories that have 
a method that take the SolrQueryRequest which provide access to everything.  
Similarly ValueSourceParser.parse provides access, albeit indirectly, to the 
SolrCore.

 

> QParserPlugin maintains a list of classes recreated every time a Solrcore 
> object is created
> ---
>
> Key: SOLR-12233
> URL: https://issues.apache.org/jira/browse/SOLR-12233
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 7.1.1
>Reporter: Jeff Miller
>Assignee: Erick Erickson
>Priority: Minor
>  Labels: Performance, qparserplugin
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> QParserPlugin maintains a static map of Class Names to Class objects and 
> everytime we create a SolrCore object this causes a lot of overhead doing 
> classloader lookups.  Our system runs a lot of cores and the classloader gets 
> bogged down when a lot of threads are creating solrcore objects.  
> There's no need to create these objects every time, similar classes such as 
> TransformerFactory store the object one time and reference it over and over 
> again



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

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

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

[Policeman Jenkins Server]

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

2 tests failed.
FAILED:  
org.apache.solr.cloud.autoscaling.IndexSizeTriggerTest.testMergeIntegration

Error Message:
did not finish processing in time

Stack Trace:
java.lang.AssertionError: did not finish processing in time
at 
__randomizedtesting.SeedInfo.seed([372E23A5817809FD:6497611563699C07]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.cloud.autoscaling.IndexSizeTriggerTest.testMergeIntegration(IndexSizeTriggerTest.java:404)
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:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
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:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
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)


FAILED:  
org.apache.solr.cloud.autoscaling.IndexSizeTriggerTest.testSplitIntegration

Error Message:


Stack Trace:
java.util.concurrent.TimeoutException
at 
__randomizedtesting.SeedInfo.seed([372E23A5817809FD:EA09AE5AE87C003]:0)
at 

[JENKINS] Lucene-Solr-repro - Build # 525 - Failure

[Apache Jenkins Server]

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

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

[repro] Revision: 1d2441441be5f5d87103ceeec6d852f8f2f6ba85

[repro] Repro line:  ant test  -Dtestcase=IndexSizeTriggerTest 
-Dtests.method=testTrigger -Dtests.seed=259D82F7F3B1E935 -Dtests.multiplier=2 
-Dtests.slow=true -Dtests.locale=th-TH -Dtests.timezone=America/Araguaina 
-Dtests.asserts=true -Dtests.file.encoding=US-ASCII

[repro] Encountered IncompleteRead exception, pausing and then retrying...
[repro] Jenkins log URL: 
https://builds.apache.org/job/Lucene-Solr-Tests-master/2493/consoleText

[repro] Revision: 1d2441441be5f5d87103ceeec6d852f8f2f6ba85

[repro] Repro line:  ant test  -Dtestcase=IndexSizeTriggerTest 
-Dtests.method=testTrigger -Dtests.seed=259D82F7F3B1E935 -Dtests.multiplier=2 
-Dtests.slow=true -Dtests.locale=th-TH -Dtests.timezone=America/Araguaina 
-Dtests.asserts=true -Dtests.file.encoding=US-ASCII

[repro] Encountered IncompleteRead exception, pausing and then retrying...
[repro] Jenkins log URL: 
https://builds.apache.org/job/Lucene-Solr-Tests-master/2493/consoleText

[repro] Revision: 1d2441441be5f5d87103ceeec6d852f8f2f6ba85

[repro] Repro line:  ant test  -Dtestcase=IndexSizeTriggerTest 
-Dtests.method=testTrigger -Dtests.seed=259D82F7F3B1E935 -Dtests.multiplier=2 
-Dtests.slow=true -Dtests.locale=th-TH -Dtests.timezone=America/Araguaina 
-Dtests.asserts=true -Dtests.file.encoding=US-ASCII

[repro] Encountered IncompleteRead exception, aborting after too many retries.

[...truncated 64 lines...]
raise RuntimeError('ERROR: fetching %s : %s' % (url, e))
RuntimeError: ERROR: fetching 
https://builds.apache.org/job/Lucene-Solr-Tests-master/2493/consoleText : 
IncompleteRead(0 bytes read)
Build step 'Execute shell' 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

Can't find resource 'currency.xml' in classpath | currencyFieldType

[Ravi Verma]

Hello Team,

I am facing an issue on solr search version 7.x. I want to create a
currencyFIeldType in my managed-schema file. In order to do that I created
the following entries :

 *  *


**
**

When I restart solr every time I get this exception :

* at
org.apache.solr.schema.ManagedIndexSchemaFactory.create(ManagedIndexSchemaFactory.java:173)*
* at
org.apache.solr.schema.ManagedIndexSchemaFactory.create(ManagedIndexSchemaFactory.java:45)*
* at
org.apache.solr.schema.IndexSchemaFactory.buildIndexSchema(IndexSchemaFactory.java:75)*
* at
org.apache.solr.core.ConfigSetService.createIndexSchema(ConfigSetService.java:119)*
* at
org.apache.solr.core.ConfigSetService.getConfig(ConfigSetService.java:92)*
* ... 11 more*
*Caused by: org.apache.solr.core.SolrResourceNotFoundException: Can't find
resource 'currency.xml' in classpath or
'/home/ravi/Desktop/solr/solr-7.2.1/server/solr/192.168.9.154
'*
* at
org.apache.solr.core.SolrResourceLoader.openResource(SolrResourceLoader.java:407)*
* at
org.apache.solr.schema.FileExchangeRateProvider.reload(FileExchangeRateProvider.java:167)*
* ... 21 more*

Please help me on this asap, I have a project pending at my end.

Thanks & Regards
Ravi Verma

[jira] [Resolved] (SOLR-12204) Upgrade commons-fileupload to address CVE-2016-1000031

[Steve Rowe (JIRA)]

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

Steve Rowe resolved SOLR-12204.
---
   Resolution: Fixed
 Assignee: Steve Rowe  (was: Hrishikesh Gadre)
Fix Version/s: master (8.0)
   7.4
   7.3.1

> Upgrade commons-fileupload to address CVE-2016-131
> --
>
> Key: SOLR-12204
> URL: https://issues.apache.org/jira/browse/SOLR-12204
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 7.2
>Reporter: Hrishikesh Gadre
>Assignee: Steve Rowe
>Priority: Major
> Fix For: 7.3.1, 7.4, master (8.0)
>
> Attachments: SOLR-12204.patch, SOLR-12204.patch
>
>
> Currently SOLR is using 1.3.2 version of commons-fileupload library which is 
> susceptible to  CVE-2016-131. We should upgrade the this library to the 
> latest version (1.3.3 at the time of writing) to mitigate the security risk.



--
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-12204) Upgrade commons-fileupload to address CVE-2016-1000031

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-12204:


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

SOLR-12204: Upgrade commons-fileupload dependency to 1.3.3 to address 
CVE-2016-131


> Upgrade commons-fileupload to address CVE-2016-131
> --
>
> Key: SOLR-12204
> URL: https://issues.apache.org/jira/browse/SOLR-12204
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 7.2
>Reporter: Hrishikesh Gadre
>Assignee: Hrishikesh Gadre
>Priority: Major
> Attachments: SOLR-12204.patch, SOLR-12204.patch
>
>
> Currently SOLR is using 1.3.2 version of commons-fileupload library which is 
> susceptible to  CVE-2016-131. We should upgrade the this library to the 
> latest version (1.3.3 at the time of writing) to mitigate the security risk.



--
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-12204) Upgrade commons-fileupload to address CVE-2016-1000031

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-12204:


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

SOLR-12204: Upgrade commons-fileupload dependency to 1.3.3 to address 
CVE-2016-131


> Upgrade commons-fileupload to address CVE-2016-131
> --
>
> Key: SOLR-12204
> URL: https://issues.apache.org/jira/browse/SOLR-12204
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 7.2
>Reporter: Hrishikesh Gadre
>Assignee: Hrishikesh Gadre
>Priority: Major
> Attachments: SOLR-12204.patch, SOLR-12204.patch
>
>
> Currently SOLR is using 1.3.2 version of commons-fileupload library which is 
> susceptible to  CVE-2016-131. We should upgrade the this library to the 
> latest version (1.3.3 at the time of writing) to mitigate the security risk.



--
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-12204) Upgrade commons-fileupload to address CVE-2016-1000031

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-12204:


Commit 36241416fdba2d6835631bfdb1d6222ba3c165be 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=3624141 ]

SOLR-12204: Upgrade commons-fileupload dependency to 1.3.3 to address 
CVE-2016-131


> Upgrade commons-fileupload to address CVE-2016-131
> --
>
> Key: SOLR-12204
> URL: https://issues.apache.org/jira/browse/SOLR-12204
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 7.2
>Reporter: Hrishikesh Gadre
>Assignee: Hrishikesh Gadre
>Priority: Major
> Attachments: SOLR-12204.patch, SOLR-12204.patch
>
>
> Currently SOLR is using 1.3.2 version of commons-fileupload library which is 
> susceptible to  CVE-2016-131. We should upgrade the this library to the 
> latest version (1.3.3 at the time of writing) to mitigate the security risk.



--
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-12204) Upgrade commons-fileupload to address CVE-2016-1000031

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-12204:


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

SOLR-12204: CHANGES.txt: remove extra 7.3.1 release header


> Upgrade commons-fileupload to address CVE-2016-131
> --
>
> Key: SOLR-12204
> URL: https://issues.apache.org/jira/browse/SOLR-12204
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 7.2
>Reporter: Hrishikesh Gadre
>Assignee: Hrishikesh Gadre
>Priority: Major
> Attachments: SOLR-12204.patch, SOLR-12204.patch
>
>
> Currently SOLR is using 1.3.2 version of commons-fileupload library which is 
> susceptible to  CVE-2016-131. We should upgrade the this library to the 
> latest version (1.3.3 at the time of writing) to mitigate the security risk.



--
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-12204) Upgrade commons-fileupload to address CVE-2016-1000031

[Steve Rowe (JIRA)]

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

Steve Rowe commented on SOLR-12204:
---

Updated patch: I moved the CHANGES entry to a new 7.3.1 release section.  
Committing shortly.

> Upgrade commons-fileupload to address CVE-2016-131
> --
>
> Key: SOLR-12204
> URL: https://issues.apache.org/jira/browse/SOLR-12204
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 7.2
>Reporter: Hrishikesh Gadre
>Assignee: Hrishikesh Gadre
>Priority: Major
> Attachments: SOLR-12204.patch, SOLR-12204.patch
>
>
> Currently SOLR is using 1.3.2 version of commons-fileupload library which is 
> susceptible to  CVE-2016-131. We should upgrade the this library to the 
> latest version (1.3.3 at the time of writing) to mitigate the security risk.



--
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-12204) Upgrade commons-fileupload to address CVE-2016-1000031

[Steve Rowe (JIRA)]

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

Steve Rowe updated SOLR-12204:
--
Attachment: SOLR-12204.patch

> Upgrade commons-fileupload to address CVE-2016-131
> --
>
> Key: SOLR-12204
> URL: https://issues.apache.org/jira/browse/SOLR-12204
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 7.2
>Reporter: Hrishikesh Gadre
>Assignee: Hrishikesh Gadre
>Priority: Major
> Attachments: SOLR-12204.patch, SOLR-12204.patch
>
>
> Currently SOLR is using 1.3.2 version of commons-fileupload library which is 
> susceptible to  CVE-2016-131. We should upgrade the this library to the 
> latest version (1.3.3 at the time of writing) to mitigate the security risk.



--
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-12204) Upgrade commons-fileupload to address CVE-2016-1000031

[Steve Rowe (JIRA)]

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

Steve Rowe commented on SOLR-12204:
---

I attached a patch to upgrade the jar.  All tests and precommit pass.

> Upgrade commons-fileupload to address CVE-2016-131
> --
>
> Key: SOLR-12204
> URL: https://issues.apache.org/jira/browse/SOLR-12204
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 7.2
>Reporter: Hrishikesh Gadre
>Assignee: Hrishikesh Gadre
>Priority: Major
> Attachments: SOLR-12204.patch, SOLR-12204.patch
>
>
> Currently SOLR is using 1.3.2 version of commons-fileupload library which is 
> susceptible to  CVE-2016-131. We should upgrade the this library to the 
> latest version (1.3.3 at the time of writing) to mitigate the security risk.



--
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-12204) Upgrade commons-fileupload to address CVE-2016-1000031

[Steve Rowe (JIRA)]

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

Steve Rowe updated SOLR-12204:
--
Attachment: SOLR-12204.patch

> Upgrade commons-fileupload to address CVE-2016-131
> --
>
> Key: SOLR-12204
> URL: https://issues.apache.org/jira/browse/SOLR-12204
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 7.2
>Reporter: Hrishikesh Gadre
>Assignee: Hrishikesh Gadre
>Priority: Major
> Attachments: SOLR-12204.patch
>
>
> Currently SOLR is using 1.3.2 version of commons-fileupload library which is 
> susceptible to  CVE-2016-131. We should upgrade the this library to the 
> latest version (1.3.3 at the time of writing) to mitigate the security risk.



--
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-11718) Deprecate CDCR Buffer APIs

[Lucene/Solr QA (JIRA)]

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

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

| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green}  0m 
 0s{color} | {color:green} The patch appears to include 2 new or modified test 
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  1m 
38s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  1m 
36s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green}  1m 
36s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Release audit (RAT) {color} | 
{color:green}  1m 41s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Check forbidden APIs {color} | 
{color:green}  1m 36s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Validate source patterns {color} | 
{color:green}  1m 36s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Validate ref guide {color} | 
{color:green}  1m 36s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 55m 21s{color} 
| {color:red} core in the patch failed. {color} |
| {color:black}{color} | {color:black} {color} | {color:black} 62m 14s{color} | 
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | solr.cloud.autoscaling.AutoScalingHandlerTest |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | SOLR-11718 |
| JIRA Patch URL | 
https://issues.apache.org/jira/secure/attachment/12919567/SOLR-11718.patch |
| Optional Tests |  compile  javac  unit  ratsources  checkforbiddenapis  
validatesourcepatterns  validaterefguide  |
| uname | Linux lucene1-us-west 3.13.0-88-generic #135-Ubuntu SMP Wed Jun 8 
21:10:42 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | ant |
| Personality | 
/home/jenkins/jenkins-slave/workspace/PreCommit-SOLR-Build/sourcedir/dev-tools/test-patch/lucene-solr-yetus-personality.sh
 |
| git revision | master / 29cbd03 |
| ant | version: Apache Ant(TM) version 1.9.3 compiled on April 8 2014 |
| Default Java | 1.8.0_152 |
| unit | 
https://builds.apache.org/job/PreCommit-SOLR-Build/61/artifact/out/patch-unit-solr_core.txt
 |
|  Test Results | 
https://builds.apache.org/job/PreCommit-SOLR-Build/61/testReport/ |
| modules | C: solr/core solr/solr-ref-guide U: solr |
| Console output | 
https://builds.apache.org/job/PreCommit-SOLR-Build/61/console |
| Powered by | Apache Yetus 0.7.0   http://yetus.apache.org |


This message was automatically generated.



> Deprecate CDCR Buffer APIs
> --
>
> Key: SOLR-11718
> URL: https://issues.apache.org/jira/browse/SOLR-11718
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: CDCR
>Reporter: Amrit Sarkar
>Assignee: Varun Thacker
>Priority: Major
> Fix For: 7.4, master (8.0)
>
> Attachments: SOLR-11718.patch, SOLR-11718.patch
>
>
> Kindly see the discussion on SOLR-11652.
> Today, if we see the current CDCR documentation page, buffering is "disabled" 
> by default in both source and target. We don't see any purpose served by Cdcr 
> buffering and it is quite an overhead considering it can take a lot heap 
> space (tlogs ptr) and forever retention of tlogs on the disk when enabled. 
> Also today, even if we disable buffer from API on source , considering it was 
> enabled at startup, tlogs are never purged on leader node of shards of 
> source, refer jira: SOLR-11652



--
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: Marketing ApacheCon on Solr home page

[Jan Høydahl]

+1 for a banner.

Here is the edit instructions: https://lucene.apache.org/site-instructions.html 
 :)
The webpage is in svn but it is easier to do a small edit through CMS 
bookmarklet.

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

> 18. apr. 2018 kl. 21:25 skrev Alexandre Rafalovitch :
> 
> Hi,
> 
> On the Apache Community mailing list, they are asking the projects to
> include an - auto-updated - Apache "ad" block for the ApacheCon.
> 
> I had a look at the Solr home page and I think it would fit right at
> the end, under the "Apache Software Foundation" block
> https://lucene.apache.org/solr/
> 
> They offer two sizes, I think the wider one looks nicer:
> https://www.apache.org/events/current-event-234x60.png
> 
> The full instructions are at: https://apache.org/events/README.txt .
> Seems easy enough. But I am not even sure who/how the Solr site is now
> updated. Is that in Git somewhere as well?
> 
> Regards,
>   Alex.
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
> 

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

[Apache Jenkins Server]

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

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

[repro] Revision: 1d2441441be5f5d87103ceeec6d852f8f2f6ba85

[repro] Repro line:  ant test  -Dtestcase=IndexSizeTriggerTest 
-Dtests.method=testTrigger -Dtests.seed=7B8FBCAAC3B8A4E -Dtests.multiplier=2 
-Dtests.slow=true -Dtests.badapples=true -Dtests.locale=bg-BG 
-Dtests.timezone=Etc/Greenwich -Dtests.asserts=true 
-Dtests.file.encoding=US-ASCII

[repro] Repro line:  ant test  -Dtestcase=TestUnInvertedFieldException 
-Dtests.seed=7B8FBCAAC3B8A4E -Dtests.multiplier=2 -Dtests.slow=true 
-Dtests.badapples=true -Dtests.locale=ar-SY -Dtests.timezone=America/Iqaluit 
-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: 
29cbd031c9431a060c7747a95f16d87a851b2d09
[repro] git fetch

[...truncated 2 lines...]
[repro] git checkout 1d2441441be5f5d87103ceeec6d852f8f2f6ba85

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

[...truncated 3298 lines...]
[repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=10 
-Dtests.class="*.TestUnInvertedFieldException|*.IndexSizeTriggerTest" 
-Dtests.showOutput=onerror  -Dtests.seed=7B8FBCAAC3B8A4E -Dtests.multiplier=2 
-Dtests.slow=true -Dtests.badapples=true -Dtests.locale=ar-SY 
-Dtests.timezone=America/Iqaluit -Dtests.asserts=true 
-Dtests.file.encoding=US-ASCII

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

[repro] Failures:
[repro]   0/5 failed: org.apache.solr.request.TestUnInvertedFieldException
[repro]   5/5 failed: org.apache.solr.cloud.autoscaling.IndexSizeTriggerTest

[repro] Re-testing 100% failures at the tip of master
[repro] ant clean

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

[...truncated 3298 lines...]
[repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=5 
-Dtests.class="*.IndexSizeTriggerTest" -Dtests.showOutput=onerror  
-Dtests.seed=7B8FBCAAC3B8A4E -Dtests.multiplier=2 -Dtests.slow=true 
-Dtests.badapples=true -Dtests.locale=bg-BG -Dtests.timezone=Etc/Greenwich 
-Dtests.asserts=true -Dtests.file.encoding=US-ASCII

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

[repro] Failures at the tip of master:
[repro]   2/5 failed: org.apache.solr.cloud.autoscaling.IndexSizeTriggerTest
[repro] git checkout 29cbd031c9431a060c7747a95f16d87a851b2d09

[...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 # 1534 - Failure

[Apache Jenkins Server]

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

6 tests failed.
FAILED:  org.apache.lucene.search.TestInetAddressRangeQueries.testRandomBig

Error Message:
CheckIndex failed

Stack Trace:
java.lang.RuntimeException: CheckIndex failed
at 
__randomizedtesting.SeedInfo.seed([DFB9317353BCF3DC:58EE4CFCC2E58F5C]:0)
at org.apache.lucene.util.TestUtil.checkIndex(TestUtil.java:305)
at org.apache.lucene.util.TestUtil.checkIndex(TestUtil.java:285)
at 
org.apache.lucene.store.BaseDirectoryWrapper.close(BaseDirectoryWrapper.java:45)
at org.apache.lucene.util.IOUtils.close(IOUtils.java:88)
at org.apache.lucene.util.IOUtils.close(IOUtils.java:76)
at 
org.apache.lucene.search.BaseRangeFieldQueryTestCase.verify(BaseRangeFieldQueryTestCase.java:293)
at 
org.apache.lucene.search.BaseRangeFieldQueryTestCase.doTestRandom(BaseRangeFieldQueryTestCase.java:160)
at 
org.apache.lucene.search.BaseRangeFieldQueryTestCase.testRandomBig(BaseRangeFieldQueryTestCase.java:75)
at 
org.apache.lucene.search.TestInetAddressRangeQueries.testRandomBig(TestInetAddressRangeQueries.java:81)
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:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
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:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
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.FullSolrCloudDistribCmdsTest.test

Error Message:
Test abandoned because suite 

[jira] [Commented] (SOLR-12236) Admin UI logging page: "Core" column never gets populated

[Shawn Heisey (JIRA)]

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

Shawn Heisey commented on SOLR-12236:
-

Now I can't even reproduce the problem on branch_7x with a clean checkout.  
This is confusing, because I was seeing the problem just a little while ago!  
(the core name does have the x: with 7x as well)

> Admin UI logging page: "Core" column never gets populated
> -
>
> Key: SOLR-12236
> URL: https://issues.apache.org/jira/browse/SOLR-12236
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Admin UI, logging
>Affects Versions: 6.6.3, 7.3
>Reporter: Shawn Heisey
>Priority: Major
> Attachments: SOLR-12236.patch, SOLR-12236.patch
>
>
> The logging page in the admin UI has a "Core" column, but there is never 
> anything in that column.  I fired up the techproducts example, then used the 
> Documents tab to try to index a document missing the "id" field, and got this 
> error in the logfile:
> ERROR - 2018-04-18 18:51:31.232; [   x:techproducts] 
> org.apache.solr.common.SolrException; org.apache.solr.common.SolrException: 
> Document is missing mandatory uniqueKey field: id
> The core name (techproducts) is in the logfile as seen above, but when 
> looking at the logging page in the UI, it can't be found anywhere.
> This is the case in both master and branch_7x.  I also tried it on the 6.6.3 
> version (binary package) with the same results.  On version 5.3.2-SNAPSHOT, 
> the Core column says "null" for all logs, instead of being blank.  That 
> column does not appear to be present in 4.x versions.



--
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-12236) Admin UI logging page: "Core" column never gets populated

[Shawn Heisey (JIRA)]

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

Shawn Heisey commented on SOLR-12236:
-

Attached updated patch for master.  Will look at 7x now.

> Admin UI logging page: "Core" column never gets populated
> -
>
> Key: SOLR-12236
> URL: https://issues.apache.org/jira/browse/SOLR-12236
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Admin UI, logging
>Affects Versions: 6.6.3, 7.3
>Reporter: Shawn Heisey
>Priority: Major
> Attachments: SOLR-12236.patch, SOLR-12236.patch
>
>
> The logging page in the admin UI has a "Core" column, but there is never 
> anything in that column.  I fired up the techproducts example, then used the 
> Documents tab to try to index a document missing the "id" field, and got this 
> error in the logfile:
> ERROR - 2018-04-18 18:51:31.232; [   x:techproducts] 
> org.apache.solr.common.SolrException; org.apache.solr.common.SolrException: 
> Document is missing mandatory uniqueKey field: id
> The core name (techproducts) is in the logfile as seen above, but when 
> looking at the logging page in the UI, it can't be found anywhere.
> This is the case in both master and branch_7x.  I also tried it on the 6.6.3 
> version (binary package) with the same results.  On version 5.3.2-SNAPSHOT, 
> the Core column says "null" for all logs, instead of being blank.  That 
> column does not appear to be present in 4.x versions.



--
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-12236) Admin UI logging page: "Core" column never gets populated

[Shawn Heisey (JIRA)]

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

Shawn Heisey updated SOLR-12236:

Attachment: SOLR-12236.patch

> Admin UI logging page: "Core" column never gets populated
> -
>
> Key: SOLR-12236
> URL: https://issues.apache.org/jira/browse/SOLR-12236
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Admin UI, logging
>Affects Versions: 6.6.3, 7.3
>Reporter: Shawn Heisey
>Priority: Major
> Attachments: SOLR-12236.patch, SOLR-12236.patch
>
>
> The logging page in the admin UI has a "Core" column, but there is never 
> anything in that column.  I fired up the techproducts example, then used the 
> Documents tab to try to index a document missing the "id" field, and got this 
> error in the logfile:
> ERROR - 2018-04-18 18:51:31.232; [   x:techproducts] 
> org.apache.solr.common.SolrException; org.apache.solr.common.SolrException: 
> Document is missing mandatory uniqueKey field: id
> The core name (techproducts) is in the logfile as seen above, but when 
> looking at the logging page in the UI, it can't be found anywhere.
> This is the case in both master and branch_7x.  I also tried it on the 6.6.3 
> version (binary package) with the same results.  On version 5.3.2-SNAPSHOT, 
> the Core column says "null" for all logs, instead of being blank.  That 
> column does not appear to be present in 4.x versions.



--
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-12236) Admin UI logging page: "Core" column never gets populated

[Shawn Heisey (JIRA)]

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

Shawn Heisey commented on SOLR-12236:
-

It appears that I was wrong about the Core column being empty on master.  It 
shows up as "x:techproducts" on master if the code is unmodified.  But it is 
empty on branch_7x.  So there is no bug in LogEvent, but we might have a code 
problem in 7x.  And the string does need to have the "x:" stripped out.



> Admin UI logging page: "Core" column never gets populated
> -
>
> Key: SOLR-12236
> URL: https://issues.apache.org/jira/browse/SOLR-12236
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Admin UI, logging
>Affects Versions: 6.6.3, 7.3
>Reporter: Shawn Heisey
>Priority: Major
> Attachments: SOLR-12236.patch
>
>
> The logging page in the admin UI has a "Core" column, but there is never 
> anything in that column.  I fired up the techproducts example, then used the 
> Documents tab to try to index a document missing the "id" field, and got this 
> error in the logfile:
> ERROR - 2018-04-18 18:51:31.232; [   x:techproducts] 
> org.apache.solr.common.SolrException; org.apache.solr.common.SolrException: 
> Document is missing mandatory uniqueKey field: id
> The core name (techproducts) is in the logfile as seen above, but when 
> looking at the logging page in the UI, it can't be found anywhere.
> This is the case in both master and branch_7x.  I also tried it on the 6.6.3 
> version (binary package) with the same results.  On version 5.3.2-SNAPSHOT, 
> the Core column says "null" for all logs, instead of being blank.  That 
> column does not appear to be present in 4.x versions.



--
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-12236) Admin UI logging page: "Core" column never gets populated

[Shawn Heisey (JIRA)]

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

Shawn Heisey commented on SOLR-12236:
-

Attached a patch against master that appears to fix the problem.

We were using a deprecated method in the log4j2 "LogEvent" class.  Switching to 
the recommended replacement appears to be all that was needed to fix it.  This 
might be a bug in LogEvent.  I am verifying this.


> Admin UI logging page: "Core" column never gets populated
> -
>
> Key: SOLR-12236
> URL: https://issues.apache.org/jira/browse/SOLR-12236
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Admin UI, logging
>Affects Versions: 6.6.3, 7.3
>Reporter: Shawn Heisey
>Priority: Major
> Attachments: SOLR-12236.patch
>
>
> The logging page in the admin UI has a "Core" column, but there is never 
> anything in that column.  I fired up the techproducts example, then used the 
> Documents tab to try to index a document missing the "id" field, and got this 
> error in the logfile:
> ERROR - 2018-04-18 18:51:31.232; [   x:techproducts] 
> org.apache.solr.common.SolrException; org.apache.solr.common.SolrException: 
> Document is missing mandatory uniqueKey field: id
> The core name (techproducts) is in the logfile as seen above, but when 
> looking at the logging page in the UI, it can't be found anywhere.
> This is the case in both master and branch_7x.  I also tried it on the 6.6.3 
> version (binary package) with the same results.  On version 5.3.2-SNAPSHOT, 
> the Core column says "null" for all logs, instead of being blank.  That 
> column does not appear to be present in 4.x versions.



--
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-12236) Admin UI logging page: "Core" column never gets populated

[Shawn Heisey (JIRA)]

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

Shawn Heisey updated SOLR-12236:

Attachment: SOLR-12236.patch

> Admin UI logging page: "Core" column never gets populated
> -
>
> Key: SOLR-12236
> URL: https://issues.apache.org/jira/browse/SOLR-12236
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Admin UI, logging
>Affects Versions: 6.6.3, 7.3
>Reporter: Shawn Heisey
>Priority: Major
> Attachments: SOLR-12236.patch
>
>
> The logging page in the admin UI has a "Core" column, but there is never 
> anything in that column.  I fired up the techproducts example, then used the 
> Documents tab to try to index a document missing the "id" field, and got this 
> error in the logfile:
> ERROR - 2018-04-18 18:51:31.232; [   x:techproducts] 
> org.apache.solr.common.SolrException; org.apache.solr.common.SolrException: 
> Document is missing mandatory uniqueKey field: id
> The core name (techproducts) is in the logfile as seen above, but when 
> looking at the logging page in the UI, it can't be found anywhere.
> This is the case in both master and branch_7x.  I also tried it on the 6.6.3 
> version (binary package) with the same results.  On version 5.3.2-SNAPSHOT, 
> the Core column says "null" for all logs, instead of being blank.  That 
> column does not appear to be present in 4.x versions.



--
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 # 569 - Still unstable

[Apache Jenkins Server]

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

2 tests failed.
FAILED:  org.apache.solr.cloud.autoscaling.IndexSizeTriggerTest.testTrigger

Error Message:
waitFor not elapsed but produced an event

Stack Trace:
java.lang.AssertionError: waitFor not elapsed but produced an event
at 
__randomizedtesting.SeedInfo.seed([B9484EBDB5A65F23:DA83783F2C692C0E]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertNull(Assert.java:551)
at 
org.apache.solr.cloud.autoscaling.IndexSizeTriggerTest.testTrigger(IndexSizeTriggerTest.java:180)
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:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
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:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
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.IndexSizeTriggerTest.testSplitIntegration

Error Message:


Stack Trace:
java.util.concurrent.TimeoutException
at 
__randomizedtesting.SeedInfo.seed([B9484EBDB5A65F23:80C6F7FD9A5996DD]:0)
at 

Marketing ApacheCon on Solr home page

[Alexandre Rafalovitch]

Hi,

On the Apache Community mailing list, they are asking the projects to
include an - auto-updated - Apache "ad" block for the ApacheCon.

I had a look at the Solr home page and I think it would fit right at
the end, under the "Apache Software Foundation" block
https://lucene.apache.org/solr/

They offer two sizes, I think the wider one looks nicer:
https://www.apache.org/events/current-event-234x60.png

The full instructions are at: https://apache.org/events/README.txt .
Seems easy enough. But I am not even sure who/how the Solr site is now
updated. Is that in Git somewhere as well?

Regards,
   Alex.

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

[jira] [Commented] (SOLR-12236) Admin UI logging page: "Core" column never gets populated

[Shawn Heisey (JIRA)]

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

Shawn Heisey commented on SOLR-12236:
-

I noticed that the 7.3 version still shows up as unreleased in Jira.

> Admin UI logging page: "Core" column never gets populated
> -
>
> Key: SOLR-12236
> URL: https://issues.apache.org/jira/browse/SOLR-12236
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Admin UI, logging
>Affects Versions: 6.6.3, 7.3
>Reporter: Shawn Heisey
>Priority: Major
>
> The logging page in the admin UI has a "Core" column, but there is never 
> anything in that column.  I fired up the techproducts example, then used the 
> Documents tab to try to index a document missing the "id" field, and got this 
> error in the logfile:
> ERROR - 2018-04-18 18:51:31.232; [   x:techproducts] 
> org.apache.solr.common.SolrException; org.apache.solr.common.SolrException: 
> Document is missing mandatory uniqueKey field: id
> The core name (techproducts) is in the logfile as seen above, but when 
> looking at the logging page in the UI, it can't be found anywhere.
> This is the case in both master and branch_7x.  I also tried it on the 6.6.3 
> version (binary package) with the same results.  On version 5.3.2-SNAPSHOT, 
> the Core column says "null" for all logs, instead of being blank.  That 
> column does not appear to be present in 4.x versions.



--
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-12236) Admin UI logging page: "Core" column never gets populated

[Shawn Heisey (JIRA)]

Shawn Heisey created SOLR-12236:
---

 Summary: Admin UI logging page: "Core" column never gets populated
 Key: SOLR-12236
 URL: https://issues.apache.org/jira/browse/SOLR-12236
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
  Components: Admin UI, logging
Affects Versions: 6.6.3, 7.3
Reporter: Shawn Heisey


The logging page in the admin UI has a "Core" column, but there is never 
anything in that column.  I fired up the techproducts example, then used the 
Documents tab to try to index a document missing the "id" field, and got this 
error in the logfile:

ERROR - 2018-04-18 18:51:31.232; [   x:techproducts] 
org.apache.solr.common.SolrException; org.apache.solr.common.SolrException: 
Document is missing mandatory uniqueKey field: id

The core name (techproducts) is in the logfile as seen above, but when looking 
at the logging page in the UI, it can't be found anywhere.

This is the case in both master and branch_7x.  I also tried it on the 6.6.3 
version (binary package) with the same results.  On version 5.3.2-SNAPSHOT, the 
Core column says "null" for all logs, instead of being blank.  That column does 
not appear to be present in 4.x versions.



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

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

[JENKINS] Lucene-Solr-7.x-Windows (32bit/jdk1.8.0_144) - Build # 550 - Still Unstable!

[Policeman Jenkins Server]

Error processing tokens: Error while parsing action 
'Text/ZeroOrMore/FirstOf/Token/DelimitedToken/DelimitedToken_Action3' at input 
position (line 79, pos 4):
)"}
   ^

java.lang.OutOfMemoryError: Java heap space

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

[jira] [Commented] (SOLR-11578) Solr 7 Admin UI (Cloud > Graph) should reflect the Replica type to give a more accurate representation of the cluster

[Rohit (JIRA)]

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

Rohit commented on SOLR-11578:
--

Correctly merged all the changes in 1 patch file.

Verified the patch with *ant rat-sources and ant precommit*

Attached screen shot of the Solr Cloud UI with the new update.
 * Indicate the replica types (NRT, TLOG, PULL)
 * Display the meta information about the replica from state.json when you 
hover over the Replica name in Solr Admin UI --> Cloud (please see the new 
screenshot attached).

> Solr 7 Admin UI (Cloud > Graph) should reflect the Replica type to give a 
> more accurate representation of the cluster
> -
>
> Key: SOLR-11578
> URL: https://issues.apache.org/jira/browse/SOLR-11578
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Admin UI
>Affects Versions: 7.0, 7.1
>Reporter: Rohit
>Assignee: Erick Erickson
>Priority: Minor
> Attachments: NRT_Tooltip.png, OnFirefox.png, OnSafari.png, 
> SOLR-11578.patch, SOLR-11578.patch, SOLR-11578.patch, Screen Shot-2.png, 
> Screenshot-1.png, TLOG_Tooltip.png, Updated Graph.png, Updated Legend.png, 
> Updated Radial Graph.png, jquery-ui.min.css, jquery-ui.min.js, 
> jquery-ui.structure.min.css
>
>
> New replica types were introduced in Solr 7.
> 1. The Solr Admin UI --> Cloud --> Graph mode should be updated to reflect 
> the new replica types (NRT, TLOG, PULL)
> 2. It will give a better overview of the cluster as well as help in 
> troubleshooting and diagnosing issues.



--
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-11578) Solr 7 Admin UI (Cloud > Graph) should reflect the Replica type to give a more accurate representation of the cluster

[Rohit (JIRA)]

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

Rohit updated SOLR-11578:
-
Attachment: Screenshot-1.png
Screen Shot-2.png

> Solr 7 Admin UI (Cloud > Graph) should reflect the Replica type to give a 
> more accurate representation of the cluster
> -
>
> Key: SOLR-11578
> URL: https://issues.apache.org/jira/browse/SOLR-11578
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Admin UI
>Affects Versions: 7.0, 7.1
>Reporter: Rohit
>Assignee: Erick Erickson
>Priority: Minor
> Attachments: NRT_Tooltip.png, OnFirefox.png, OnSafari.png, 
> SOLR-11578.patch, SOLR-11578.patch, SOLR-11578.patch, Screen Shot-2.png, 
> Screenshot-1.png, TLOG_Tooltip.png, Updated Graph.png, Updated Legend.png, 
> Updated Radial Graph.png, jquery-ui.min.css, jquery-ui.min.js, 
> jquery-ui.structure.min.css
>
>
> New replica types were introduced in Solr 7.
> 1. The Solr Admin UI --> Cloud --> Graph mode should be updated to reflect 
> the new replica types (NRT, TLOG, PULL)
> 2. It will give a better overview of the cluster as well as help in 
> troubleshooting and diagnosing issues.



--
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-11578) Solr 7 Admin UI (Cloud > Graph) should reflect the Replica type to give a more accurate representation of the cluster

[Rohit (JIRA)]

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

Rohit updated SOLR-11578:
-
Attachment: SOLR-11578.patch

> Solr 7 Admin UI (Cloud > Graph) should reflect the Replica type to give a 
> more accurate representation of the cluster
> -
>
> Key: SOLR-11578
> URL: https://issues.apache.org/jira/browse/SOLR-11578
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Admin UI
>Affects Versions: 7.0, 7.1
>Reporter: Rohit
>Assignee: Erick Erickson
>Priority: Minor
> Attachments: NRT_Tooltip.png, OnFirefox.png, OnSafari.png, 
> SOLR-11578.patch, SOLR-11578.patch, SOLR-11578.patch, TLOG_Tooltip.png, 
> Updated Graph.png, Updated Legend.png, Updated Radial Graph.png, 
> jquery-ui.min.css, jquery-ui.min.js, jquery-ui.structure.min.css
>
>
> New replica types were introduced in Solr 7.
> 1. The Solr Admin UI --> Cloud --> Graph mode should be updated to reflect 
> the new replica types (NRT, TLOG, PULL)
> 2. It will give a better overview of the cluster as well as help in 
> troubleshooting and diagnosing issues.



--
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-Windows (64bit/jdk-11-ea+5) - Build # 7273 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/7273/
Java: 64bit/jdk-11-ea+5 -XX:+UseCompressedOops -XX:+UseG1GC

18 tests failed.
FAILED:  org.apache.solr.handler.TestReplicationHandler.doTestStressReplication

Error Message:
found:2[index.20180418113751198, index.20180418113751512, index.properties, 
replication.properties, snapshot_metadata]

Stack Trace:
java.lang.AssertionError: found:2[index.20180418113751198, 
index.20180418113751512, index.properties, replication.properties, 
snapshot_metadata]
at 
__randomizedtesting.SeedInfo.seed([C661FB3A40345359:1DCAFBFC451C3AEA]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.handler.TestReplicationHandler.checkForSingleIndex(TestReplicationHandler.java:968)
at 
org.apache.solr.handler.TestReplicationHandler.checkForSingleIndex(TestReplicationHandler.java:939)
at 
org.apache.solr.handler.TestReplicationHandler.doTestStressReplication(TestReplicationHandler.java:915)
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:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
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:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 

[jira] [Commented] (LUCENE-8249) Add matches to exact PhraseQuery and MultiPhraseQuery

[Adrien Grand (JIRA)]

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

Adrien Grand commented on LUCENE-8249:
--

I like this approach better. I have some questions/notes:
 - The implementation of {{MatchesIterator#term}} feels wrong. Should remove 
that method or make it return a list of terms?
 - I think {{PhraseMatcher#minFreq()}} should actually be called {{maxFreq}}, 
since it tries to give an upper bound of the frequency of this phrase?
 - Is the implementation of {{SloppyPhraseMatcher#minFreq}} right? A single 
term position can be used for two phrase positions with slops? For instance I 
suspect that if you search for a phrase of two synonyms with a large slop, you 
end up with a phrase frequency that is larger than the frequency of any 
synonym? Maybe we should also make this a float rather than an int, it might 
have potential to be greater than an int?
 - I'm wondering whether we can simplify ExactPhraseMatcher to not have its 
lead iterator being one position ahead all the time? This would eg. allow to 
remove the {{if (exposeOffset)}} trick to remember the start offset.
 - Should we try to implement freq() on top of the matchers? It's a bit weird 
that it consumes the iterator when called.

> Add matches to exact PhraseQuery and MultiPhraseQuery
> -
>
> Key: LUCENE-8249
> URL: https://issues.apache.org/jira/browse/LUCENE-8249
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Alan Woodward
>Assignee: Alan Woodward
>Priority: Major
> Attachments: LUCENE-8249.patch, LUCENE-8249.patch
>
>
> ExactPhraseScorer can be rejigged fairly easily to expose a MatchesIterator



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

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

[JENKINS] Lucene-Solr-SmokeRelease-7.x - Build # 203 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-7.x/203/

No tests ran.

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

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

-dist-keys:
  [get] Getting: http://home.apache.org/keys/group/lucene.asc
  [get] To: 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/solr/package/KEYS

package:

-unpack-solr-tgz:

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

generate-maven-artifacts:

resolve:

resolve:

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

-ivy-fail-disallowed-ivy-version:

ivy-fail:

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

resolve:

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

-ivy-fail-disallowed-ivy-version:

ivy-fail:

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

resolve:

resolve:

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

-ivy-fail-disallowed-ivy-version:

ivy-fail:

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

resolve:

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

-ivy-fail-disallowed-ivy-version:

ivy-fail:

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

resolve:

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

-ivy-fail-disallowed-ivy-version:

ivy-fail:

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

resolve:

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

-ivy-fail-disallowed-ivy-version:

ivy-fail:

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

resolve:

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

-ivy-fail-disallowed-ivy-version:

ivy-fail:

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

resolve:

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

-ivy-fail-disallowed-ivy-version:

ivy-fail:

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

resolve:

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

-ivy-fail-disallowed-ivy-version:

ivy-fail:

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

resolve:

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

-ivy-fail-disallowed-ivy-version:

ivy-fail:

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

resolve:

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

-ivy-fail-disallowed-ivy-version:

ivy-fail:

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

Re: [JENKINS] Lucene-Solr-7.x-Linux (32bit/jdk1.8.0_162) - Build # 1744 - Failure!

[Simon Willnauer]

pushed a fix, test bug - sorry for the noise

On Wed, Apr 18, 2018 at 12:47 PM, Policeman Jenkins Server
 wrote:
> Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/1744/
> Java: 32bit/jdk1.8.0_162 -server -XX:+UseG1GC
>
> 1 tests failed.
> FAILED:  
> org.apache.lucene.index.TestPendingSoftDeletes.testUpdateAppliedOnlyOnce
>
> Error Message:
> expected:<1> but was:<2>
>
> Stack Trace:
> java.lang.AssertionError: expected:<1> but was:<2>
> at 
> __randomizedtesting.SeedInfo.seed([534121D77EFDCB0A:7E638ADEA75CBAAB]: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.lucene.index.TestPendingSoftDeletes.testUpdateAppliedOnlyOnce(TestPendingSoftDeletes.java:170)
> 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:1737)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
> 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:943)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
> at 
> org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
> at 
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
> at 
> org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
> at 
> com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
> at 
> com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
> at 
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
> at 
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
> at 
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
> at 
> org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
> at 
> org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
> at 
> org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
> at 
> org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
> at 
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
> at 
> com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
> at java.lang.Thread.run(Thread.java:748)
>
>
>
>
> Build Log:
> [...truncated 480 lines...]
>[junit4] Suite: org.apache.lucene.index.TestPendingSoftDeletes
>[junit4]   2> NOTE: reproduce with: ant test  

[jira] [Commented] (SOLR-11833) Allow searchRate trigger to delete replicas

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar commented on SOLR-11833:
--

Thanks Andrzej. Two questions:

# Why does SearchRateTrigger skip PULL replica types?
# For back-compatibility, can't we support {{rate}} but set both {{aboveRate}} 
and {{belowRate}} to the same value?

> Allow searchRate trigger to delete replicas
> ---
>
> Key: SOLR-11833
> URL: https://issues.apache.org/jira/browse/SOLR-11833
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: AutoScaling
>Reporter: Andrzej Bialecki 
>Assignee: Andrzej Bialecki 
>Priority: Major
> Fix For: 7.4, master (8.0)
>
> Attachments: SOLR-11833.patch, SOLR-11833.patch
>
>
> Currently {{SearchRateTrigger}} generates events when search rate thresholds 
> are exceeded, and {{ComputePlanAction}} computes ADDREPLICA actions in 
> response - adding replicas should allow the search rate to be reduced across 
> the increased number of replicas.
> However, once the peak load period is over the collection is left with too 
> many replicas, which unnecessarily tie cluster resources. 
> {{SearchRateTrigger}} should detect situations like this and generate events 
> that should cause some of these replicas to be deleted.
> {{SearchRateTrigger}} should use hysteresis to avoid thrashing when the rate 
> is close to the threshold.



--
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-8180) Explore using (Future)Arrays.mismatch for FixedBitSet.nextSetBit

[Adrien Grand (JIRA)]

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

Adrien Grand commented on LUCENE-8180:
--

(Note: I had to patch luceneutil to use the JAR file of lucene-core rather than 
the classes folder https://github.com/mikemccand/luceneutil/pull/14)

> Explore using (Future)Arrays.mismatch for FixedBitSet.nextSetBit
> 
>
> Key: LUCENE-8180
> URL: https://issues.apache.org/jira/browse/LUCENE-8180
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Adrien Grand
>Priority: Trivial
>  Labels: newdev
> Attachments: LUCENE-8180.patch
>
>
> Using Arrays.mismatch with a fixed-size array full of zeros might help find 
> the next long that is not 0 faster.



--
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-8180) Explore using (Future)Arrays.mismatch for FixedBitSet.nextSetBit

[Adrien Grand (JIRA)]

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

Adrien Grand resolved LUCENE-8180.
--
Resolution: Not A Problem

> Explore using (Future)Arrays.mismatch for FixedBitSet.nextSetBit
> 
>
> Key: LUCENE-8180
> URL: https://issues.apache.org/jira/browse/LUCENE-8180
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Adrien Grand
>Priority: Trivial
>  Labels: newdev
> Attachments: LUCENE-8180.patch
>
>
> Using Arrays.mismatch with a fixed-size array full of zeros might help find 
> the next long that is not 0 faster.



--
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-8180) Explore using (Future)Arrays.mismatch for FixedBitSet.nextSetBit

[Adrien Grand (JIRA)]

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

Adrien Grand updated LUCENE-8180:
-
Attachment: LUCENE-8180.patch

> Explore using (Future)Arrays.mismatch for FixedBitSet.nextSetBit
> 
>
> Key: LUCENE-8180
> URL: https://issues.apache.org/jira/browse/LUCENE-8180
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Adrien Grand
>Priority: Trivial
>  Labels: newdev
> Attachments: LUCENE-8180.patch
>
>
> Using Arrays.mismatch with a fixed-size array full of zeros might help find 
> the next long that is not 0 faster.



--
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-8180) Explore using (Future)Arrays.mismatch for FixedBitSet.nextSetBit

[Adrien Grand (JIRA)]

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

Adrien Grand commented on LUCENE-8180:
--

It doesn't seem to.

I tried to test this change but there is a slight slowdown with wikibigall:

{noformat}
TaskQPS baseline  StdDev   QPS patch  StdDev
Pct diff
 Prefix3  107.21  (6.9%)  100.80  (5.7%)   
-6.0% ( -17% -7%)
Wildcard   73.71  (6.9%)   70.43  (6.0%)   
-4.4% ( -16% -9%)
  IntNRQ   28.69 (10.1%)   27.82  (9.0%)   
-3.0% ( -20% -   17%)
  OrHighHigh   32.25  (3.2%)   32.12  (3.3%)   
-0.4% (  -6% -6%)
   OrHighMed  101.35  (2.5%)  101.03  (2.2%)   
-0.3% (  -4% -4%)
HighSpanNear5.51  (5.5%)5.50  (5.4%)   
-0.2% ( -10% -   11%)
   MedPhrase   14.55  (1.7%)   14.52  (1.6%)   
-0.2% (  -3% -3%)
  AndHighMed  215.89  (3.0%)  215.59  (2.9%)   
-0.1% (  -5% -5%)
 MedSloppyPhrase   23.26  (3.3%)   23.23  (3.3%)   
-0.1% (  -6% -6%)
 MedSpanNear   79.38  (5.1%)   79.29  (5.1%)   
-0.1% (  -9% -   10%)
   LowPhrase   67.40  (1.4%)   67.33  (1.4%)   
-0.1% (  -2% -2%)
   AndCommon  154.32  (4.2%)  154.21  (4.2%)   
-0.1% (  -8% -8%)
 LowSpanNear   39.95  (3.1%)   39.92  (3.2%)   
-0.1% (  -6% -6%)
  HighPhrase   60.46  (1.7%)   60.42  (1.6%)   
-0.1% (  -3% -3%)
 LowSloppyPhrase  706.30  (2.0%)  705.95  (1.9%)   
-0.1% (  -3% -3%)
 AndHighHigh   37.60  (2.6%)   37.59  (2.8%)   
-0.0% (  -5% -5%)
   OrHighLow 1380.85  (4.3%) 1380.85  (3.6%)
0.0% (  -7% -8%)
HighSloppyPhrase1.87  (7.9%)1.87  (7.7%)
0.1% ( -14% -   17%)
OrCommon  217.99  (5.1%)  218.29  (5.1%)
0.1% (  -9% -   10%)
HighTerm  433.84  (6.7%)  434.54  (6.5%)
0.2% ( -12% -   14%)
 LowTerm 2344.87  (4.6%) 2349.37  (4.7%)
0.2% (  -8% -9%)
   HighTermMonthSort   55.69 (11.1%)   55.83 (11.2%)
0.3% ( -19% -   25%)
 Respell  211.40  (2.6%)  211.98  (2.5%)
0.3% (  -4% -5%)
 MedTerm 1125.82  (5.6%) 1129.18  (5.4%)
0.3% ( -10% -   11%)
   HighTermDayOfYearSort   98.79  (9.2%)   99.16  (8.4%)
0.4% ( -15% -   19%)
  Fuzzy2  111.64 (12.4%)  112.17 (11.3%)
0.5% ( -20% -   27%)
  Fuzzy1  226.93  (7.3%)  228.67  (8.0%)
0.8% ( -13% -   17%)
  AndHighLow 1720.51  (5.1%) 1741.37  (5.2%)
1.2% (  -8% -   12%)
{noformat}

> Explore using (Future)Arrays.mismatch for FixedBitSet.nextSetBit
> 
>
> Key: LUCENE-8180
> URL: https://issues.apache.org/jira/browse/LUCENE-8180
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Adrien Grand
>Priority: Trivial
>  Labels: newdev
>
> Using Arrays.mismatch with a fixed-size array full of zeros might help find 
> the next long that is not 0 faster.



--
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: StreamExpressionTest.testNulls hangs for 3 days on Policeman Jenkins.

[Steve Rowe]

Thanks Mikhail, I killed it.

--
Steve
www.lucidworks.com

> On Apr 18, 2018, at 7:09 AM, Mikhail Khludnev  wrote:
> 
> 
> https://jenkins.thetaphi.de/job/Lucene-Solr-master-Solaris/1804/console
> 
> I can't shoot it as I used to.
> 
> -- 
> Sincerely yours
> Mikhail Khludnev


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

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

[Apache Jenkins Server]

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

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

[repro] Revision: 330fd18f200dae0892b3aa0882668435730c4319

[repro] Ant options: -Dtests.multiplier=2 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-BadApples-NightlyTests-7.x/test-data/enwiki.random.lines.txt
[repro] Repro line:  ant test  -Dtestcase=RestartWhileUpdatingTest 
-Dtests.method=test -Dtests.seed=789067998E3E27C7 -Dtests.multiplier=2 
-Dtests.nightly=true -Dtests.slow=true -Dtests.badapples=true 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-BadApples-NightlyTests-7.x/test-data/enwiki.random.lines.txt
 -Dtests.locale=pt-PT -Dtests.timezone=Eire -Dtests.asserts=true 
-Dtests.file.encoding=UTF-8

[repro] Repro line:  ant test  -Dtestcase=RestartWhileUpdatingTest 
-Dtests.seed=789067998E3E27C7 -Dtests.multiplier=2 -Dtests.nightly=true 
-Dtests.slow=true -Dtests.badapples=true 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-BadApples-NightlyTests-7.x/test-data/enwiki.random.lines.txt
 -Dtests.locale=pt-PT -Dtests.timezone=Eire -Dtests.asserts=true 
-Dtests.file.encoding=UTF-8

[repro] git rev-parse --abbrev-ref HEAD
[repro] git rev-parse HEAD
[repro] Initial local git branch/revision: 
dbdedf3e3f4b4f839348cf4759dc65092f7d5baf
[repro] git fetch

[...truncated 2 lines...]
[repro] git checkout 330fd18f200dae0892b3aa0882668435730c4319

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

[...truncated 3316 lines...]
[repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=5 
-Dtests.class="*.RestartWhileUpdatingTest" -Dtests.showOutput=onerror 
-Dtests.multiplier=2 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-BadApples-NightlyTests-7.x/test-data/enwiki.random.lines.txt
 -Dtests.seed=789067998E3E27C7 -Dtests.multiplier=2 -Dtests.nightly=true 
-Dtests.slow=true -Dtests.badapples=true 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-BadApples-NightlyTests-7.x/test-data/enwiki.random.lines.txt
 -Dtests.locale=pt-PT -Dtests.timezone=Eire -Dtests.asserts=true 
-Dtests.file.encoding=UTF-8

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

[repro] Failures:
[repro]   3/5 failed: org.apache.solr.cloud.RestartWhileUpdatingTest
[repro] git checkout dbdedf3e3f4b4f839348cf4759dc65092f7d5baf

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

[jira] [Commented] (SOLR-12233) QParserPlugin maintains a list of classes recreated every time a Solrcore object is created

[Shawn Heisey (JIRA)]

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

Shawn Heisey commented on SOLR-12233:
-

bq. In our use case we're loading some 60,000 solrcore objects

That many cores on one machine is going to present a LOT of scalability issues, 
some of which cannot be improved, even when using transient cores.  Anything 
you can do to decrease this number is going to help.  One idea is to combine 
data from multiple cores into one core, and use filtering on fields in the 
document.  Another is to add more servers, so there are fewer cores on each one.

Sharing internal objects like this issue aims to do will help, but that can't 
be done with everything.  A SolrCore instance is not a small object, and takes 
a little bit of time to initialize.

bq. the other being creating the handlers which is a whole other problem 

There are a lot of implicit request handlers created even without 
configuration.  Quite a lot of them were added after the 4.x versions.  It 
might be that we need a way to disable implicit handlers when the user is 
facing scalability issues and is absolutely certain that they won't ever need 
some of them.

https://lucene.apache.org/solr/guide/7_3/implicit-requesthandlers.html


> QParserPlugin maintains a list of classes recreated every time a Solrcore 
> object is created
> ---
>
> Key: SOLR-12233
> URL: https://issues.apache.org/jira/browse/SOLR-12233
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 7.1.1
>Reporter: Jeff Miller
>Assignee: Erick Erickson
>Priority: Minor
>  Labels: Performance, qparserplugin
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> QParserPlugin maintains a static map of Class Names to Class objects and 
> everytime we create a SolrCore object this causes a lot of overhead doing 
> classloader lookups.  Our system runs a lot of cores and the classloader gets 
> bogged down when a lot of threads are creating solrcore objects.  
> There's no need to create these objects every time, similar classes such as 
> TransformerFactory store the object one time and reference it over and over 
> again



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

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

[JENKINS] Lucene-Solr-NightlyTests-7.x - Build # 203 - Failure

[Apache Jenkins Server]

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

5 tests failed.
FAILED:  junit.framework.TestSuite.org.apache.solr.cloud.ZkControllerTest

Error Message:
ObjectTracker found 1 object(s) that were not released!!! [Overseer] 
org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: 
org.apache.solr.cloud.Overseer  at 
org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42)
  at org.apache.solr.cloud.Overseer.start(Overseer.java:545)  at 
org.apache.solr.cloud.OverseerElectionContext.runLeaderProcess(ElectionContext.java:851)
  at 
org.apache.solr.cloud.LeaderElector.runIamLeaderProcess(LeaderElector.java:170) 
 at 
org.apache.solr.cloud.LeaderElector.checkIfIamLeader(LeaderElector.java:135)  
at org.apache.solr.cloud.LeaderElector.joinElection(LeaderElector.java:307)  at 
org.apache.solr.cloud.LeaderElector.retryElection(LeaderElector.java:393)  at 
org.apache.solr.cloud.ZkController.rejoinOverseerElection(ZkController.java:2081)
  at 
org.apache.solr.cloud.Overseer$ClusterStateUpdater.checkIfIamStillLeader(Overseer.java:331)
  at java.lang.Thread.run(Thread.java:748)  

Stack Trace:
java.lang.AssertionError: ObjectTracker found 1 object(s) that were not 
released!!! [Overseer]
org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: 
org.apache.solr.cloud.Overseer
at 
org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42)
at org.apache.solr.cloud.Overseer.start(Overseer.java:545)
at 
org.apache.solr.cloud.OverseerElectionContext.runLeaderProcess(ElectionContext.java:851)
at 
org.apache.solr.cloud.LeaderElector.runIamLeaderProcess(LeaderElector.java:170)
at 
org.apache.solr.cloud.LeaderElector.checkIfIamLeader(LeaderElector.java:135)
at 
org.apache.solr.cloud.LeaderElector.joinElection(LeaderElector.java:307)
at 
org.apache.solr.cloud.LeaderElector.retryElection(LeaderElector.java:393)
at 
org.apache.solr.cloud.ZkController.rejoinOverseerElection(ZkController.java:2081)
at 
org.apache.solr.cloud.Overseer$ClusterStateUpdater.checkIfIamStillLeader(Overseer.java:331)
at java.lang.Thread.run(Thread.java:748)


at __randomizedtesting.SeedInfo.seed([769471CD20BAB3FF]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertNull(Assert.java:551)
at 
org.apache.solr.SolrTestCaseJ4.teardownTestCases(SolrTestCaseJ4.java:303)
at sun.reflect.GeneratedMethodAccessor39.invoke(Unknown Source)
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:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:897)
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:  junit.framework.TestSuite.org.apache.solr.cloud.ZkControllerTest

Error Message:
1 thread leaked from SUITE scope at org.apache.solr.cloud.ZkControllerTest: 
1) 

[jira] [Commented] (SOLR-12231) /etc/init.d/solr problem

[Steve Rowe (JIRA)]

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

Steve Rowe commented on SOLR-12231:
---

I don't know anything about SolrSearch or Omeka, but: adding the semicolons 
means that the {{$SOLR_INCLUDE}} environment variable assignment is not 
available to {{bin/solr}}.  I wonder if the real issue is that the file pointed 
to by {{$SOLR_INCLUDE}} ({{/etc/default/solr.in.sh}} by default) is somehow 
missing/incorrect/malformed?  What do the logs say?

> /etc/init.d/solr problem
> 
>
> Key: SOLR-12231
> URL: https://issues.apache.org/jira/browse/SOLR-12231
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: scripts and tools
>Affects Versions: 7.3
> Environment: Centos 7.4 
> java-1.8.0-openjdk
>Reporter: Lihua Wang
>Assignee: Steve Rowe
>Priority: Minor
>
> I noticed that there are a couple of minor issues with the init.d script in 
> pretty much every version. 
> Basically, a semicolon (or an escaped semicolon) is missing in the 
> *{color:#205081}BLUE{color}* lines blow:
>  
> if [ -n "$RUNAS" ]; then
>  {color:#205081}su -c "SOLR_INCLUDE=\"$SOLR_ENV\" 
> \"$SOLR_INSTALL_DIR/bin/solr\" $SOLR_CMD" - "$RUNAS"{color}
>  else
>  {color:#205081}SOLR_INCLUDE="$SOLR_ENV" "$SOLR_INSTALL_DIR/bin/solr" 
> "$SOLR_CMD"{color}
>  fi
>  
> *With the {color:#d04437}added semicolons{color} (escaped where necessary), 
> the code would look like:* 
> if [ -n "$RUNAS" ]; then
>  *{color:#8eb021}{color:#8eb021}su -c 
> "SOLR_INCLUDE=\"$SOLR_ENV\"{color:#d04437}\;{color}{color} 
> \"$SOLR_INSTALL_DIR/bin/solr\" $SOLR_CMD" - 
> "$RUNAS"{color}{color:#8eb021}*{color}*
>  *else*
>  
> *{color:#8eb021}*SOLR_INCLUDE="$SOLR_ENV"{color:#d04437};{color}{color}{color:#8eb021}
>  "$SOLR_INSTALL_DIR/bin/solr" "$SOLR_CMD"{color}*
>  fi
>  



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

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

[JENKINS] Lucene-Solr-7.x-Linux (32bit/jdk1.8.0_162) - Build # 1745 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/1745/
Java: 32bit/jdk1.8.0_162 -server -XX:+UseConcMarkSweepGC

2 tests failed.
FAILED:  
org.apache.solr.cloud.autoscaling.IndexSizeTriggerTest.testSplitIntegration

Error Message:


Stack Trace:
java.util.concurrent.TimeoutException
at 
__randomizedtesting.SeedInfo.seed([6F610A441138D356:56EFB3043EC71AA8]:0)
at 
org.apache.solr.cloud.CloudTestUtils.waitForState(CloudTestUtils.java:109)
at 
org.apache.solr.cloud.autoscaling.IndexSizeTriggerTest.testSplitIntegration(IndexSizeTriggerTest.java:299)
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:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
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:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
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.IndexSizeTriggerTest.testTrigger

Error Message:
waitFor not elapsed but produced an event

Stack Trace:
java.lang.AssertionError: waitFor not elapsed but produced an event
at 
__randomizedtesting.SeedInfo.seed([6F610A441138D356:CAA3CC688F7A07B]:0)
at 

[jira] [Commented] (SOLR-12231) /etc/init.d/solr problem

[Lihua Wang (JIRA)]

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

Lihua Wang commented on SOLR-12231:
---

For some reason, I had to add the semicolons in those lines for Solr to 
properly load a third party core. (SolrSearch for omeka). Without the 
semicolons, the omeka core of SolrSearch does not load.

> /etc/init.d/solr problem
> 
>
> Key: SOLR-12231
> URL: https://issues.apache.org/jira/browse/SOLR-12231
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: scripts and tools
>Affects Versions: 7.3
> Environment: Centos 7.4 
> java-1.8.0-openjdk
>Reporter: Lihua Wang
>Assignee: Steve Rowe
>Priority: Minor
>
> I noticed that there are a couple of minor issues with the init.d script in 
> pretty much every version. 
> Basically, a semicolon (or an escaped semicolon) is missing in the 
> *{color:#205081}BLUE{color}* lines blow:
>  
> if [ -n "$RUNAS" ]; then
>  {color:#205081}su -c "SOLR_INCLUDE=\"$SOLR_ENV\" 
> \"$SOLR_INSTALL_DIR/bin/solr\" $SOLR_CMD" - "$RUNAS"{color}
>  else
>  {color:#205081}SOLR_INCLUDE="$SOLR_ENV" "$SOLR_INSTALL_DIR/bin/solr" 
> "$SOLR_CMD"{color}
>  fi
>  
> *With the {color:#d04437}added semicolons{color} (escaped where necessary), 
> the code would look like:* 
> if [ -n "$RUNAS" ]; then
>  *{color:#8eb021}{color:#8eb021}su -c 
> "SOLR_INCLUDE=\"$SOLR_ENV\"{color:#d04437}\;{color}{color} 
> \"$SOLR_INSTALL_DIR/bin/solr\" $SOLR_CMD" - 
> "$RUNAS"{color}{color:#8eb021}*{color}*
>  *else*
>  
> *{color:#8eb021}*SOLR_INCLUDE="$SOLR_ENV"{color:#d04437};{color}{color}{color:#8eb021}
>  "$SOLR_INSTALL_DIR/bin/solr" "$SOLR_CMD"{color}*
>  fi
>  



--
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-11933) DIH gui shouldn't have "clean" be checked by default

[Shawn Heisey (JIRA)]

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

Shawn Heisey commented on SOLR-11933:
-

See SOLR-9613.

I think the default of the 'clean' checkbox in the UI should change depending 
on the type of import selected.  This is what happens when using the API 
directly and the clean parameter is not present.

If full-import is selected, it should be on, if delta-import is selected, it 
should be off.  (with the option for the user to change the setting, of course)

> DIH gui shouldn't have "clean" be checked by default
> 
>
> Key: SOLR-11933
> URL: https://issues.apache.org/jira/browse/SOLR-11933
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: contrib - DataImportHandler
>Affects Versions: 7.2
>Reporter: Eric Pugh
>Assignee: Tomás Fernández Löbbe
>Priority: Minor
> Fix For: 7.3, master (8.0)
>
> Attachments: fef1d06a2eb15a0fd36eb91124af413a19d95528.diff
>
>
> The DIH webapp by default has the "clean" checkbox enabled.   Clean is very 
> dangerous because you delete all the data first, and then load the data.   
> Making this the default choice is bad UX.  



--
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-12187) Replica should watch clusterstate and unload itself if its entry is removed

[Cao Manh Dat (JIRA)]

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

Cao Manh Dat commented on SOLR-12187:
-

thanks [~mkhludnev]!

> Replica should watch clusterstate and unload itself if its entry is removed
> ---
>
> Key: SOLR-12187
> URL: https://issues.apache.org/jira/browse/SOLR-12187
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Cao Manh Dat
>Assignee: Cao Manh Dat
>Priority: Major
> Fix For: 7.4
>
> Attachments: SOLR-12187.patch, SOLR-12187.patch, SOLR-12187.patch, 
> SOLR-12187.patch, SOLR-12187.patch, SOLR-12187.patch
>
>
> With the introduction of autoscaling framework, we have seen an increase in 
> the number of issues related to the race condition between delete a replica 
> and other stuff.
> Case 1: DeleteReplicaCmd failed to send UNLOAD request to a replica, 
> therefore, forcefully remove its entry from clusterstate, but the replica 
> still function normally and be able to become a leader -> SOLR-12176
> Case 2:
>  * DeleteReplicaCmd enqueue a DELETECOREOP (without sending a request to 
> replica because the node is not live)
>  * The node start and the replica get loaded
>  * DELETECOREOP has not processed hence the replica still present in 
> clusterstate --> pass checkStateInZk
>  * DELETECOREOP is executed, DeleteReplicaCmd finished
>  ** result 1: the replica start recovering, finish it and publish itself as 
> ACTIVE --> state of the replica is ACTIVE
>  ** result 2: the replica throw an exception (probably: NPE) 
> --> state of the replica is DOWN, not join leader election



--
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-12155) Solr 7.2.1 deadlock in UnInvertedField.getUnInvertedField()

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-12155:


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

SOLR-12155: making TestUnInvertedFieldException more thread-safe


> Solr 7.2.1 deadlock in UnInvertedField.getUnInvertedField() 
> 
>
> Key: SOLR-12155
> URL: https://issues.apache.org/jira/browse/SOLR-12155
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 7.2.1
>Reporter: Kishor gandham
>Assignee: Mikhail Khludnev
>Priority: Major
> Fix For: 7.4, master (8.0)
>
> Attachments: 21832-consoleText.txt.zip, SOLR-12155.master.patch, 
> SOLR-12155.patch, SOLR-12155.patch, SOLR-12155.patch, SOLR-12155.patch, 
> SOLR-12155.patch, SOLR-12155.patch, stack.txt
>
>
> I am attaching a stack trace from our production Solr (7.2.1). Occasionally, 
> we are seeing SOLR becoming unresponsive. We are then forced to kill the JVM 
> and start solr again.
> We have a lot of facet queries and our index has approximately 15 million 
> documents. We have recently started using json.facet queries and some of the 
> facet fields use DocValues.



--
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-12155) Solr 7.2.1 deadlock in UnInvertedField.getUnInvertedField()

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-12155:


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

SOLR-12155: making TestUnInvertedFieldException more thread-safe


> Solr 7.2.1 deadlock in UnInvertedField.getUnInvertedField() 
> 
>
> Key: SOLR-12155
> URL: https://issues.apache.org/jira/browse/SOLR-12155
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 7.2.1
>Reporter: Kishor gandham
>Assignee: Mikhail Khludnev
>Priority: Major
> Fix For: 7.4, master (8.0)
>
> Attachments: 21832-consoleText.txt.zip, SOLR-12155.master.patch, 
> SOLR-12155.patch, SOLR-12155.patch, SOLR-12155.patch, SOLR-12155.patch, 
> SOLR-12155.patch, SOLR-12155.patch, stack.txt
>
>
> I am attaching a stack trace from our production Solr (7.2.1). Occasionally, 
> we are seeing SOLR becoming unresponsive. We are then forced to kill the JVM 
> and start solr again.
> We have a lot of facet queries and our index has approximately 15 million 
> documents. We have recently started using json.facet queries and some of the 
> facet fields use DocValues.



--
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-12235) Incomplete debugQuery info when using edismax and boost param

[Bogdan Stoica (JIRA)]

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

Bogdan Stoica updated SOLR-12235:
-
Component/s: Schema and Analysis

> Incomplete debugQuery info when using edismax and boost param
> -
>
> Key: SOLR-12235
> URL: https://issues.apache.org/jira/browse/SOLR-12235
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Schema and Analysis, search
>Affects Versions: 7.3
> Environment: Solr 7.3.0, Java 1.8.0_162
>Reporter: Bogdan Stoica
>Priority: Minor
>
> There is an issue with the way SOLR 7.3 outputs explain information when 
> using edismax and 
> boost param.
>  
> Example query: 
> /select?boost=results=on=edismax=word=text
>  
> Solr 7.3 outputs:
>  
> {code:java}
>  
> 31349.63 = product of: 1.0 = boost 31349.63 = boost(double(results)) 
> {code}
>  
>  
> In comparrison, Solr 7.2.1 returns the following:
>  
> {code:java}
>  
> 31349.63 = boost(text:word,double(results)), product of: 14.400382 = 
> weight(text:word in 18142) [SchemaSimilarity], result of: 14.400382 = 
> score(doc=18142,freq=1.0 = termFreq=1.0 ), product of: 10.677335 = idf, 
> computed as log(1 + (docCount - docFreq + 0.5) / (docFreq + 0.5)) from: 6.0 = 
> docFreq 281851.0 = docCount 1.3486869 = tfNorm, computed as (freq * (k1 + 1)) 
> / (freq + k1 * (1 - b + b * fieldLength / avgFieldLength)) from: 1.0 = 
> termFreq=1.0 1.2 = parameter k1 0.75 = parameter b 2.7172585 = avgFieldLength 
> 1.0 = fieldLength 2177.0 = double(results)=2177.0 
> {code}
>  



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

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

[jira] [Commented] (SOLR-11990) Make it possible to co-locate replicas of multiple collections together in a node using policy

[Noble Paul (JIRA)]

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

Noble Paul commented on SOLR-11990:
---

The ideal syntax for such a feature would be

 
{code:java}
//place all replicas of collection 'comment' where collection 'article' is 
present

{"replica" :"#ALL", "collection" : "comment", "withCollection" :"article" }

{code}
With this feature
 * we expect the collection {{"article"}} to be created first. If {{"article"}} 
is not present creation of collection {{"comment"}} must fail
 * The collection {{"article"}} must have only one shard
 * when {{"comments"}} collection is created, it must first identify nodes 
where replicas are going to be created, and then it must go on and create 
replicas of {{"article"}} in all those nodes
 * When a new replica (or a shard)  is created for {{"comment"}} , it must do 
the same as create collection

 I seriously think it is a lot of work . We will have to change the way the 
collection APIs work. The way the rules are computed in the Policy framework 
also needs to change specifically for this use case. The APIs are not written 
to handle multiple collections simultaneously. I think it will be much easier 
if we just make this as a collection attribute  and deal it specially there. 
That way, we don't have to touch the Policy framework at all


> Make it possible to co-locate replicas of multiple collections together in a 
> node using policy
> --
>
> Key: SOLR-11990
> URL: https://issues.apache.org/jira/browse/SOLR-11990
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: AutoScaling, SolrCloud
>Reporter: Shalin Shekhar Mangar
>Assignee: Shalin Shekhar Mangar
>Priority: Major
> Fix For: 7.4, master (8.0)
>
> Attachments: SOLR-11990.patch, SOLR-11990.patch
>
>
> It is necessary to co-locate replicas of different collection together in a 
> node when cross-collection joins are performed. The policy rules framework 
> should support this use-case.
> Example: Co-locate exactly 1 replica of collection A in each node where a 
> replica of collection B is present.
> {code}
> {"replica":">0", "collection":"A", "shard":"#EACH", "withCollection":"B"}
> {code}
> This requires changing create collection, create shard and add replica APIs 
> as well because we want a replica of collection A to be created first before 
> a replica of collection B is created so that join queries etc are always 
> possible.



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

StreamExpressionTest.testNulls hangs for 3 days on Policeman Jenkins.

[Mikhail Khludnev]

https://jenkins.thetaphi.de/job/Lucene-Solr-master-Solaris/1804/console

I can't shoot it as I used to.

-- 
Sincerely yours
Mikhail Khludnev

[JENKINS] Lucene-Solr-7.x-Linux (32bit/jdk1.8.0_162) - Build # 1744 - Failure!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/1744/
Java: 32bit/jdk1.8.0_162 -server -XX:+UseG1GC

1 tests failed.
FAILED:  
org.apache.lucene.index.TestPendingSoftDeletes.testUpdateAppliedOnlyOnce

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

Stack Trace:
java.lang.AssertionError: expected:<1> but was:<2>
at 
__randomizedtesting.SeedInfo.seed([534121D77EFDCB0A:7E638ADEA75CBAAB]: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.lucene.index.TestPendingSoftDeletes.testUpdateAppliedOnlyOnce(TestPendingSoftDeletes.java:170)
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:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
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:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:748)




Build Log:
[...truncated 480 lines...]
   [junit4] Suite: org.apache.lucene.index.TestPendingSoftDeletes
   [junit4]   2> NOTE: reproduce with: ant test  
-Dtestcase=TestPendingSoftDeletes -Dtests.method=testUpdateAppliedOnlyOnce 
-Dtests.seed=534121D77EFDCB0A -Dtests.multiplier=3 -Dtests.slow=true 
-Dtests.locale=da -Dtests.timezone=Europe/Lisbon -Dtests.asserts=true 
-Dtests.file.encoding=US-ASCII
   [junit4] FAILURE 0.02s J2 | 

Re: [JENKINS] Lucene-Solr-master-Linux (64bit/jdk1.8.0_162) - Build # 21851 - Failure!

[Mikhail Khludnev]

pushed unused imports removal for both branches

On Wed, Apr 18, 2018 at 9:45 AM, Policeman Jenkins Server <
jenk...@thetaphi.de> wrote:

> Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/21851/
> Java: 64bit/jdk1.8.0_162 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC
>
> All tests passed
>
> Build Log:
> [...truncated 62189 lines...]
> -ecj-javadoc-lint-tests:
> [mkdir] Created dir: /tmp/ecj1465837151
>  [ecj-lint] Compiling 896 source files to /tmp/ecj1465837151
>  [ecj-lint] invalid Class-Path header in manifest of jar file:
> /home/jenkins/.ivy2/cache/org.restlet.jee/org.restlet/jars/
> org.restlet-2.3.0.jar
>  [ecj-lint] invalid Class-Path header in manifest of jar file:
> /home/jenkins/.ivy2/cache/org.restlet.jee/org.restlet.ext.
> servlet/jars/org.restlet.ext.servlet-2.3.0.jar
>  [ecj-lint] --
>  [ecj-lint] 1. WARNING in /home/jenkins/workspace/
> Lucene-Solr-master-Linux/solr/core/src/test/org/apache/solr/
> analysis/TokenizerChainTest.java (at line 37)
>  [ecj-lint] TokenizerChain tokenizerChain = new TokenizerChain(
>  [ecj-lint]^^
>  [ecj-lint] Resource leak: 'tokenizerChain' is never closed
>  [ecj-lint] --
>  [ecj-lint] --
>  [ecj-lint] 2. ERROR in /home/jenkins/workspace/
> Lucene-Solr-master-Linux/solr/core/src/test/org/apache/solr/cloud/DeleteReplicaTest.java
> (at line 31)
>  [ecj-lint] import java.util.function.Supplier;
>  [ecj-lint]^^^
>  [ecj-lint] The import java.util.function.Supplier is never used
>  [ecj-lint] --
>  [ecj-lint] --
>  [ecj-lint] 3. ERROR in /home/jenkins/workspace/
> Lucene-Solr-master-Linux/solr/core/src/test/org/apache/solr/cloud/ForceLeaderTest.java
> (at line 25)
>  [ecj-lint] import java.util.concurrent.TimeUnit;
>  [ecj-lint]^
>  [ecj-lint] The import java.util.concurrent.TimeUnit is never used
>  [ecj-lint] --
>  [ecj-lint] 4. ERROR in /home/jenkins/workspace/
> Lucene-Solr-master-Linux/solr/core/src/test/org/apache/solr/cloud/ForceLeaderTest.java
> (at line 26)
>  [ecj-lint] import java.util.stream.Collectors;
>  [ecj-lint]^^^
>  [ecj-lint] The import java.util.stream.Collectors is never used
>  [ecj-lint] --
>  [ecj-lint] 5. ERROR in /home/jenkins/workspace/
> Lucene-Solr-master-Linux/solr/core/src/test/org/apache/solr/cloud/ForceLeaderTest.java
> (at line 32)
>  [ecj-lint] import org.apache.solr.cloud.overseer.OverseerAction;
>  [ecj-lint]^
>  [ecj-lint] The import org.apache.solr.cloud.overseer.OverseerAction is
> never used
>  [ecj-lint] --
>  [ecj-lint] 6. ERROR in /home/jenkins/workspace/
> Lucene-Solr-master-Linux/solr/core/src/test/org/apache/solr/cloud/ForceLeaderTest.java
> (at line 38)
>  [ecj-lint] import org.apache.solr.common.cloud.ZkNodeProps;
>  [ecj-lint]
>  [ecj-lint] The import org.apache.solr.common.cloud.ZkNodeProps is never
> used
>  [ecj-lint] --
>  [ecj-lint] 7. ERROR in /home/jenkins/workspace/
> Lucene-Solr-master-Linux/solr/core/src/test/org/apache/solr/cloud/ForceLeaderTest.java
> (at line 39)
>  [ecj-lint] import org.apache.solr.common.cloud.ZkStateReader;
>  [ecj-lint]^^
>  [ecj-lint] The import org.apache.solr.common.cloud.ZkStateReader is
> never used
>  [ecj-lint] --
>  [ecj-lint] 8. ERROR in /home/jenkins/workspace/
> Lucene-Solr-master-Linux/solr/core/src/test/org/apache/solr/cloud/ForceLeaderTest.java
> (at line 41)
>  [ecj-lint] import org.apache.solr.common.util.Utils;
>  [ecj-lint]^
>  [ecj-lint] The import org.apache.solr.common.util.Utils is never used
>  [ecj-lint] --
>  [ecj-lint] --
>  [ecj-lint] 9. ERROR in /home/jenkins/workspace/
> Lucene-Solr-master-Linux/solr/core/src/test/org/apache/solr/cloud/MoveReplicaTest.java
> (at line 25)
>  [ecj-lint] import java.util.HashSet;
>  [ecj-lint]^
>  [ecj-lint] The import java.util.HashSet is never used
>  [ecj-lint] --
>  [ecj-lint] 10. ERROR in /home/jenkins/workspace/
> Lucene-Solr-master-Linux/solr/core/src/test/org/apache/solr/cloud/MoveReplicaTest.java
> (at line 42)
>  [ecj-lint] import org.apache.solr.common.cloud.
> CollectionStateWatcher;
>  [ecj-lint]^^^
>  [ecj-lint] The import org.apache.solr.common.cloud.CollectionStateWatcher
> is never used
>  [ecj-lint] --
>  [ecj-lint] 11. ERROR in /home/jenkins/workspace/
> Lucene-Solr-master-Linux/solr/core/src/test/org/apache/solr/cloud/MoveReplicaTest.java
> (at line 46)
>  [ecj-lint] import org.apache.solr.common.cloud.ZkStateReaderAccessor;
>  [ecj-lint]^^
> 

[jira] [Commented] (SOLR-12187) Replica should watch clusterstate and unload itself if its entry is removed

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-12187:


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

SOLR-12187: fix precommit


> Replica should watch clusterstate and unload itself if its entry is removed
> ---
>
> Key: SOLR-12187
> URL: https://issues.apache.org/jira/browse/SOLR-12187
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Cao Manh Dat
>Assignee: Cao Manh Dat
>Priority: Major
> Attachments: SOLR-12187.patch, SOLR-12187.patch, SOLR-12187.patch, 
> SOLR-12187.patch, SOLR-12187.patch, SOLR-12187.patch
>
>
> With the introduction of autoscaling framework, we have seen an increase in 
> the number of issues related to the race condition between delete a replica 
> and other stuff.
> Case 1: DeleteReplicaCmd failed to send UNLOAD request to a replica, 
> therefore, forcefully remove its entry from clusterstate, but the replica 
> still function normally and be able to become a leader -> SOLR-12176
> Case 2:
>  * DeleteReplicaCmd enqueue a DELETECOREOP (without sending a request to 
> replica because the node is not live)
>  * The node start and the replica get loaded
>  * DELETECOREOP has not processed hence the replica still present in 
> clusterstate --> pass checkStateInZk
>  * DELETECOREOP is executed, DeleteReplicaCmd finished
>  ** result 1: the replica start recovering, finish it and publish itself as 
> ACTIVE --> state of the replica is ACTIVE
>  ** result 2: the replica throw an exception (probably: NPE) 
> --> state of the replica is DOWN, not join leader election



--
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-12200) ZkControllerTest failure. Leaking Overseer

[Lucene/Solr QA (JIRA)]

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

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

| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
|| || || || {color:brown} Prechecks {color} ||
| {color:red}-1{color} | {color:red} test4tests {color} | {color:red}  0m  
0s{color} | {color:red} The patch doesn't appear to include any new or modified 
tests. Please justify why no new tests are needed for this patch. Also please 
list what manual steps were performed to verify this patch. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  1m 
18s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  1m 
14s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green}  1m 
14s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Release audit (RAT) {color} | 
{color:green}  1m 14s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Check forbidden APIs {color} | 
{color:green}  1m 14s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Validate source patterns {color} | 
{color:green}  1m 14s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 50m  3s{color} 
| {color:red} core in the patch failed. {color} |
| {color:black}{color} | {color:black} {color} | {color:black} 55m 11s{color} | 
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | solr.cloud.TestLeaderElectionZkExpiry |
|   | solr.cloud.api.collections.CollectionReloadTest |
|   | solr.cloud.OverseerRolesTest |
|   | solr.cloud.TestAuthenticationFramework |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | SOLR-12200 |
| JIRA Patch URL | 
https://issues.apache.org/jira/secure/attachment/12919479/SOLR-12200.patch |
| Optional Tests |  compile  javac  unit  ratsources  checkforbiddenapis  
validatesourcepatterns  |
| uname | Linux lucene1-us-west 3.13.0-88-generic #135-Ubuntu SMP Wed Jun 8 
21:10:42 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | ant |
| Personality | 
/home/jenkins/jenkins-slave/workspace/PreCommit-SOLR-Build/sourcedir/dev-tools/test-patch/lucene-solr-yetus-personality.sh
 |
| git revision | master / 1d24414 |
| ant | version: Apache Ant(TM) version 1.9.3 compiled on April 8 2014 |
| Default Java | 1.8.0_152 |
| unit | 
https://builds.apache.org/job/PreCommit-SOLR-Build/60/artifact/out/patch-unit-solr_core.txt
 |
|  Test Results | 
https://builds.apache.org/job/PreCommit-SOLR-Build/60/testReport/ |
| modules | C: solr/core U: solr/core |
| Console output | 
https://builds.apache.org/job/PreCommit-SOLR-Build/60/console |
| Powered by | Apache Yetus 0.7.0   http://yetus.apache.org |


This message was automatically generated.



> ZkControllerTest failure. Leaking Overseer
> --
>
> Key: SOLR-12200
> URL: https://issues.apache.org/jira/browse/SOLR-12200
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Reporter: Mikhail Khludnev
>Priority: Major
> Attachments: SOLR-12200.patch, SOLR-12200.patch, SOLR-12200.patch, 
> patch-unit-solr_core.zip, tests-failures.txt, tests-failures.txt.gz, 
> zk.fail.txt.gz
>
>
> Failure seems suspiciously the same. 
>[junit4]   2> 499919 INFO  
> (TEST-ZkControllerTest.testReadConfigName-seed#[BC856CC565039E77]) 
> [n:127.0.0.1:8983_solr] o.a.s.c.Overseer Overseer 
> (id=73578760132362243-127.0.0.1:8983_solr-n_00) closing
>[junit4]   2> 499920 INFO  
> (OverseerStateUpdate-73578760132362243-127.0.0.1:8983_solr-n_00) [
> ] o.a.s.c.Overseer Overseer Loop exiting : 127.0.0.1:8983_solr
>[junit4]   2> 499920 ERROR 
> (OverseerCollectionConfigSetProcessor-73578760132362243-127.0.0.1:8983_solr-n_00)
>  [] o.a.s.c.OverseerTaskProcessor Unable to prioritize overseer
>[junit4]   2> java.lang.InterruptedException: null
>[junit4]   2>at java.lang.Object.wait(Native Method) ~[?:1.8.0_152]
>[junit4]   2>at java.lang.Object.wait(Object.java:502) 
> ~[?:1.8.0_152]
>[junit4]   2>at 
> org.apache.zookeeper.ClientCnxn.submitRequest(ClientCnxn.java:1409) 
> ~[zookeeper-3.4.11.jar:3.4
> then it spins in SessionExpiredException, all tests pass but suite fails due 
> to leaking Overseer. 



--
This message was sent by Atlassian 

[jira] [Commented] (SOLR-12187) Replica should watch clusterstate and unload itself if its entry is removed

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-12187:


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

SOLR-12187: fix precommit


> Replica should watch clusterstate and unload itself if its entry is removed
> ---
>
> Key: SOLR-12187
> URL: https://issues.apache.org/jira/browse/SOLR-12187
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Cao Manh Dat
>Assignee: Cao Manh Dat
>Priority: Major
> Attachments: SOLR-12187.patch, SOLR-12187.patch, SOLR-12187.patch, 
> SOLR-12187.patch, SOLR-12187.patch, SOLR-12187.patch
>
>
> With the introduction of autoscaling framework, we have seen an increase in 
> the number of issues related to the race condition between delete a replica 
> and other stuff.
> Case 1: DeleteReplicaCmd failed to send UNLOAD request to a replica, 
> therefore, forcefully remove its entry from clusterstate, but the replica 
> still function normally and be able to become a leader -> SOLR-12176
> Case 2:
>  * DeleteReplicaCmd enqueue a DELETECOREOP (without sending a request to 
> replica because the node is not live)
>  * The node start and the replica get loaded
>  * DELETECOREOP has not processed hence the replica still present in 
> clusterstate --> pass checkStateInZk
>  * DELETECOREOP is executed, DeleteReplicaCmd finished
>  ** result 1: the replica start recovering, finish it and publish itself as 
> ACTIVE --> state of the replica is ACTIVE
>  ** result 2: the replica throw an exception (probably: NPE) 
> --> state of the replica is DOWN, not join leader election



--
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-12235) Incomplete debugQuery info when using edismax and boost param

[Bogdan Stoica (JIRA)]

Bogdan Stoica created SOLR-12235:


 Summary: Incomplete debugQuery info when using edismax and boost 
param
 Key: SOLR-12235
 URL: https://issues.apache.org/jira/browse/SOLR-12235
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
  Components: search
Affects Versions: 7.3
 Environment: Solr 7.3.0, Java 1.8.0_162
Reporter: Bogdan Stoica


There is an issue with the way SOLR 7.3 outputs explain information when using 
edismax and 
boost param.
 
Example query: 
/select?boost=results=on=edismax=word=text
 
Solr 7.3 outputs:
 
{code:java}
 
31349.63 = product of: 1.0 = boost 31349.63 = boost(double(results)) 
{code}
 
 
In comparrison, Solr 7.2.1 returns the following:
 
{code:java}
 
31349.63 = boost(text:word,double(results)), product of: 14.400382 = 
weight(text:word in 18142) [SchemaSimilarity], result of: 14.400382 = 
score(doc=18142,freq=1.0 = termFreq=1.0 ), product of: 10.677335 = idf, 
computed as log(1 + (docCount - docFreq + 0.5) / (docFreq + 0.5)) from: 6.0 = 
docFreq 281851.0 = docCount 1.3486869 = tfNorm, computed as (freq * (k1 + 1)) / 
(freq + k1 * (1 - b + b * fieldLength / avgFieldLength)) from: 1.0 = 
termFreq=1.0 1.2 = parameter k1 0.75 = parameter b 2.7172585 = avgFieldLength 
1.0 = fieldLength 2177.0 = double(results)=2177.0 
{code}
 



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

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

[jira] [Resolved] (SOLR-12181) Add trigger based on document count

[Andrzej Bialecki (JIRA)]

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

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

> Add trigger based on document count
> ---
>
> Key: SOLR-12181
> URL: https://issues.apache.org/jira/browse/SOLR-12181
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: AutoScaling
>Affects Versions: master (8.0)
>Reporter: Andrzej Bialecki 
>Assignee: Andrzej Bialecki 
>Priority: Major
> Fix For: 7.4, master (8.0)
>
> Attachments: SOLR-12181.patch
>
>
> This may turn out to be as simple as using a {{MetricTrigger}} but it's 
> likely this will require some specialization, and we may want to add this 
> type of trigger anyway for convenience.
> The two control actions associated with this trigger will be SPLITSHARD and 
> (yet nonexistent) MERGESHARD.



--
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-12234) group by not working for inner joins

[krishna prasad (JIRA)]

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

krishna prasad commented on SOLR-12234:
---

can anyone give me solution for this.

> group by not working for inner joins
> 
>
> Key: SOLR-12234
> URL: https://issues.apache.org/jira/browse/SOLR-12234
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: clients - java
>Affects Versions: 6.0
>Reporter: krishna prasad
>Priority: Major
> Attachments: file.xml
>
>
> when I check status as open its returning requested 1 doc but it should not 
> return return requested 1 because in the last action status as closed. Please 
> advice how we can search.



--
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 # 519 - Still Unstable

[Apache Jenkins Server]

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

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

[repro] Revision: d904112428184ce9c1726313add5d184f4014a72

[repro] Repro line:  ant test  -Dtestcase=TestTlogReplica 
-Dtests.method=testCreateDelete -Dtests.seed=593BAAB11F2DD441 
-Dtests.multiplier=2 -Dtests.slow=true -Dtests.locale=sq-AL 
-Dtests.timezone=America/Godthab -Dtests.asserts=true 
-Dtests.file.encoding=ISO-8859-1

[repro] Repro line:  ant test  -Dtestcase=TestTlogReplica 
-Dtests.method=testCreateDelete -Dtests.seed=593BAAB11F2DD441 
-Dtests.multiplier=2 -Dtests.slow=true -Dtests.locale=sq-AL 
-Dtests.timezone=America/Godthab -Dtests.asserts=true 
-Dtests.file.encoding=ISO-8859-1

[repro] Encountered IncompleteRead exception, pausing and then retrying...
[repro] Jenkins log URL: 
https://builds.apache.org/job/Lucene-Solr-Tests-master/2492/consoleText

[repro] Revision: d904112428184ce9c1726313add5d184f4014a72

[repro] Repro line:  ant test  -Dtestcase=TestTlogReplica 
-Dtests.method=testCreateDelete -Dtests.seed=593BAAB11F2DD441 
-Dtests.multiplier=2 -Dtests.slow=true -Dtests.locale=sq-AL 
-Dtests.timezone=America/Godthab -Dtests.asserts=true 
-Dtests.file.encoding=ISO-8859-1

[repro] Repro line:  ant test  -Dtestcase=TestTlogReplica 
-Dtests.method=testCreateDelete -Dtests.seed=593BAAB11F2DD441 
-Dtests.multiplier=2 -Dtests.slow=true -Dtests.locale=sq-AL 
-Dtests.timezone=America/Godthab -Dtests.asserts=true 
-Dtests.file.encoding=ISO-8859-1

[repro] Repro line:  ant test  -Dtestcase=ZkControllerTest 
-Dtests.seed=593BAAB11F2DD441 -Dtests.multiplier=2 -Dtests.slow=true 
-Dtests.locale=th-TH -Dtests.timezone=Etc/GMT-10 -Dtests.asserts=true 
-Dtests.file.encoding=ISO-8859-1

[repro] git rev-parse --abbrev-ref HEAD
[repro] git rev-parse HEAD
[repro] Initial local git branch/revision: 
1d2441441be5f5d87103ceeec6d852f8f2f6ba85
[repro] git fetch

[...truncated 2 lines...]
[repro] git checkout d904112428184ce9c1726313add5d184f4014a72

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

[...truncated 3298 lines...]
[repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=10 
-Dtests.class="*.TestTlogReplica|*.ZkControllerTest" -Dtests.showOutput=onerror 
 -Dtests.seed=593BAAB11F2DD441 -Dtests.multiplier=2 -Dtests.slow=true 
-Dtests.locale=sq-AL -Dtests.timezone=America/Godthab -Dtests.asserts=true 
-Dtests.file.encoding=ISO-8859-1

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

[repro] Failures:
[repro]   0/5 failed: org.apache.solr.cloud.ZkControllerTest
[repro]   1/5 failed: org.apache.solr.cloud.TestTlogReplica
[repro] git checkout 1d2441441be5f5d87103ceeec6d852f8f2f6ba85

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

[JENKINS] Lucene-Solr-Tests-master - Build # 2493 - Still Failing

[Apache Jenkins Server]

Error processing tokens: Error while parsing action 
'Text/ZeroOrMore/FirstOf/Token/DelimitedToken/DelimitedToken_Action3' at input 
position (line 76, pos 4):
)"}
   ^

java.lang.OutOfMemoryError: Java heap space

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

[jira] [Updated] (SOLR-11718) Deprecate CDCR Buffer APIs

[Amrit Sarkar (JIRA)]

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

Amrit Sarkar updated SOLR-11718:

Attachment: SOLR-11718.patch

> Deprecate CDCR Buffer APIs
> --
>
> Key: SOLR-11718
> URL: https://issues.apache.org/jira/browse/SOLR-11718
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: CDCR
>Reporter: Amrit Sarkar
>Assignee: Varun Thacker
>Priority: Major
> Fix For: 7.4, master (8.0)
>
> Attachments: SOLR-11718.patch, SOLR-11718.patch
>
>
> Kindly see the discussion on SOLR-11652.
> Today, if we see the current CDCR documentation page, buffering is "disabled" 
> by default in both source and target. We don't see any purpose served by Cdcr 
> buffering and it is quite an overhead considering it can take a lot heap 
> space (tlogs ptr) and forever retention of tlogs on the disk when enabled. 
> Also today, even if we disable buffer from API on source , considering it was 
> enabled at startup, tlogs are never purged on leader node of shards of 
> source, refer jira: SOLR-11652



--
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-7867) implicit sharded, facet grouping problem with multivalued string field starting with digits

[Jay (JIRA)]

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

Jay commented on SOLR-7867:
---

I am seeing similar error in Solr 5.3 & 6.6.3. In my case, the error happens 
intermittently and all the values are alphanumeric (don't start with digit as 
reported above). Reindexing the document seems to address the issue. Have not 
been able to verify if it happens after reindexing it.

> implicit sharded, facet grouping problem with multivalued string field 
> starting with digits
> ---
>
> Key: SOLR-7867
> URL: https://issues.apache.org/jira/browse/SOLR-7867
> Project: Solr
>  Issue Type: Bug
>  Components: faceting, SolrCloud
>Affects Versions: 5.2
> Environment: 3.13.0-48-generic #80-Ubuntu SMP x86_64 GNU/Linux
> java version "1.7.0_80"
> Java(TM) SE Runtime Environment (build 1.7.0_80-b15)
> Java HotSpot(TM) 64-Bit Server VM (build 24.80-b11, mixed mode)
>Reporter: Umut Erogul
>Priority: Major
>  Labels: docValues, facet, group, sharding
> Attachments: DocValuesException.PNG, ErrorReadingDocValues.PNG
>
>
> related parts @ schema.xml:
> {code} docValues="true" multiValued="true"/>
>  docValues="true"/>{code}
> every document has valid author_s and keyword_ss fields;
> we can make successful facet group queries on single node, single collection, 
> solr-4.9.0 server
> {code}
> q: *:* fq: keyword_ss:3m
> facet=true=keyword_ss=true=author_s=true
> {code}
> when querying on solr-5.2.0 server with implicit sharded environment with:
> {code}
>  required="true"/>{code}
> with example shard names; affinity1 affinity2 affinity3 affinity4
> the same query with same documents gets:
> {code}
> ERROR - 2015-08-04 08:15:15.222; [document affinity3 core_node32 
> document_affinity3_replica2] org.apache.solr.common.SolrException; 
> org.apache.solr.common.SolrException: Exception during facet.field: keyword_ss
> at org.apache.solr.request.SimpleFacets$3.call(SimpleFacets.java:632)
> at org.apache.solr.request.SimpleFacets$3.call(SimpleFacets.java:617)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> at 
> org.apache.solr.request.SimpleFacets$2.execute(SimpleFacets.java:571)
> at 
> org.apache.solr.request.SimpleFacets.getFacetFieldCounts(SimpleFacets.java:642)
> ...
> at 
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.ArrayIndexOutOfBoundsException
> at 
> org.apache.lucene.codecs.lucene50.Lucene50DocValuesProducer$CompressedBinaryDocValues$CompressedBinaryTermsEnum.readTerm(Lucene50DocValuesProducer.java:1008)
> at 
> org.apache.lucene.codecs.lucene50.Lucene50DocValuesProducer$CompressedBinaryDocValues$CompressedBinaryTermsEnum.next(Lucene50DocValuesProducer.java:1026)
> at 
> org.apache.lucene.search.grouping.term.TermGroupFacetCollector$MV$SegmentResult.nextTerm(TermGroupFacetCollector.java:373)
> at 
> org.apache.lucene.search.grouping.AbstractGroupFacetCollector.mergeSegmentResults(AbstractGroupFacetCollector.java:91)
> at 
> org.apache.solr.request.SimpleFacets.getGroupedCounts(SimpleFacets.java:541)
> at 
> org.apache.solr.request.SimpleFacets.getTermCounts(SimpleFacets.java:463)
> at 
> org.apache.solr.request.SimpleFacets.getTermCounts(SimpleFacets.java:386)
> at org.apache.solr.request.SimpleFacets$3.call(SimpleFacets.java:626)
> ... 33 more
> {code}
> all the problematic queries are caused by strings starting with digits; 
> ("3m", "8 saniye", "2 broke girls", "1v1y")
> there are some strings that the query works like ("24", "90+", "45 dakika")
> we do not observe the problem when querying with 
> -keyword_ss:(0-9)*
> updating the problematic documents (a small subset of keyword_ss:(0-9)*), 
> fixes the query, 
> but we cannot find an easy solution to find the problematic documents
> there is around 400m docs; seperated at 28 shards; 
> -keyword_ss:(0-9)* matches %97 of documents



--
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-12234) group by not working for inner joins

[krishna prasad (JIRA)]

krishna prasad created SOLR-12234:
-

 Summary: group by not working for inner joins
 Key: SOLR-12234
 URL: https://issues.apache.org/jira/browse/SOLR-12234
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
  Components: clients - java
Affects Versions: 6.0
Reporter: krishna prasad
 Attachments: file.xml

when I check status as open its returning requested 1 doc but it should not 
return return requested 1 because in the last action status as closed. Please 
advice how we can search.



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

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

[JENKINS] Lucene-Solr-master-Linux (64bit/jdk1.8.0_162) - Build # 21851 - Failure!

[Policeman Jenkins Server]

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

All tests passed

Build Log:
[...truncated 62189 lines...]
-ecj-javadoc-lint-tests:
[mkdir] Created dir: /tmp/ecj1465837151
 [ecj-lint] Compiling 896 source files to /tmp/ecj1465837151
 [ecj-lint] invalid Class-Path header in manifest of jar file: 
/home/jenkins/.ivy2/cache/org.restlet.jee/org.restlet/jars/org.restlet-2.3.0.jar
 [ecj-lint] invalid Class-Path header in manifest of jar file: 
/home/jenkins/.ivy2/cache/org.restlet.jee/org.restlet.ext.servlet/jars/org.restlet.ext.servlet-2.3.0.jar
 [ecj-lint] --
 [ecj-lint] 1. WARNING in 
/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/core/src/test/org/apache/solr/analysis/TokenizerChainTest.java
 (at line 37)
 [ecj-lint] TokenizerChain tokenizerChain = new TokenizerChain(
 [ecj-lint]^^
 [ecj-lint] Resource leak: 'tokenizerChain' is never closed
 [ecj-lint] --
 [ecj-lint] --
 [ecj-lint] 2. ERROR in 
/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/core/src/test/org/apache/solr/cloud/DeleteReplicaTest.java
 (at line 31)
 [ecj-lint] import java.util.function.Supplier;
 [ecj-lint]^^^
 [ecj-lint] The import java.util.function.Supplier is never used
 [ecj-lint] --
 [ecj-lint] --
 [ecj-lint] 3. ERROR in 
/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/core/src/test/org/apache/solr/cloud/ForceLeaderTest.java
 (at line 25)
 [ecj-lint] import java.util.concurrent.TimeUnit;
 [ecj-lint]^
 [ecj-lint] The import java.util.concurrent.TimeUnit is never used
 [ecj-lint] --
 [ecj-lint] 4. ERROR in 
/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/core/src/test/org/apache/solr/cloud/ForceLeaderTest.java
 (at line 26)
 [ecj-lint] import java.util.stream.Collectors;
 [ecj-lint]^^^
 [ecj-lint] The import java.util.stream.Collectors is never used
 [ecj-lint] --
 [ecj-lint] 5. ERROR in 
/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/core/src/test/org/apache/solr/cloud/ForceLeaderTest.java
 (at line 32)
 [ecj-lint] import org.apache.solr.cloud.overseer.OverseerAction;
 [ecj-lint]^
 [ecj-lint] The import org.apache.solr.cloud.overseer.OverseerAction is never 
used
 [ecj-lint] --
 [ecj-lint] 6. ERROR in 
/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/core/src/test/org/apache/solr/cloud/ForceLeaderTest.java
 (at line 38)
 [ecj-lint] import org.apache.solr.common.cloud.ZkNodeProps;
 [ecj-lint]
 [ecj-lint] The import org.apache.solr.common.cloud.ZkNodeProps is never used
 [ecj-lint] --
 [ecj-lint] 7. ERROR in 
/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/core/src/test/org/apache/solr/cloud/ForceLeaderTest.java
 (at line 39)
 [ecj-lint] import org.apache.solr.common.cloud.ZkStateReader;
 [ecj-lint]^^
 [ecj-lint] The import org.apache.solr.common.cloud.ZkStateReader is never used
 [ecj-lint] --
 [ecj-lint] 8. ERROR in 
/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/core/src/test/org/apache/solr/cloud/ForceLeaderTest.java
 (at line 41)
 [ecj-lint] import org.apache.solr.common.util.Utils;
 [ecj-lint]^
 [ecj-lint] The import org.apache.solr.common.util.Utils is never used
 [ecj-lint] --
 [ecj-lint] --
 [ecj-lint] 9. ERROR in 
/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/core/src/test/org/apache/solr/cloud/MoveReplicaTest.java
 (at line 25)
 [ecj-lint] import java.util.HashSet;
 [ecj-lint]^
 [ecj-lint] The import java.util.HashSet is never used
 [ecj-lint] --
 [ecj-lint] 10. ERROR in 
/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/core/src/test/org/apache/solr/cloud/MoveReplicaTest.java
 (at line 42)
 [ecj-lint] import org.apache.solr.common.cloud.CollectionStateWatcher;
 [ecj-lint]^^^
 [ecj-lint] The import org.apache.solr.common.cloud.CollectionStateWatcher is 
never used
 [ecj-lint] --
 [ecj-lint] 11. ERROR in 
/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/core/src/test/org/apache/solr/cloud/MoveReplicaTest.java
 (at line 46)
 [ecj-lint] import org.apache.solr.common.cloud.ZkStateReaderAccessor;
 [ecj-lint]^^
 [ecj-lint] The import org.apache.solr.common.cloud.ZkStateReaderAccessor is 
never used
 [ecj-lint] --
 [ecj-lint] 11 problems (10 errors, 1 warning)

BUILD FAILED
/home/jenkins/workspace/Lucene-Solr-master-Linux/build.xml:633: The following 
error occurred while executing this line: