[JENKINS-EA] Lucene-Solr-6.4-Linux (64bit/jdk-9-ea+153) - Build # 81 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.4-Linux/81/
Java: 64bit/jdk-9-ea+153 -XX:+UseCompressedOops -XX:+UseSerialGC

1 tests failed.
FAILED:  org.apache.solr.cloud.CollectionsAPISolrJTest.testCreateAndDeleteShard

Error Message:
Error from server at https://127.0.0.1:35873/solr: Could not fully remove 
collection: solrj_implicit

Stack Trace:
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at https://127.0.0.1:35873/solr: Could not fully remove collection: 
solrj_implicit
at 
__randomizedtesting.SeedInfo.seed([309FE2A69894222:C6574A36EF7C88DF]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:610)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:279)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:268)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:435)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:387)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1344)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:1095)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:1037)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:149)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:166)
at 
org.apache.solr.cloud.CollectionsAPISolrJTest.testCreateAndDeleteShard(CollectionsAPISolrJTest.java:100)
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:543)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
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:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:811)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:462)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
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 

[jira] (SOLR-10060) Add test for implicit commit of uncommitted docs aged out of the transient cache.

[ASF subversion and git services (JIRA)]

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 ASF subversion and git services commented on  SOLR-10060 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
  Re: Add test for implicit commit of uncommitted docs aged out of the transient cache.  
 
 
 
 
 
 
 
 
 
 
Commit a8b1c8ba0d6ebf244af81e3ff0870d1d4fbe7a1d in lucene-solr's branch refs/heads/branch_6x from Erick Erickson [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=a8b1c8b ] 


SOLR-10060
: Add test for implicit commit of uncommitted docs aged out of the transient cache. 
(cherry picked from commit 0ccce22) 
 
 
 
 
 
 
 
 
 
 
 
 

 
 Add Comment 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 
 
 

 This message was sent by Atlassian JIRA (v6.3.15#6346-sha1:dbc023d) 
 
 
 
 
  
 
 
 
 
 
 
 
 
   

[jira] (SOLR-10060) Add test for implicit commit of uncommitted docs aged out of the transient cache.

[Erick Erickson (JIRA)]

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Erick Erickson closed an issue as Fixed 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 Solr /  SOLR-10060 
 
 
 
  Add test for implicit commit of uncommitted docs aged out of the transient cache.  
 
 
 
 
 
 
 
 
 

Change By:
 
 Erick Erickson 
 
 
 

Resolution:
 
 Fixed 
 
 
 

Fix Version/s:
 
 6.5 
 
 
 

Fix Version/s:
 
 trunk 
 
 
 

Status:
 
 Open Closed 
 
 
 
 
 
 
 
 
 
 
 
 

 
 Add Comment 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 
 
 

 This message was sent by Atlassian JIRA (v6.3.15#6346-sha1:dbc023d) 
 
 
 
 
  
 
 
 
 
 
 
 
 
   

[jira] (SOLR-10060) Add test for implicit commit of uncommitted docs aged out of the transient cache.

[ASF subversion and git services (JIRA)]

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 ASF subversion and git services commented on  SOLR-10060 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
  Re: Add test for implicit commit of uncommitted docs aged out of the transient cache.  
 
 
 
 
 
 
 
 
 
 
Commit 0ccce22fcd8afa8ad7befa95e0f246e896a788c2 in lucene-solr's branch refs/heads/master from Erick Erickson [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=0ccce22 ] 
SOLR-10060: Add test for implicit commit of uncommitted docs aged out of the transient cache. 
 
 
 
 
 
 
 
 
 
 
 
 

 
 Add Comment 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 
 
 

 This message was sent by Atlassian JIRA (v6.3.15#6346-sha1:dbc023d) 
 
 
 
 
  
 
 
 
 
 
 
 
 
   

[jira] (SOLR-10061) Core admin API documentation needs to be updated

[Erick Erickson (JIRA)]

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Erick Erickson created an issue 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 Solr /  SOLR-10061 
 
 
 
  Core admin API documentation needs to be updated  
 
 
 
 
 
 
 
 
 

Issue Type:
 
  Improvement 
 
 
 

Assignee:
 

 Unassigned 
 
 
 

Created:
 

 31/Jan/17 06:34 
 
 
 

Priority:
 
  Major 
 
 
 

Reporter:
 
 Erick Erickson 
 
 
 

Security Level:
 

 Public (Default Security Level. Issues are Public) 
 
 
 
 
 
 
 
 
 
 
There are some problems with it, particularly in the areas of still referencing  in solr.xml and commingling stand-alone and SolrCloud. 
1> A number of the commands say things like "The name of the new core. Same as "name" on the  element." CREATE, STATUS, UNLOAD at least.  hasn't been supported for a while. 
2> the CREATE command in particular is confusing about what instanceDir is all about and how it relates to dataDir. What should be in instanceDir? core.properties? config files (unless configset is specified)? etc. 
3> CREATE also lists SolrCloud options. Perhaps mark these as "expert"? I suspect putting these params in just plain like they are contributes to people trying to use the core admin API when they should be using the Collections API in SolrCloud mode. 
This has been true for a while, so there's no need to hold up 6.4 docs for this. 
 
 
 
 
 
 
 
 
 
 
  

[jira] (SOLR-10054) Core swapping doesn't work with new metrics changes in place

[Andrzej Bialecki (JIRA)]

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Andrzej Bialecki  assigned an issue to Andrzej Bialecki  
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 Solr /  SOLR-10054 
 
 
 
  Core swapping doesn't work with new metrics changes in place  
 
 
 
 
 
 
 
 
 

Change By:
 
 Andrzej Bialecki  
 
 
 

Assignee:
 
 Andrzej Bialecki  
 
 
 
 
 
 
 
 
 
 
 
 

 
 Add Comment 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 
 
 

 This message was sent by Atlassian JIRA (v6.3.15#6346-sha1:dbc023d) 
 
 
 
 
  
 
 
 
 
 
 
 
 
   

[jira] (SOLR-6246) Core fails to reload when AnalyzingInfixSuggester is used as a Suggester

[Steve Rowe (JIRA)]

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Steve Rowe commented on  SOLR-6246 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
  Re: Core fails to reload when AnalyzingInfixSuggester is used as a Suggester  
 
 
 
 
 
 
 
 
 
 
I filed LUCENE-7670 to address an issue I see with tests: a second core reload after a suggester build will trigger the failures mentioned above, because suggesters opened over already-built indexes were creating an IndexWriter just to create a SearcherManager, thus locking the index directory. 
 
 
 
 
 
 
 
 
 
 
 
 

 
 Add Comment 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 
 
 

 This message was sent by Atlassian JIRA (v6.3.15#6346-sha1:dbc023d) 
 
 
 
 
  
 
 
 
 
 
 
 
 
   

Re: 6.4.1

[Steve Rowe]

Hi Adrien,

I’d like to include LUCENE-7670 in 6.4.1 - is that ok with you?

--
Steve
www.lucidworks.com

> On Jan 30, 2017, at 1:14 PM, Adrien Grand  wrote:
> 
> Thanks Steve, I had looked at whether there were existing infra issues but 
> had not thought about looking at their mailing-list. I'll have a look 
> tomorrow at whether the GPG import succeeded.
> 
> Le lun. 30 janv. 2017 à 19:06, Steve Rowe  a écrit :
> FYI yesterday morning on the users@infra mailing list, sebb posted with 
> subject “committers keys job failed last night”:
> 
> > As some of you may have noticed, the committers pgp keys job did not
> > retrieve any keys last night.
> >
> > I made a change to use gpg instead of curl for downloading keys.
> > Unfortunately it looks like the gpg version on home.apache.org is not
> > as up to date as the version I tested on, and one of the options did
> > not work.
> >
> > Hopefully the code is now fixed to work on the older version, but we
> > won't know until tomorrow as the job only runs once a day.
> 
> --
> Steve
> www.lucidworks.com
> 
> > On Jan 30, 2017, at 12:46 PM, Adrien Grand  wrote:
> >
> > There is an issue with GPG keys that prevents me from building a first RC: 
> > https://issues.apache.org/jira/browse/INFRA-13427. I'll monitor that issue 
> > and build a RC once it is resolved.
> >
> > Le jeu. 26 janv. 2017 à 16:01, Adrien Grand  a écrit :
> > +1 to get the change in if it is safe.
> >
> > Le jeu. 26 janv. 2017 à 15:59, Shawn Heisey  a écrit :
> > On 1/25/2017 4:40 AM, Adrien Grand wrote:
> > > These are annoying bugs so I would like to do a 6.4.1 release that
> > > includes these fixes.
> >
> > The immediate simple fix for SOLR-10035 is a one-liner.  Even the larger
> > fix of including redundant information that preserves backward API
> > compatibility would be very safe.
> >
> > Thanks,
> > Shawn
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> > For additional commands, e-mail: dev-h...@lucene.apache.org
> >
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
> 


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

[jira] (LUCENE-7670) AnalyzingInfixSuggester should not immediately open an IndexWriter over an already-built index

[ASF subversion and git services (JIRA)]

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 ASF subversion and git services commented on  LUCENE-7670 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
  Re: AnalyzingInfixSuggester should not immediately open an IndexWriter over an already-built index  
 
 
 
 
 
 
 
 
 
 
Commit dbcfe698706fc2a87199f913bfd2185147b75e62 in lucene-solr's branch refs/heads/branch_6x from Steve Rowe [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=dbcfe69 ] 
LUCENE-7670: AnalyzingInfixSuggester should not immediately open an IndexWriter over an already-built index 
 
 
 
 
 
 
 
 
 
 
 
 

 
 Add Comment 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 
 
 

 This message was sent by Atlassian JIRA (v6.3.15#6346-sha1:dbc023d) 
 
 
 
 
  
 
 
 
 
 
 
 
 
   

[jira] (LUCENE-7670) AnalyzingInfixSuggester should not immediately open an IndexWriter over an already-built index

[ASF subversion and git services (JIRA)]

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 ASF subversion and git services commented on  LUCENE-7670 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
  Re: AnalyzingInfixSuggester should not immediately open an IndexWriter over an already-built index  
 
 
 
 
 
 
 
 
 
 
Commit 967b66fb5bf08c876632ada63751027b8efce5dc in lucene-solr's branch refs/heads/branch_6x from Steve Rowe [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=967b66f ] 
LUCENE-7670: changes entry 
 
 
 
 
 
 
 
 
 
 
 
 

 
 Add Comment 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 
 
 

 This message was sent by Atlassian JIRA (v6.3.15#6346-sha1:dbc023d) 
 
 
 
 
  
 
 
 
 
 
 
 
 
   

[jira] (LUCENE-7670) AnalyzingInfixSuggester should not immediately open an IndexWriter over an already-built index

[ASF subversion and git services (JIRA)]

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 ASF subversion and git services commented on  LUCENE-7670 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
  Re: AnalyzingInfixSuggester should not immediately open an IndexWriter over an already-built index  
 
 
 
 
 
 
 
 
 
 
Commit 33861527914770b556528b66c90bc6ed421c2034 in lucene-solr's branch refs/heads/master from Steve Rowe [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=3386152 ] 
LUCENE-7670: changes entry 
 
 
 
 
 
 
 
 
 
 
 
 

 
 Add Comment 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 
 
 

 This message was sent by Atlassian JIRA (v6.3.15#6346-sha1:dbc023d) 
 
 
 
 
  
 
 
 
 
 
 
 
 
   

[jira] (LUCENE-7670) AnalyzingInfixSuggester should not immediately open an IndexWriter over an already-built index

[ASF subversion and git services (JIRA)]

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 ASF subversion and git services commented on  LUCENE-7670 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
  Re: AnalyzingInfixSuggester should not immediately open an IndexWriter over an already-built index  
 
 
 
 
 
 
 
 
 
 
Commit c1fe88b7c6fa861d5101f9702a7832d29b8032ee in lucene-solr's branch refs/heads/master from Steve Rowe [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=c1fe88b ] 
LUCENE-7670: AnalyzingInfixSuggester should not immediately open an IndexWriter over an already-built index 
 
 
 
 
 
 
 
 
 
 
 
 

 
 Add Comment 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 
 
 

 This message was sent by Atlassian JIRA (v6.3.15#6346-sha1:dbc023d) 
 
 
 
 
  
 
 
 
 
 
 
 
 
   

[jira] (SOLR-8029) Modernize and standardize Solr APIs

[ASF subversion and git services (JIRA)]

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 ASF subversion and git services commented on  SOLR-8029 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
  Re: Modernize and standardize Solr APIs  
 
 
 
 
 
 
 
 
 
 
Commit 71abe130697b0f279d6e3613145f1f8f052c7848 in lucene-solr's branch refs/heads/master from Noble Paul [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=71abe13 ] 
SOLR-8029: Added new style APIs and a framework for creating new APIs and mapping old APIs to new 
 
 
 
 
 
 
 
 
 
 
 
 

 
 Add Comment 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 
 
 

 This message was sent by Atlassian JIRA (v6.3.15#6346-sha1:dbc023d) 
 
 
 
 
  
 
 
 
 
 
 
 
 
   

[jira] (LUCENE-7670) AnalyzingInfixSuggester should not immediately open an IndexWriter over an already-built index

[Steve Rowe (JIRA)]

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Steve Rowe updated an issue 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 Lucene - Core /  LUCENE-7670 
 
 
 
  AnalyzingInfixSuggester should not immediately open an IndexWriter over an already-built index  
 
 
 
 
 
 
 
 
 
 
Patch that uses the SearcherManager(Directory,...) ctor instead of the SM(IndexWriter,...) ctor in the case of opening a suggester over an already built index. 
Committing shortly. 
 
 
 
 
 
 
 
 
 

Change By:
 
 Steve Rowe 
 
 
 

Attachment:
 
 LUCENE-7670.patch 
 
 
 
 
 
 
 
 
 
 
 
 

 
 Add Comment 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 
 
 

 This message was sent by Atlassian JIRA (v6.3.15#6346-sha1:dbc023d) 
 
 
 
 
  
 
 
 
 
 
 
 
 
   

[jira] (LUCENE-7670) AnalyzingInfixSuggester should not immediately open an IndexWriter over an already-built index

[Steve Rowe (JIRA)]

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Steve Rowe created an issue 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 Lucene - Core /  LUCENE-7670 
 
 
 
  AnalyzingInfixSuggester should not immediately open an IndexWriter over an already-built index  
 
 
 
 
 
 
 
 
 

Issue Type:
 
  Bug 
 
 
 

Affects Versions:
 

 6.4 
 
 
 

Assignee:
 

 Unassigned 
 
 
 

Created:
 

 31/Jan/17 05:57 
 
 
 

Priority:
 
  Major 
 
 
 

Reporter:
 
 Steve Rowe 
 
 
 
 
 
 
 
 
 
 
In tests I'm working on under SOLR-6246, I can see that attempts to open an AnalyzingInfixSuggester over a previously-built index fail, because the old suggester's IndexWriter lock is never released. The issue is that an IndexWriter is created in order to create a SearcherManager over the previously built index. But this is not necessary: SearcherManager has a ctor that takes a directory instead of an IndexWriter. 
 
 
 
 
 
 
 
 
 
 
 
 

 
 Add Comment 
 
 
 
 
 
 
 
 
 
  

[jira] (SOLR-10059) In SolrCloud, every fq added via is computed twice.

[Marc Morissette (JIRA)]

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Marc Morissette updated an issue 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 Solr /  SOLR-10059 
 
 
 
  In SolrCloud, every fq added via  is computed twice.  
 
 
 
 
 
 
 
 
 

Change By:
 
 Marc Morissette 
 
 
 
 
 
 
 
 
 
 While researching another issue, I noticed that parameters appended to a query via SearchHandler's  are added to the query twice in SolrCloud: once on the aggregator and again on the shard.The FacetComponent corrects this automatically by removing duplicates. Field queries added in this fashion are however computed twice and that  seriously  hinders performance on  large data sets  filter queries that aren't simple bitsets such as those produced by the CollapsingQueryParser .To reproduce the issue, simply test this handler on a large enough collection, then replace "appends" with "defaults" , you . You 'll notice significant performance improvements.{code}{! tag collapse field = myField routingKey hint=top_fc } myValue {code} 
 
 
 
 
 
 
 
 
 
 
 
 

 
 Add Comment 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 
 
 

 This message was sent by Atlassian JIRA (v6.3.15#6346-sha1:dbc023d) 
 
 
 
 
  
 
 
 
 
 
 
 
 
   

[jira] (SOLR-10060) Add test for implicit commit of uncommitted docs aged out of the transient cache.

[Erick Erickson (JIRA)]

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Erick Erickson updated an issue 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 Solr /  SOLR-10060 
 
 
 
  Add test for implicit commit of uncommitted docs aged out of the transient cache.  
 
 
 
 
 
 
 
 
 
 
Test, running precommit now. 
 
 
 
 
 
 
 
 
 

Change By:
 
 Erick Erickson 
 
 
 

Attachment:
 
 SOLR-10060.patch 
 
 
 
 
 
 
 
 
 
 
 
 

 
 Add Comment 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 
 
 

 This message was sent by Atlassian JIRA (v6.3.15#6346-sha1:dbc023d) 
 
 
 
 
  
 
 
 
 
 
 
 
 
   

[jira] (SOLR-10060) Add test for implicit commit of uncommitted docs aged out of the transient cache.

[Erick Erickson (JIRA)]

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Erick Erickson created an issue 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 Solr /  SOLR-10060 
 
 
 
  Add test for implicit commit of uncommitted docs aged out of the transient cache.  
 
 
 
 
 
 
 
 
 

Issue Type:
 
  Improvement 
 
 
 

Assignee:
 
 Erick Erickson 
 
 
 

Created:
 

 31/Jan/17 05:36 
 
 
 

Priority:
 
  Major 
 
 
 

Reporter:
 
 Erick Erickson 
 
 
 

Security Level:
 

 Public (Default Security Level. Issues are Public) 
 
 
 
 
 
 
 
 
 
 
There was a question on the user's list about whether uncommitted docs were implicitly committed when a transient core was aged out of the cache. I couldn't point to any tests showing that they were so I wrote one. Uncommitted docs are committed when a core is aged out, but this seems like a good test to have. 
I'm not sure this addresses the user's question about commit hooks or not, but that's probably another discussion. 
 
 
 
 
 
 
 
 
 
 
 
 

 
 Add Comment 
 
 
 
 
 
 
 
   

[jira] (SOLR-10059) In SolrCloud, every fq added via is computed twice.

[Marc Morissette (JIRA)]

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Marc Morissette commented on  SOLR-10059 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
  Re: In SolrCloud, every fq added via  is computed twice.  
 
 
 
 
 
 
 
 
 
 
I am willing to work on a patch but I'd like some guidance. I see two ways to solve this: 
 

Eliminate duplicate filter queries. Other parameters might however suffer from the same duplication issue so it seems like too narrow a solution.
 

Disable RequestHandler "appends" when ShardParams.IS_SHARD is true. This seems like the better solution since the appended parameters should already have been added to the query by the aggregating node. I don't know if there are some corner cases that I haven't considered though.
 
 
I'd appreciate some feedback. 
 
 
 
 
 
 
 
 
 
 
 
 

 
 Add Comment 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 
 
 

 This message was sent by Atlassian JIRA (v6.3.15#6346-sha1:dbc023d) 
 
 
 
 
  
 
 
 
 
 
 
 
 
   

[jira] (SOLR-10059) In SolrCloud, every fq added via is computed twice.

[Marc Morissette (JIRA)]

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Marc Morissette created an issue 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 Solr /  SOLR-10059 
 
 
 
  In SolrCloud, every fq added via  is computed twice.  
 
 
 
 
 
 
 
 
 

Issue Type:
 
  Bug 
 
 
 

Affects Versions:
 

 6.4.0 
 
 
 

Assignee:
 

 Unassigned 
 
 
 

Components:
 

 SolrCloud 
 
 
 

Created:
 

 31/Jan/17 04:30 
 
 
 

Labels:
 

 performance 
 
 
 

Priority:
 
  Major 
 
 
 

Reporter:
 
 Marc Morissette 
 
 
 

Security Level:
 

 Public (Default Security Level. Issues are Public) 
 
 
 
 
 
 
 
 
 
 
While researching another issue, I noticed that parameters appended to a query via SearchHandler's  are added to the query twice in SolrCloud: once on the aggregator and again on the shard. 
The FacetComponent corrects this automatically by removing duplicates. Field queries added in this 

[JENKINS] Lucene-Solr-SmokeRelease-6.x - Build # 249 - Still Failing

[Apache Jenkins Server]

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

No tests ran.

Build Log:
[...truncated 41899 lines...]
prepare-release-no-sign:
[mkdir] Created dir: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.x/lucene/build/smokeTestRelease/dist
 [copy] Copying 476 files to 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.x/lucene/build/smokeTestRelease/dist/lucene
 [copy] Copying 260 files to 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.x/lucene/build/smokeTestRelease/dist/solr
   [smoker] Java 1.8 JAVA_HOME=/home/jenkins/tools/java/latest1.8
   [smoker] NOTE: output encoding is UTF-8
   [smoker] Traceback (most recent call last):
   [smoker]   File 
"/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.x/dev-tools/scripts/smokeTestRelease.py",
 line 1472, in 
   [smoker] main()
   [smoker]   File 
"/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.x/dev-tools/scripts/smokeTestRelease.py",
 line 1416, in main
   [smoker] smokeTest(c.java, c.url, c.revision, c.version, c.tmp_dir, 
c.is_signed, ' '.join(c.test_args))
   [smoker]   File 
"/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.x/dev-tools/scripts/smokeTestRelease.py",
 line 1451, in smokeTest
   [smoker] checkSigs('lucene', lucenePath, version, tmpDir, isSigned)
   [smoker]   File 
"/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.x/dev-tools/scripts/smokeTestRelease.py",
 line 363, in checkSigs
   [smoker] '%s/%s.gpg.import.log' % (tmpDir, project))
   [smoker]   File 
"/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.x/dev-tools/scripts/smokeTestRelease.py",
 line 547, in run
   [smoker] raise RuntimeError('command "%s" failed; see log file %s' % 
(command, logPath))
   [smoker] RuntimeError: command "gpg --homedir 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.x/lucene/build/smokeTestRelease/tmp/lucene.gpg
 --import 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.x/lucene/build/smokeTestRelease/tmp/lucene.KEYS"
 failed; see log file 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.x/lucene/build/smokeTestRelease/tmp/lucene.gpg.import.log
   [smoker] 
   [smoker] Load release URL 
"file:/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.x/lucene/build/smokeTestRelease/dist/"...
   [smoker] 
   [smoker] Test Lucene...
   [smoker]   test basics...
   [smoker]   get KEYS
   [smoker] 0.0 MB in 0.01 sec (0.0 MB/sec)
   [smoker] 
   [smoker] command "gpg --homedir 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.x/lucene/build/smokeTestRelease/tmp/lucene.gpg
 --import 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.x/lucene/build/smokeTestRelease/tmp/lucene.KEYS"
 failed:
   [smoker] gpg: keyring 
`/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.x/lucene/build/smokeTestRelease/tmp/lucene.gpg/secring.gpg'
 created
   [smoker] gpg: keyring 
`/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.x/lucene/build/smokeTestRelease/tmp/lucene.gpg/pubring.gpg'
 created
   [smoker] gpg: no valid OpenPGP data found.
   [smoker] gpg: Total number processed: 0
   [smoker] 
   [smoker] 

BUILD FAILED
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.x/build.xml:571: 
exec returned: 1

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




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

[JENKINS-EA] Lucene-Solr-6.x-Linux (64bit/jdk-9-ea+153) - Build # 2770 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Linux/2770/
Java: 64bit/jdk-9-ea+153 -XX:+UseCompressedOops -XX:+UseG1GC

1 tests failed.
FAILED:  org.apache.solr.cloud.DocValuesNotIndexedTest.testGroupingDVOnly

Error Message:
Unexpected number of elements in the group for intGSF: 8

Stack Trace:
java.lang.AssertionError: Unexpected number of elements in the group for 
intGSF: 8
at 
__randomizedtesting.SeedInfo.seed([B1FDEF7C99596E67:2A468124D4015C39]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.DocValuesNotIndexedTest.testGroupingDVOnly(DocValuesNotIndexedTest.java:376)
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:543)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
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:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.base/java.lang.Thread.run(Thread.java:844)




Build Log:
[...truncated 11131 lines...]
   [junit4] Suite: org.apache.solr.cloud.DocValuesNotIndexedTest
   [junit4]   2> Creating dataDir: 
/home/jenkins/workspace/Lucene-Solr-6.x-Linux/solr/build/solr-core/test/J1/temp/solr.cloud.DocValuesNotIndexedTest_B1FDEF7C99596E67-001/init-core-data-001
   [junit4]   

[jira] (SOLR-10049) Collection deletion leaves behind the snapshot metadata

[Yonik Seeley (JIRA)]

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Yonik Seeley resolved as Fixed 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 
Committed, Thanks! 
 
 
 
 
 
 
 
 
 
 Solr /  SOLR-10049 
 
 
 
  Collection deletion leaves behind the snapshot metadata  
 
 
 
 
 
 
 
 
 

Change By:
 
 Yonik Seeley 
 
 
 

Resolution:
 
 Fixed 
 
 
 

Status:
 
 Open Resolved 
 
 
 
 
 
 
 
 
 
 
 
 

 
 Add Comment 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 
 
 

 This message was sent by Atlassian JIRA (v6.3.15#6346-sha1:dbc023d) 
 
 
 
 
  
 
 
 
 
 
 
 
 
   

[jira] (SOLR-10049) Collection deletion leaves behind the snapshot metadata

[ASF subversion and git services (JIRA)]

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 ASF subversion and git services commented on  SOLR-10049 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
  Re: Collection deletion leaves behind the snapshot metadata  
 
 
 
 
 
 
 
 
 
 
Commit 958d38ec69dcd6eaf361c0bed84e54b0b424f258 in lucene-solr's branch refs/heads/branch_6x from Yonik Seeley [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=958d38e ] 
SOLR-10049: make collection deletion remove snapshot metadata 
 
 
 
 
 
 
 
 
 
 
 
 

 
 Add Comment 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 
 
 

 This message was sent by Atlassian JIRA (v6.3.15#6346-sha1:dbc023d) 
 
 
 
 
  
 
 
 
 
 
 
 
 
   

[jira] (SOLR-10056) Add a parameter to the nodes Streaming Expression to control the scope of cycle detection

[Joel Bernstein (JIRA)]

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Joel Bernstein updated an issue 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 Solr /  SOLR-10056 
 
 
 
  Add a parameter to the nodes Streaming _expression_ to control the scope of cycle detection   
 
 
 
 
 
 
 
 
 

Change By:
 
 Joel Bernstein 
 
 
 
 
 
 
 
 
 
 Currently the *nodes* (aka *gatherNodes*) _expression_ does cycle detection for the entire traversal. This ticket will add a parameter to the nodes _expression_ to control when to start a new scope for cycle detection. Sample syntax: 
 
 
 
 
 
 
 
 
 
 
 
 

 
 Add Comment 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 
 
 

 This message was sent by Atlassian JIRA (v6.3.15#6346-sha1:dbc023d) 
 
 
 
 
  
 
 
 
 
 
 
 
 
   

[jira] (SOLR-10049) Collection deletion leaves behind the snapshot metadata

[ASF subversion and git services (JIRA)]

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 ASF subversion and git services commented on  SOLR-10049 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
  Re: Collection deletion leaves behind the snapshot metadata  
 
 
 
 
 
 
 
 
 
 
Commit c8edbe8663769392d422e84c05f45530833e48cc in lucene-solr's branch refs/heads/master from Yonik Seeley [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=c8edbe8 ] 
SOLR-10049: make collection deletion remove snapshot metadata 
 
 
 
 
 
 
 
 
 
 
 
 

 
 Add Comment 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 
 
 

 This message was sent by Atlassian JIRA (v6.3.15#6346-sha1:dbc023d) 
 
 
 
 
  
 
 
 
 
 
 
 
 
   

[jira] (SOLR-9764) Design a memory efficient DocSet if a query returns all docs

[Michael Sun (JIRA)]

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Michael Sun edited a comment on  SOLR-9764 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
  Re: Design a memory efficient DocSet if a query returns all docs  
 
 
 
 
 
 
 
 
 
 bq.  if the robustness of the DocSet hierarchy can be improved, we could even add multiple new implementations (Roaring, MatchMost, MatchAll, etc)Thanks for [~yo...@apache.org] for reviewing and improving. I open new JIRAs to evaluate and implement these optimizations.SOLR-10057 Evaluate/Design a MatchMost /MatchAll  doc setSOLR-10058 Evaluate/Design a DocSet using Lucene RoaringIdDocSet  
 
 
 
 
 
 
 
 
 
 
 
 

 
 Add Comment 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 
 
 

 This message was sent by Atlassian JIRA (v6.3.15#6346-sha1:dbc023d) 
 
 
 
 
  
 
 
 
 
 
 
 
 
   

[jira] (SOLR-9764) Design a memory efficient DocSet if a query returns all docs

[Michael Sun (JIRA)]

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Michael Sun edited a comment on  SOLR-9764 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
  Re: Design a memory efficient DocSet if a query returns all docs  
 
 
 
 
 
 
 
 
 
 bq.  if the robustness of the DocSet hierarchy can be improved, we could even add multiple new implementations (Roaring, MatchMost, MatchAll, etc)Thanks for [~yo...@apache.org] for reviewing and improving. I open new JIRAs to evaluate and implement these optimizations.SOLR-10057 Evaluate/Design a MatchMost/MatchAll doc set  (Use one JIRA since MatchAll can be a special case for MatchMost) SOLR-10058 Evaluate/Design a DocSet using Lucene RoaringIdDocSet  
 
 
 
 
 
 
 
 
 
 
 
 

 
 Add Comment 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 
 
 

 This message was sent by Atlassian JIRA (v6.3.15#6346-sha1:dbc023d) 
 
 
 
 
  
 
 
 
 
 
 
 
 
   

[jira] (SOLR-10057) Evaluate/Design a MatchMost/MatchAll doc set

[Michael Sun (JIRA)]

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Michael Sun updated an issue 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 Solr /  SOLR-10057 
 
 
 
  Evaluate/Design a MatchMost/MatchAll doc set  
 
 
 
 
 
 
 
 
 

Change By:
 
 Michael Sun 
 
 
 

Summary:
 
 Evaluate/Design a MatchMost /MatchAll  doc set 
 
 
 
 
 
 
 
 
 
 
 
 

 
 Add Comment 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 
 
 

 This message was sent by Atlassian JIRA (v6.3.15#6346-sha1:dbc023d) 
 
 
 
 
  
 
 
 
 
 
 
 
 
   

[jira] (SOLR-10058) Evaluate/Design a DocSet using Lucene RoaringIdDocSet

[Michael Sun (JIRA)]

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Michael Sun created an issue 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 Solr /  SOLR-10058 
 
 
 
  Evaluate/Design a DocSet using Lucene RoaringIdDocSet   
 
 
 
 
 
 
 
 
 

Issue Type:
 
  Bug 
 
 
 

Assignee:
 

 Unassigned 
 
 
 

Created:
 

 31/Jan/17 01:53 
 
 
 

Priority:
 
  Major 
 
 
 

Reporter:
 
 Michael Sun 
 
 
 

Security Level:
 

 Public (Default Security Level. Issues are Public) 
 
 
 
 
 
 
 
 
 
 
Per discussion in SOLR-9764 Design a memory efficient DocSet if a query returns all docs, Lucene RoaringIdDocSet can be memory efficient in a smart way, at the cost of some extra cpu cycles depending on use case and may be a good choice for some use cases. This JIRA is to evaluate and design a DocSet to take advantage of Lucene RoaringIdDocSet and understand the trade off. 
 
 
 
 
 
 
 
 
 
 
 
 

 
 Add Comment 
 
 
 
 
 
 
 
 
 
 

[jira] (SOLR-9764) Design a memory efficient DocSet if a query returns all docs

[Michael Sun (JIRA)]

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Michael Sun edited a comment on  SOLR-9764 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
  Re: Design a memory efficient DocSet if a query returns all docs  
 
 
 
 
 
 
 
 
 
 bq.  if the robustness of the DocSet hierarchy can be improved, we could even add multiple new implementations (Roaring, MatchMost, MatchAll, etc)Thanks for [~yo...@apache.org] for reviewing and improving. I open new JIRAs to evaluate and implement these optimizations. SOLR-10057 Evaluate/Design a MatchMost doc setSOLR-10058 Evaluate/Design a DocSet using Lucene RoaringIdDocSet  
 
 
 
 
 
 
 
 
 
 
 
 

 
 Add Comment 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 
 
 

 This message was sent by Atlassian JIRA (v6.3.15#6346-sha1:dbc023d) 
 
 
 
 
  
 
 
 
 
 
 
 
 
   

[jira] (SOLR-10057) Evaluate/Design a MatchMost doc set

[Michael Sun (JIRA)]

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Michael Sun created an issue 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 Solr /  SOLR-10057 
 
 
 
  Evaluate/Design a MatchMost doc set  
 
 
 
 
 
 
 
 
 

Issue Type:
 
  Bug 
 
 
 

Assignee:
 

 Unassigned 
 
 
 

Created:
 

 31/Jan/17 01:49 
 
 
 

Priority:
 
  Major 
 
 
 

Reporter:
 
 Michael Sun 
 
 
 

Security Level:
 

 Public (Default Security Level. Issues are Public) 
 
 
 
 
 
 
 
 
 
 
Per discussion in SOLR-9764 Design a memory efficient DocSet if a query returns all docs, if a DocSet matches most of documents, current implementation using BitDocSet can be optimized. This JIRA is to evaluate and design an optimized DocSet for these use cases.  
The basic idea is to use an inverted integer list to enumerate all doc ids that doesn't match. If the DocSet matches most of docs, it can be pretty efficient. Meanwhile other ideas are welcome. 
 
 
 
 
 
 
 
 
 
 
 
 

 
 Add Comment 
 
 
 
 
 
 
 
   

[jira] (SOLR-9764) Design a memory efficient DocSet if a query returns all docs

[Michael Sun (JIRA)]

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Michael Sun commented on  SOLR-9764 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
  Re: Design a memory efficient DocSet if a query returns all docs  
 
 
 
 
 
 
 
 
 
 

if the robustness of the DocSet hierarchy can be improved, we could even add multiple new implementations (Roaring, MatchMost, MatchAll, etc)
 
Thanks for Yonik Seeley for reviewing and improving. I open new JIRAs to evaluate and implement these optimizations. 
 
 
 
 
 
 
 
 
 
 
 
 

 
 Add Comment 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 
 
 

 This message was sent by Atlassian JIRA (v6.3.15#6346-sha1:dbc023d) 
 
 
 
 
  
 
 
 
 
 
 
 
 
   

[JENKINS] Lucene-Solr-NightlyTests-6.x - Build # 271 - Still unstable

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-6.x/271/

2 tests failed.
FAILED:  org.apache.solr.cloud.hdfs.StressHdfsTest.test

Error Message:
Timeout occured while waiting response from server at: http://127.0.0.1:57802

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: Timeout occured while waiting 
response from server at: http://127.0.0.1:57802
at 
__randomizedtesting.SeedInfo.seed([765495B8CB018238:FE00AA6265FDEFC0]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:621)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:279)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:268)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:435)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:387)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1344)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:1095)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:1037)
at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219)
at 
org.apache.solr.cloud.hdfs.StressHdfsTest.createAndDeleteCollection(StressHdfsTest.java:220)
at 
org.apache.solr.cloud.hdfs.StressHdfsTest.test(StressHdfsTest.java:103)
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:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:992)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:967)
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:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
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 

[jira] (SOLR-10056) Add a parameter to the nodes Streaming Expression to control the scope of cycle detection

[Joel Bernstein (JIRA)]

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Joel Bernstein created an issue 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 Solr /  SOLR-10056 
 
 
 
  Add a parameter to the nodes Streaming _expression_ to control the scope of cycle detection   
 
 
 
 
 
 
 
 
 

Issue Type:
 
  Improvement 
 
 
 

Assignee:
 

 Unassigned 
 
 
 

Created:
 

 31/Jan/17 00:47 
 
 
 

Priority:
 
  Major 
 
 
 

Reporter:
 
 Joel Bernstein 
 
 
 

Security Level:
 

 Public (Default Security Level. Issues are Public) 
 
 
 
 
 
 
 
 
 
 
Currently the nodes (aka gatherNodes) _expression_ does cycle detection for the entire traversal. This ticket will add a parameter to the nodes _expression_ to control when to start a new scope for cycle detection. 
 
 
 
 
 
 
 
 
 
 
 
 

 
 Add Comment 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 

[jira] (LUCENE-5143) rm or formalize dealing with "general" KEYS files in our dist dir

[JIRA]

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Jan Høydahl edited a comment on  LUCENE-5143 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
  Re: rm or formalize dealing with "general" KEYS files in our dist dir  
 
 
 
 
 
 
 
 
 
 See also http://search-lucene.com/m/l6pAi1GHWhp12AXAa2=dist+apache+org+Lucene+PGP+KEYS+files+mmbq , .  In my opinion we should only have one non-stale KEYS file which is automatically kept up-to-date.+1, I.e. stop publishing KEYS file in the solr, java and version-specific folders. That's what e.g. Hadoop and Ant do, and what is proposed in https://www.apache.org/dev/release-signing.html#keys-policy 
 
 
 
 
 
 
 
 
 
 
 
 

 
 Add Comment 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 
 
 

 This message was sent by Atlassian JIRA (v6.3.15#6346-sha1:dbc023d) 
 
 
 
 
  
 
 
 
 
 
 
 
 
   

[jira] (LUCENE-5143) rm or formalize dealing with "general" KEYS files in our dist dir

[JIRA]

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Jan Høydahl commented on  LUCENE-5143 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
  Re: rm or formalize dealing with "general" KEYS files in our dist dir  
 
 
 
 
 
 
 
 
 
 
See also http://search-lucene.com/m/l6pAi1GHWhp12AXAa2=dist+apache+org+Lucene+PGP+KEYS+files+mm 
bq, In my opinion we should only have one non-stale KEYS file which is automatically kept up-to-date. 
+1,  
I.e. stop publishing KEYS file in the solr, java and version-specific folders. That's what e.g. Hadoop and Ant do, and what is proposed in https://www.apache.org/dev/release-signing.html#keys-policy 
 
 
 
 
 
 
 
 
 
 
 
 

 
 Add Comment 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 
 
 

 This message was sent by Atlassian JIRA (v6.3.15#6346-sha1:dbc023d) 
 
 
 
 
  
 
 
 
 
 
 
 
 
   

[jira] (SOLR-10043) Reduce logging of pre-start log rotation

[JIRA]

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Jan Høydahl updated an issue 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 Solr /  SOLR-10043 
 
 
 
  Reduce logging of pre-start log rotation  
 
 
 
 
 
 
 
 
 

Change By:
 
 Jan Høydahl 
 
 
 

Affects Version/s:
 
 4.4 
 
 
 

Affects Version/s:
 
 4.3 
 
 
 

Affects Version/s:
 
 6.4.1 
 
 
 

Affects Version/s:
 
 6.4 
 
 
 

Affects Version/s:
 
 6.3 
 
 
 
 
 
 
 
 
 
 
 
 

 
 Add Comment 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 
 
 

 This message was sent by Atlassian JIRA (v6.3.15#6346-sha1:dbc023d) 
 
 
 
 
  
 
 
 
 
 
 
 
 
   

[jira] (SOLR-10043) Reduce logging of pre-start log rotation

[JIRA]

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Jan Høydahl resolved as Fixed 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 Solr /  SOLR-10043 
 
 
 
  Reduce logging of pre-start log rotation  
 
 
 
 
 
 
 
 
 

Change By:
 
 Jan Høydahl 
 
 
 

Resolution:
 
 Fixed 
 
 
 

Status:
 
 Open Resolved 
 
 
 
 
 
 
 
 
 
 
 
 

 
 Add Comment 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 
 
 

 This message was sent by Atlassian JIRA (v6.3.15#6346-sha1:dbc023d) 
 
 
 
 
  
 
 
 
 
 
 
 
 
   

[jira] (SOLR-10043) Reduce logging of pre-start log rotation

[ASF subversion and git services (JIRA)]

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 ASF subversion and git services commented on  SOLR-10043 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
  Re: Reduce logging of pre-start log rotation  
 
 
 
 
 
 
 
 
 
 
Commit a2395120500fed76d016656032bf1f2eed725b9a in lucene-solr's branch refs/heads/branch_6x from Jan Høydahl [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=a239512 ] 


SOLR-10043
: Reduce logging of pre-start log rotation 
(cherry picked from commit 8782d26) 
 
 
 
 
 
 
 
 
 
 
 
 

 
 Add Comment 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 
 
 

 This message was sent by Atlassian JIRA (v6.3.15#6346-sha1:dbc023d) 
 
 
 
 
  
 
 
 
 
 
 
 
 
   

[jira] (SOLR-10043) Reduce logging of pre-start log rotation

[JIRA]

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Jan Høydahl updated an issue 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 Solr /  SOLR-10043 
 
 
 
  Reduce logging of pre-start log rotation  
 
 
 
 
 
 
 
 
 

Change By:
 
 Jan Høydahl 
 
 
 

Fix Version/s:
 
 4.5 
 
 
 

Fix Version/s:
 
 6.5 
 
 
 
 
 
 
 
 
 
 
 
 

 
 Add Comment 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 
 
 

 This message was sent by Atlassian JIRA (v6.3.15#6346-sha1:dbc023d) 
 
 
 
 
  
 
 
 
 
 
 
 
 
   

[jira] (SOLR-10043) Reduce logging of pre-start log rotation

[ASF subversion and git services (JIRA)]

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 ASF subversion and git services commented on  SOLR-10043 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
  Re: Reduce logging of pre-start log rotation  
 
 
 
 
 
 
 
 
 
 
Commit 8782d261978b50cee5efe84dc7d699e0f33fb18a in lucene-solr's branch refs/heads/master from Jan Høydahl [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=8782d26 ] 
SOLR-10043: Reduce logging of pre-start log rotation 
 
 
 
 
 
 
 
 
 
 
 
 

 
 Add Comment 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 
 
 

 This message was sent by Atlassian JIRA (v6.3.15#6346-sha1:dbc023d) 
 
 
 
 
  
 
 
 
 
 
 
 
 
   

[jira] (SOLR-10055) Manual bin/solr start causes crash due to resolving wrong solr.in.sh

[JIRA]

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Jan Høydahl updated an issue 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 Solr /  SOLR-10055 
 
 
 
  Manual bin/solr start causes crash due to resolving wrong solr.in.sh  
 
 
 
 
 
 
 
 
 

Change By:
 
 Jan Høydahl 
 
 
 

Fix Version/s:
 
 master (7.0) 
 
 
 

Fix Version/s:
 
 6.5 
 
 
 
 
 
 
 
 
 
 
 
 

 
 Add Comment 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 
 
 

 This message was sent by Atlassian JIRA (v6.3.15#6346-sha1:dbc023d) 
 
 
 
 
  
 
 
 
 
 
 
 
 
   

[jira] (SOLR-10055) Manual bin/solr start causes crash due to resolving wrong solr.in.sh

[JIRA]

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Jan Høydahl assigned an issue to Jan Høydahl 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 Solr /  SOLR-10055 
 
 
 
  Manual bin/solr start causes crash due to resolving wrong solr.in.sh  
 
 
 
 
 
 
 
 
 

Change By:
 
 Jan Høydahl 
 
 
 

Assignee:
 
 Jan Høydahl 
 
 
 
 
 
 
 
 
 
 
 
 

 
 Add Comment 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 
 
 

 This message was sent by Atlassian JIRA (v6.3.15#6346-sha1:dbc023d) 
 
 
 
 
  
 
 
 
 
 
 
 
 
   

[jira] (SOLR-10055) Manual bin/solr start causes crash due to resolving wrong solr.in.sh

[JIRA]

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Jan Høydahl created an issue 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 Solr /  SOLR-10055 
 
 
 
  Manual bin/solr start causes crash due to resolving wrong solr.in.sh  
 
 
 
 
 
 
 
 
 

Issue Type:
 
  Bug 
 
 
 

Assignee:
 

 Unassigned 
 
 
 

Components:
 

 scripts and tools 
 
 
 

Created:
 

 31/Jan/17 00:04 
 
 
 

Priority:
 
  Major 
 
 
 

Reporter:
 
 Jan Høydahl 
 
 
 

Security Level:
 

 Public (Default Security Level. Issues are Public) 
 
 
 
 
 
 
 
 
 
 
The install script installs solr.in.sh in /etc/defaults/. However, if the user manually runs solr start, the script will use the solr.in.sh file from bin/ since that is first in the search path. And it will fail since /opt/solr is write protected. But if user starts with service solr start then the file from installation is used and all is fine. 
Since the default /opt/solr/server/solr is not writable by solr user, this creates a bad user experience and classifies as a bug. 
My proposal is that the installer renames bin/solr.in.sh -> bin/solr.in.sh.orig and the same with solr.in.cmd, so that the resolution logic will end up finding the one from the install. User can still override this by creating a $HOME/.solr.in.sh. 
 
 
 
 
 
 
  

[jira] (SOLR-10054) Core swapping doesn't work with new metrics changes in place

[Shawn Heisey (JIRA)]

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Shawn Heisey edited a comment on  SOLR-10054 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
  Re: Core swapping doesn't work with new metrics changes in place  
 
 
 
 
 
 
 
 
 
 Full The  error message  visible  in the  admin UI is "A metric named ADMIN./admin/ping.requestTimes already exists"Below is the full ERROR entry from the  logfile when the core swap is attempted.  This is from the binary 6.4.0 release:{noformat}2017-01-30 22:18:20.746 ERROR (qtp1769597131-22) [   ] o.a.s.h.RequestHandlerBase java.lang.IllegalArgumentException: A metric named ADMIN./admin/ping.requestTimes already exists at com.codahale.metrics.MetricRegistry.register(MetricRegistry.java:91) at com.codahale.metrics.MetricRegistry.registerAll(MetricRegistry.java:389) at com.codahale.metrics.MetricRegistry.registerAll(MetricRegistry.java:104) at org.apache.solr.metrics.SolrMetricManager.moveMetrics(SolrMetricManager.java:227) at org.apache.solr.metrics.SolrCoreMetricManager.afterCoreSetName(SolrCoreMetricManager.java:76) at org.apache.solr.core.SolrCore.setName(SolrCore.java:423) at org.apache.solr.core.SolrCores.swap(SolrCores.java:243) at org.apache.solr.core.CoreContainer.swap(CoreContainer.java:1012) at org.apache.solr.handler.admin.CoreAdminOperation.lambda$static$3(CoreAdminOperation.java:122) at org.apache.solr.handler.admin.CoreAdminOperation.execute(CoreAdminOperation.java:377) at org.apache.solr.handler.admin.CoreAdminHandler$CallInfo.call(CoreAdminHandler.java:379) at org.apache.solr.handler.admin.CoreAdminHandler.handleRequestBody(CoreAdminHandler.java:165) at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:166) at org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:664) at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:445) at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:345) at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:296) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1691) at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:582) at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143) at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548) at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:226) at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1180) at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:512) at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185) at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1112) at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141) at org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:213) at org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:119) at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134) at org.eclipse.jetty.server.Server.handle(Server.java:534) at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:320) at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:251) at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:273) at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:95) at org.eclipse.jetty.io.SelectChannelEndPoint$2.run(SelectChannelEndPoint.java:93) at org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.executeProduceConsume(ExecuteProduceConsume.java:303) at org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.produceConsume(ExecuteProduceConsume.java:148) at org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.run(ExecuteProduceConsume.java:136) at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:671) at 

[jira] (LUCENE-7668) WordDelimiterGraphFilter fails to preserve token type

[Uwe Schindler (JIRA)]

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Uwe Schindler commented on  LUCENE-7668 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
  Re: WordDelimiterGraphFilter fails to preserve token type  
 
 
 
 
 
 
 
 
 
 
There is one possibility: As CannedTokenStream is a source and owns the attributes, it could use the Token Attributefactory (see the final field on deprecated Token class) in its ctor. Because of this one could use copyTo of Token to copy it into the Token behind all attributes. 
But as CannedTokenStream only supports the attributes of Token, we could also just ensure all of those are copied. So look which attributes are implemented and use those! 
Not sure what's the better idea. 
 
 
 
 
 
 
 
 
 
 
 
 

 
 Add Comment 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 
 
 

 This message was sent by Atlassian JIRA (v6.3.15#6346-sha1:dbc023d) 
 
 
 
 
  
 
 
 
 
 
 
 
 
   

RE: dist.apache.org - Lucene PGP KEYS files mm

[Uwe Schindler]

Hi,

> Some historic context: https://issues.apache.org/jira/browse/LUCENE-5143

Oh, I remember!

 
> Keep in mind that things like the solr ref guide and pylucene releases
> don't do "per-release" KEY files, so completley eliminating those URLs
> would require a change to those process.
> 
> on the flip side: see Uwe's comment in that Jira questioning the rationale
> of snapshoting the KEY files per-release anyway, instead of just always
> using a continuously growing, automatically updated, KEYS file using LDAP
> as the source of truth.

I still think this is the best place, if:
- People also keep their historic GPG keys on the LDAP account
- There is a way to link the autogen'ed file from the website and its 
guaranteed to be there.

I think the Apache Infra Team should change id.apache.org that only adding of 
keys is possible with self-service. But removing old keys should be impossible 
for a non-admin or some extra crosschecks. If a key really needs to be deleted, 
it should happen with human interaction - ensuring it was not used anywhere (at 
least at Apache).

> I personally have no opinion, but agree the current situation is
> confusing.

:-(

Uwe

> : Date: Tue, 31 Jan 2017 00:23:46 +0100
> : From: Jan Høydahl 
> : Reply-To: dev@lucene.apache.org
> : To: dev@lucene.apache.org
> : Subject: dist.apache.org - Lucene PGP KEYS files mm
> :
> : Hi,
> :
> : I noticed that in the release archives
> https://archive.apache.org/dist/lucene/ there are
> : several KEYS files (containing committer’s PGP public keys):
> :
> : https://archive.apache.org/dist/lucene/KEYS  151109b  Tue, 30 
> Aug
> 2016  25 keys
> : https://archive.apache.org/dist/lucene/java/KEYS 128519b  Wed, 02
> Oct 2013  23 keys
> : https://archive.apache.org/dist/lucene/solr/KEYS 139586b  Tue, 30 
> Aug
> 2016  26 keys
> : https://archive.apache.org/dist/lucene/java/6.4.0/KEYS   224469b  Tue, 17
> Jan 2017  30 keys
> : https://archive.apache.org/dist/lucene/solr/6.4.0/KEYS   224469b  Tue, 17
> Jan 2017  30 keys
> :
> : Seems kind of random when the various files get updated.
> :
> : And why do we ever need more than the top /lucene/KEYS file? E.g. the
> Hadoop project maintains
> : only one top-level KEYS file http://www.apache.org/dist/hadoop/common/
> :
> : Another difference in the download site is that
> http://www.apache.org/dist/lucene/java/
> : has a README.html displaying below, while
> http://www.apache.org/dist/lucene/solr/ has a
> : HEADER.html showing above the list of downloads.
> :
> : Finally, when can we get rid of /tika, /nutch and /mahout folders
> (redirects)? They clutter up things :)
> :
> : --
> : Jan Høydahl, search solution architect
> : Cominvent AS - www.cominvent.com
> :
> :
> : -
> : To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> : For additional commands, e-mail: dev-h...@lucene.apache.org
> :
> :
> 
> -Hoss
> http://www.lucidworks.com/


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

[jira] (LUCENE-7668) WordDelimiterGraphFilter fails to preserve token type

[Michael McCandless (JIRA)]

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Michael McCandless commented on  LUCENE-7668 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
  Re: WordDelimiterGraphFilter fails to preserve token type  
 
 
 
 
 
 
 
 
 
 

Maybe we should fix CannedTokenStream to do what its comment says (captureState/restoreState).
 
I would love to, but I'm not quite sure how to do it. CannedTokenStream gets an array of Token in ... how can I do a restoreState from a Token? 
 
 
 
 
 
 
 
 
 
 
 
 

 
 Add Comment 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 
 
 

 This message was sent by Atlassian JIRA (v6.3.15#6346-sha1:dbc023d) 
 
 
 
 
  
 
 
 
 
 
 
 
 
   

[jira] (SOLR-10049) Collection deletion leaves behind the snapshot metadata

[Hrishikesh Gadre (JIRA)]

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Hrishikesh Gadre commented on  SOLR-10049 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
  Re: Collection deletion leaves behind the snapshot metadata  
 
 
 
 
 
 
 
 
 
 
Yonik Seeley Could you please review this small patch ? 
https://github.com/apache/lucene-solr/pull/149 
 
 
 
 
 
 
 
 
 
 
 
 

 
 Add Comment 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 
 
 

 This message was sent by Atlassian JIRA (v6.3.15#6346-sha1:dbc023d) 
 
 
 
 
  
 
 
 
 
 
 
 
 
   

Re: dist.apache.org - Lucene PGP KEYS files mm

[Chris Hostetter]

Some historic context: https://issues.apache.org/jira/browse/LUCENE-5143

Keep in mind that things like the solr ref guide and pylucene releases 
don't do "per-release" KEY files, so completley eliminating those URLs 
would require a change to those process.

on the flip side: see Uwe's comment in that Jira questioning the rationale 
of snapshoting the KEY files per-release anyway, instead of just always 
using a continuously growing, automatically updated, KEYS file using LDAP 
as the source of truth.

I personally have no opinion, but agree the current situation is 
confusing.


: Date: Tue, 31 Jan 2017 00:23:46 +0100
: From: Jan Høydahl 
: Reply-To: dev@lucene.apache.org
: To: dev@lucene.apache.org
: Subject: dist.apache.org - Lucene PGP KEYS files mm
: 
: Hi,
: 
: I noticed that in the release archives 
https://archive.apache.org/dist/lucene/ there are
: several KEYS files (containing committer’s PGP public keys):
: 
: https://archive.apache.org/dist/lucene/KEYS  151109b  Tue, 30 Aug 
2016  25 keys
: https://archive.apache.org/dist/lucene/java/KEYS 128519b  Wed, 02 Oct 
2013  23 keys
: https://archive.apache.org/dist/lucene/solr/KEYS 139586b  Tue, 30 Aug 
2016  26 keys
: https://archive.apache.org/dist/lucene/java/6.4.0/KEYS   224469b  Tue, 17 Jan 
2017  30 keys
: https://archive.apache.org/dist/lucene/solr/6.4.0/KEYS   224469b  Tue, 17 Jan 
2017  30 keys
: 
: Seems kind of random when the various files get updated.
: 
: And why do we ever need more than the top /lucene/KEYS file? E.g. the Hadoop 
project maintains
: only one top-level KEYS file http://www.apache.org/dist/hadoop/common/
: 
: Another difference in the download site is that 
http://www.apache.org/dist/lucene/java/
: has a README.html displaying below, while 
http://www.apache.org/dist/lucene/solr/ has a
: HEADER.html showing above the list of downloads.
: 
: Finally, when can we get rid of /tika, /nutch and /mahout folders 
(redirects)? They clutter up things :)
: 
: --
: Jan Høydahl, search solution architect
: Cominvent AS - www.cominvent.com
: 
: 
: -
: To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
: For additional commands, e-mail: dev-h...@lucene.apache.org
: 
: 

-Hoss
http://www.lucidworks.com/

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

[jira] (SOLR-10054) Core swapping doesn't work with new metrics changes in place

[Shawn Heisey (JIRA)]

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Shawn Heisey commented on  SOLR-10054 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
  Re: Core swapping doesn't work with new metrics changes in place  
 
 
 
 
 
 
 
 
 
 
I see that there is "TestCoreAdmin" but the text "swap" does not appear in that test. I cannot find any evidence that core swapping is tested by any Solr tests at all. 
 
 
 
 
 
 
 
 
 
 
 
 

 
 Add Comment 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 
 
 

 This message was sent by Atlassian JIRA (v6.3.15#6346-sha1:dbc023d) 
 
 
 
 
  
 
 
 
 
 
 
 
 
   

[jira] (LUCENE-7668) WordDelimiterGraphFilter fails to preserve token type

[Uwe Schindler (JIRA)]

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Uwe Schindler commented on  LUCENE-7668 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
  Re: WordDelimiterGraphFilter fails to preserve token type  
 
 
 
 
 
 
 
 
 
 
Hah, thanks for bringing to closure!  Thanks for removing the dead TypeAttribute! 
Maybe we should fix CannedTokenStream to do what its comment says (captureState/restoreState).  
 
 
 
 
 
 
 
 
 
 
 
 

 
 Add Comment 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 
 
 

 This message was sent by Atlassian JIRA (v6.3.15#6346-sha1:dbc023d) 
 
 
 
 
  
 
 
 
 
 
 
 
 
   

[jira] (SOLR-10035) Admin UI cannot find dataimport handlers

[JIRA]

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Jan Høydahl commented on  SOLR-10035 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
  Re: Admin UI cannot find dataimport handlers  
 
 
 
 
 
 
 
 
 
 
Looks awesome  The obvious question then is, if you specify -Dsolr.mbeans.useOnlyNewNaming=true, will then the DIH UI work?  I think we should flip the constant QUERYHANDLER -> QUERY in that dih JS file... 
 
 
 
 
 
 
 
 
 
 
 
 

 
 Add Comment 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 
 
 

 This message was sent by Atlassian JIRA (v6.3.15#6346-sha1:dbc023d) 
 
 
 
 
  
 
 
 
 
 
 
 
 
   

[jira] (SOLR-10049) Collection deletion leaves behind the snapshot metadata

[Yonik Seeley (JIRA)]

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Yonik Seeley assigned an issue to Yonik Seeley 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 Solr /  SOLR-10049 
 
 
 
  Collection deletion leaves behind the snapshot metadata  
 
 
 
 
 
 
 
 
 

Change By:
 
 Yonik Seeley 
 
 
 

Assignee:
 
 Yonik Seeley 
 
 
 
 
 
 
 
 
 
 
 
 

 
 Add Comment 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 
 
 

 This message was sent by Atlassian JIRA (v6.3.15#6346-sha1:dbc023d) 
 
 
 
 
  
 
 
 
 
 
 
 
 
   

[jira] (SOLR-10054) Core swapping doesn't work with new metrics changes in place

[Shawn Heisey (JIRA)]

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Shawn Heisey commented on  SOLR-10054 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
  Re: Core swapping doesn't work with new metrics changes in place  
 
 
 
 
 
 
 
 
 
 
Full error message in the logfile when the core swap is attempted. This is from the binary 6.4.0 release: 

 
2017-01-30 22:18:20.746 ERROR (qtp1769597131-22) [   ] o.a.s.h.RequestHandlerBase java.lang.IllegalArgumentException: A metric named ADMIN./admin/ping.requestTimes already exists
	at com.codahale.metrics.MetricRegistry.register(MetricRegistry.java:91)
	at com.codahale.metrics.MetricRegistry.registerAll(MetricRegistry.java:389)
	at com.codahale.metrics.MetricRegistry.registerAll(MetricRegistry.java:104)
	at org.apache.solr.metrics.SolrMetricManager.moveMetrics(SolrMetricManager.java:227)
	at org.apache.solr.metrics.SolrCoreMetricManager.afterCoreSetName(SolrCoreMetricManager.java:76)
	at org.apache.solr.core.SolrCore.setName(SolrCore.java:423)
	at org.apache.solr.core.SolrCores.swap(SolrCores.java:243)
	at org.apache.solr.core.CoreContainer.swap(CoreContainer.java:1012)
	at org.apache.solr.handler.admin.CoreAdminOperation.lambda$static$3(CoreAdminOperation.java:122)
	at org.apache.solr.handler.admin.CoreAdminOperation.execute(CoreAdminOperation.java:377)
	at org.apache.solr.handler.admin.CoreAdminHandler$CallInfo.call(CoreAdminHandler.java:379)
	at org.apache.solr.handler.admin.CoreAdminHandler.handleRequestBody(CoreAdminHandler.java:165)
	at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:166)
	at org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:664)
	at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:445)
	at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:345)
	at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:296)
	at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1691)
	at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:582)
	at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
	at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)
	at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:226)
	at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1180)
	at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:512)
	at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
	at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1112)
	at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
	at org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:213)
	at org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:119)
	at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)
	at org.eclipse.jetty.server.Server.handle(Server.java:534)
	at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:320)
	at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:251)
	at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:273)
	at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:95)
	at org.eclipse.jetty.io.SelectChannelEndPoint$2.run(SelectChannelEndPoint.java:93)
	at org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.executeProduceConsume(ExecuteProduceConsume.java:303)
	at org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.produceConsume(ExecuteProduceConsume.java:148)
	at org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.run(ExecuteProduceConsume.java:136)
	at 

dist.apache.org - Lucene PGP KEYS files mm

[Jan Høydahl]

Hi,

I noticed that in the release archives https://archive.apache.org/dist/lucene/ 
there are
several KEYS files (containing committer’s PGP public keys):

https://archive.apache.org/dist/lucene/KEYS  151109b  Tue, 30 Aug 
2016  25 keys
https://archive.apache.org/dist/lucene/java/KEYS 128519b  Wed, 02 Oct 
2013  23 keys
https://archive.apache.org/dist/lucene/solr/KEYS 139586b  Tue, 30 Aug 
2016  26 keys
https://archive.apache.org/dist/lucene/java/6.4.0/KEYS   224469b  Tue, 17 Jan 
2017  30 keys
https://archive.apache.org/dist/lucene/solr/6.4.0/KEYS   224469b  Tue, 17 Jan 
2017  30 keys

Seems kind of random when the various files get updated.

And why do we ever need more than the top /lucene/KEYS file? E.g. the Hadoop 
project maintains
only one top-level KEYS file http://www.apache.org/dist/hadoop/common/

Another difference in the download site is that 
http://www.apache.org/dist/lucene/java/
has a README.html displaying below, while 
http://www.apache.org/dist/lucene/solr/ has a
HEADER.html showing above the list of downloads.

Finally, when can we get rid of /tika, /nutch and /mahout folders (redirects)? 
They clutter up things :)

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


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

[jira] (SOLR-10053) TestSolrCloudWithDelegationTokens failures

[Hrishikesh Gadre (JIRA)]

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Hrishikesh Gadre commented on  SOLR-10053 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
  Re: TestSolrCloudWithDelegationTokens failures  
 
 
 
 
 
 
 
 
 
 
Ishan Chattopadhyaya TestDelegationWithHadoopAuth fails in a similar fashion. Since both these are using Hadoop framework, the fix for TestSolrCloudWithDelegationTokens would also apply to this test. Just an FYI. 
 
 
 
 
 
 
 
 
 
 
 
 

 
 Add Comment 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 
 
 

 This message was sent by Atlassian JIRA (v6.3.15#6346-sha1:dbc023d) 
 
 
 
 
  
 
 
 
 
 
 
 
 
   

[jira] (SOLR-10053) TestSolrCloudWithDelegationTokens failures

[ASF GitHub Bot (JIRA)]

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 ASF GitHub Bot commented on  SOLR-10053 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
  Re: TestSolrCloudWithDelegationTokens failures  
 
 
 
 
 
 
 
 
 
 
GitHub user hgadre opened a pull request: 
 https://github.com/apache/lucene-solr/pull/150 
 SOLR-10053 Logging improvements for troubleshooting 
You can merge this pull request into a Git repository by running: 
 $ git pull https://github.com/hgadre/lucene-solr SOLR-10053_fix 
Alternatively you can review and apply these changes as the patch at: 
 https://github.com/apache/lucene-solr/pull/150.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 #150 
 
commit 22f5473e2772859a936cae8e91946f79baf00fa5 Author: Hrishikesh Gadre  Date: 2017-01-30T22:58:26Z 
 SOLR-10053 Logging improvements for troubleshooting 
 
 
 
 
 
 
 
 
 
 
 
 
 

 
 Add Comment 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 
 
 

 This message was sent by Atlassian JIRA (v6.3.15#6346-sha1:dbc023d) 
 
 
 
 
  
 
 
 
 
 
 
 
 
   

[GitHub] lucene-solr pull request #150: [SOLR-10053] Logging improvements for trouble...

[hgadre]

GitHub user hgadre opened a pull request:

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

[SOLR-10053] Logging improvements for troubleshooting



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

$ git pull https://github.com/hgadre/lucene-solr SOLR-10053_fix

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

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


commit 22f5473e2772859a936cae8e91946f79baf00fa5
Author: Hrishikesh Gadre 
Date:   2017-01-30T22:58:26Z

[SOLR-10053] Logging improvements for troubleshooting




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

[jira] (SOLR-10035) Admin UI cannot find dataimport handlers

[Andrzej Bialecki (JIRA)]

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Andrzej Bialecki  edited a comment on  SOLR-10035 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
  Re: Admin UI cannot find dataimport handlers  
 
 
 
 
 
 
 
 
 
 This patch changes the output of /admin/mbeans to return affected mbeans under both new and old names, and supports selecting beans by both new and old categories.I also modified the UI to indicate that old names are deprecated  (see the screenshot) . 
 
 
 
 
 
 
 
 
 
 
 
 

 
 Add Comment 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 
 
 

 This message was sent by Atlassian JIRA (v6.3.15#6346-sha1:dbc023d) 
 
 
 
 
  
 
 
 
 
 
 
 
 
   

[jira] (SOLR-10035) Admin UI cannot find dataimport handlers

[Andrzej Bialecki (JIRA)]

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Andrzej Bialecki  updated an issue 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 Solr /  SOLR-10035 
 
 
 
  Admin UI cannot find dataimport handlers  
 
 
 
 
 
 
 
 
 

Change By:
 
 Andrzej Bialecki  
 
 
 

Attachment:
 
 screenshot-1.png 
 
 
 
 
 
 
 
 
 
 
 
 

 
 Add Comment 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 
 
 

 This message was sent by Atlassian JIRA (v6.3.15#6346-sha1:dbc023d) 
 
 
 
 
  
 
 
 
 
 
 
 
 
   

[jira] (SOLR-10035) Admin UI cannot find dataimport handlers

[Andrzej Bialecki (JIRA)]

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Andrzej Bialecki  updated an issue 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 Solr /  SOLR-10035 
 
 
 
  Admin UI cannot find dataimport handlers  
 
 
 
 
 
 
 
 
 
 
This patch changes the output of /admin/mbeans to return affected mbeans under both new and old names, and supports selecting beans by both new and old categories. 
I also modified the UI to indicate that old names are deprecated. 
 
 
 
 
 
 
 
 
 

Change By:
 
 Andrzej Bialecki  
 
 
 

Attachment:
 
 SOLR-10035.patch 
 
 
 
 
 
 
 
 
 
 
 
 

 
 Add Comment 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 
 
 

 This message was sent by Atlassian JIRA (v6.3.15#6346-sha1:dbc023d) 
 
 
 
 
  
 
 
 
 
 
 
 
 
   

[jira] (SOLR-10053) TestSolrCloudWithDelegationTokens failures

[Hrishikesh Gadre (JIRA)]

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Hrishikesh Gadre edited a comment on  SOLR-10053 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
  Re: TestSolrCloudWithDelegationTokens failures  
 
 
 
 
 
 
 
 
 
 [~ichattopadhyaya] Thanks for filing the jira. I am also not able to reproduce (and root cause) this failure. Since we are using WARN logging level for hadoop classes, we don't have enough information  to  for  troubleshooting. I suggest that we enable debug logging for delegation token auth related classes and keep the test enabled. Once we get relevant logs, I can spend some more time on this. 
 
 
 
 
 
 
 
 
 
 
 
 

 
 Add Comment 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 
 
 

 This message was sent by Atlassian JIRA (v6.3.15#6346-sha1:dbc023d) 
 
 
 
 
  
 
 
 
 
 
 
 
 
   

[jira] (SOLR-10053) TestSolrCloudWithDelegationTokens failures

[Hrishikesh Gadre (JIRA)]

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Hrishikesh Gadre edited a comment on  SOLR-10053 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
  Re: TestSolrCloudWithDelegationTokens failures  
 
 
 
 
 
 
 
 
 
 [~ichattopadhyaya] Thanks for filing the jira. I am also not able to reproduce (and root cause) this failure.  But I found that  Since  we are  missing the log output which can help us to identify the root-cause since we have set  using  WARN  logging  level for  all  hadoop classes , we don't have enough information to troubleshooting . I suggest that we enable debug logging for delegation token auth related classes and keep the test enabled. Once we get relevant logs, I can spend some more time on this.   
 
 
 
 
 
 
 
 
 
 
 
 

 
 Add Comment 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 
 
 

 This message was sent by Atlassian JIRA (v6.3.15#6346-sha1:dbc023d) 
 
 
 
 
  
 
 
 
 
 
 
 
 
   

[jira] (SOLR-10053) TestSolrCloudWithDelegationTokens failures

[Hrishikesh Gadre (JIRA)]

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Hrishikesh Gadre commented on  SOLR-10053 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
  Re: TestSolrCloudWithDelegationTokens failures  
 
 
 
 
 
 
 
 
 
 
Ishan Chattopadhyaya Thanks for filing the jira. I am also not able to reproduce (and root cause) this failure. But I found that we are missing the log output which can help us to identify the root-cause since we have set WARN level for all hadoop classes. I suggest that we enable debug logging for delegation token auth related classes and keep the test enabled. Once we get relevant logs, I can spend some more time on this. 
 
 
 
 
 
 
 
 
 
 
 
 

 
 Add Comment 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 
 
 

 This message was sent by Atlassian JIRA (v6.3.15#6346-sha1:dbc023d) 
 
 
 
 
  
 
 
 
 
 
 
 
 
   

[jira] (SOLR-10054) Core swapping doesn't work with new metrics changes in place

[Shawn Heisey (JIRA)]

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Shawn Heisey commented on  SOLR-10054 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
  Re: Core swapping doesn't work with new metrics changes in place  
 
 
 
 
 
 
 
 
 
 
The initial problem report came in via the #solr IRC channel. 
 
 
 
 
 
 
 
 
 
 
 
 

 
 Add Comment 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 
 
 

 This message was sent by Atlassian JIRA (v6.3.15#6346-sha1:dbc023d) 
 
 
 
 
  
 
 
 
 
 
 
 
 
   

[jira] (SOLR-10054) Core swapping doesn't work with new metrics changes in place

[Shawn Heisey (JIRA)]

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Shawn Heisey updated an issue 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 Solr /  SOLR-10054 
 
 
 
  Core swapping doesn't work with new metrics changes in place  
 
 
 
 
 
 
 
 
 

Change By:
 
 Shawn Heisey 
 
 
 
 
 
 
 
 
 
 The new 6.4.0 version includes some significant changes having to  deal  do  with metrics.  These changes have broken core swapping.  Will attach some screenshots.For the screenshots that I will attach, I started Solr directly from the 6.4.0 download on Windows 7 (bin\solr start).  Then I created a "foo" core and a "bar" core, each from a different configset, using the bin\solr command. * Screenshot 1: you can see the two cores in CoreAdmin. * Screenshot 2: Attempting to swap the cores, an error message appears about a metric already existing for the ping handler. * Screenshot 3: Clicking somewhere else and then back to CoreAdmin shows that both cores have the same name -- bar. * If Solr is stopped and then started back up, the admin UI looks like screenshot 1 again -- the change that caused two cores with the same name only took place within the running Solr and did not update core.properties files. 
 
 
 
 
 
 
 
 
 
 
 
 

 
 Add Comment 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 
 
 

 This message was sent by Atlassian JIRA (v6.3.15#6346-sha1:dbc023d) 
 
 
 
 
  
 
 
 
 
 
 
 
 
   

[jira] (SOLR-10054) Core swapping doesn't work with new metrics changes in place

[Shawn Heisey (JIRA)]

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Shawn Heisey updated an issue 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 Solr /  SOLR-10054 
 
 
 
  Core swapping doesn't work with new metrics changes in place  
 
 
 
 
 
 
 
 
 
 
Attaching screenshots. 
 
 
 
 
 
 
 
 
 

Change By:
 
 Shawn Heisey 
 
 
 

Attachment:
 
 solr64coreswap3.png 
 
 
 

Attachment:
 
 solr64coreswap2.png 
 
 
 

Attachment:
 
 solr64coreswap1.png 
 
 
 
 
 
 
 
 
 
 
 
 

 
 Add Comment 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 
 
 

 This message was sent by Atlassian JIRA (v6.3.15#6346-sha1:dbc023d) 
 
 
 
 
  
 
 
 
 
 
 
 
 
   

[jira] (SOLR-10054) Core swapping doesn't work with new metrics changes in place

[Shawn Heisey (JIRA)]

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Shawn Heisey created an issue 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 Solr /  SOLR-10054 
 
 
 
  Core swapping doesn't work with new metrics changes in place  
 
 
 
 
 
 
 
 
 

Issue Type:
 
  Bug 
 
 
 

Affects Versions:
 

 6.4.0 
 
 
 

Assignee:
 

 Unassigned 
 
 
 

Created:
 

 30/Jan/17 22:31 
 
 
 

Priority:
 
  Major 
 
 
 

Reporter:
 
 Shawn Heisey 
 
 
 

Security Level:
 

 Public (Default Security Level. Issues are Public) 
 
 
 
 
 
 
 
 
 
 
The new 6.4.0 version includes some significant changes having to deal with metrics. These changes have broken core swapping. Will attach some screenshots. 
For the screenshots that I will attach, I started Solr directly from the 6.4.0 download on Windows 7 (bin\solr start). Then I created a "foo" core and a "bar" core, each from a different configset, using the bin\solr command. 
 

Screenshot 1: you can see the two cores in CoreAdmin.
 

Screenshot 2: Attempting to swap the cores, an error message appears about a metric already existing for the ping handler.
 

 

[jira] (SOLR-9764) Design a memory efficient DocSet if a query returns all docs

[Yonik Seeley (JIRA)]

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Yonik Seeley updated an issue 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 Solr /  SOLR-9764 
 
 
 
  Design a memory efficient DocSet if a query returns all docs  
 
 
 
 
 
 
 
 
 
 
Here's an updated patch that has tests for the sharing of DocSets that match all documents. 
 
 
 
 
 
 
 
 
 

Change By:
 
 Yonik Seeley 
 
 
 

Attachment:
 
 SOLR-9764.patch 
 
 
 
 
 
 
 
 
 
 
 
 

 
 Add Comment 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 
 
 

 This message was sent by Atlassian JIRA (v6.3.15#6346-sha1:dbc023d) 
 
 
 
 
  
 
 
 
 
 
 
 
 
   

[jira] (LUCENE-7664) Deprecate GeoPointField & queries

[Michael McCandless (JIRA)]

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Michael McCandless updated an issue 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 Lucene - Core /  LUCENE-7664 
 
 
 
  Deprecate GeoPointField & queries  
 
 
 
 
 
 
 
 
 
 
Patch for 6.x, adding deprecation notices; I'll remove the classes in master after I push to 6.x. 
 
 
 
 
 
 
 
 
 

Change By:
 
 Michael McCandless 
 
 
 

Attachment:
 
 LUCENE-7664.patch 
 
 
 
 
 
 
 
 
 
 
 
 

 
 Add Comment 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 
 
 

 This message was sent by Atlassian JIRA (v6.3.15#6346-sha1:dbc023d) 
 
 
 
 
  
 
 
 
 
 
 
 
 
   

[jira] (LUCENE-7668) WordDelimiterGraphFilter fails to preserve token type

[Michael McCandless (JIRA)]

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Michael McCandless updated an issue 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 Lucene - Core /  LUCENE-7668 
 
 
 
  WordDelimiterGraphFilter fails to preserve token type  
 
 
 
 
 
 
 
 
 
 
Ahh in fact it's already doing the captureState/restoreState here, and so in fact there is no bug! I wrote the test first, and it was only failing because CannedTokenStream was failing to carry over the type I had asked for. 
Here's a new patch, just adding the test case, and removing dead code from WDGF. 
Thanks Uwe Schindler. 
 
 
 
 
 
 
 
 
 

Change By:
 
 Michael McCandless 
 
 
 

Attachment:
 
 LUCENE-7668.patch 
 
 
 
 
 
 
 
 
 
 
 
 

 
 Add Comment 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 
 
 

 This message was sent by Atlassian JIRA (v6.3.15#6346-sha1:dbc023d) 
 
 
 
 
  
 
 
 
 
 
 
 
 
   

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

[Apache Jenkins Server]

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

4 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.cloud.hdfs.HdfsChaosMonkeySafeLeaderTest

Error Message:
ObjectTracker found 1 object(s) that were not released!!! [HdfsTransactionLog] 
org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException  at 
org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:43)
  at 
org.apache.solr.update.HdfsTransactionLog.(HdfsTransactionLog.java:130)  
at org.apache.solr.update.HdfsTransactionLog.(HdfsTransactionLog.java:74) 
 at org.apache.solr.update.HdfsUpdateLog.ensureLog(HdfsUpdateLog.java:313)  at 
org.apache.solr.update.UpdateLog.add(UpdateLog.java:528)  at 
org.apache.solr.update.UpdateLog.add(UpdateLog.java:513)  at 
org.apache.solr.update.DirectUpdateHandler2.doNormalUpdate(DirectUpdateHandler2.java:299)
  at 
org.apache.solr.update.DirectUpdateHandler2.addDoc0(DirectUpdateHandler2.java:213)
  at 
org.apache.solr.update.DirectUpdateHandler2.addDoc(DirectUpdateHandler2.java:168)
  at 
org.apache.solr.update.processor.RunUpdateProcessor.processAdd(RunUpdateProcessorFactory.java:67)
  at 
org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:48)
  at 
org.apache.solr.update.processor.DistributedUpdateProcessor.doLocalAdd(DistributedUpdateProcessor.java:971)
  at 
org.apache.solr.update.processor.DistributedUpdateProcessor.versionAdd(DistributedUpdateProcessor.java:1184)
  at 
org.apache.solr.update.processor.DistributedUpdateProcessor.processAdd(DistributedUpdateProcessor.java:749)
  at 
org.apache.solr.update.processor.LogUpdateProcessorFactory$LogUpdateProcessor.processAdd(LogUpdateProcessorFactory.java:103)
  at 
org.apache.solr.handler.loader.JavabinLoader$1.update(JavabinLoader.java:97)  
at 
org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec$1.readOuterMostDocIterator(JavaBinUpdateRequestCodec.java:179)
  at 
org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec$1.readIterator(JavaBinUpdateRequestCodec.java:135)
  at org.apache.solr.common.util.JavaBinCodec.readObject(JavaBinCodec.java:306) 
 at org.apache.solr.common.util.JavaBinCodec.readVal(JavaBinCodec.java:251)  at 
org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec$1.readNamedList(JavaBinUpdateRequestCodec.java:121)
  at org.apache.solr.common.util.JavaBinCodec.readObject(JavaBinCodec.java:271) 
 at org.apache.solr.common.util.JavaBinCodec.readVal(JavaBinCodec.java:251)  at 
org.apache.solr.common.util.JavaBinCodec.unmarshal(JavaBinCodec.java:173)  at 
org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec.unmarshal(JavaBinUpdateRequestCodec.java:186)
  at 
org.apache.solr.handler.loader.JavabinLoader.parseAndLoadDocs(JavabinLoader.java:107)
  at org.apache.solr.handler.loader.JavabinLoader.load(JavabinLoader.java:54)  
at 
org.apache.solr.handler.UpdateRequestHandler$1.load(UpdateRequestHandler.java:97)
  at 
org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:68)
  at 
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:166)
  at org.apache.solr.core.SolrCore.execute(SolrCore.java:2402)  at 
org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:658)  at 
org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:464)  at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:345)
  at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:296)
  at 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1699)
  at 
org.apache.solr.client.solrj.embedded.JettySolrRunner$DebugFilter.doFilter(JettySolrRunner.java:139)
  at 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1699)
  at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:582) 
 at 
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:224)
  at 
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1180)
  at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:512)  
at 
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
  at 
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1112)
  at 
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)  
at 
org.eclipse.jetty.server.handler.gzip.GzipHandler.handle(GzipHandler.java:395)  
at 
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134) 
 at org.eclipse.jetty.server.Server.handle(Server.java:534)  at 
org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:320)  at 
org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:251)  at 
org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:273)
  at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:95)  at 

[jira] (SOLR-9997) Enable configuring SolrHttpClientBuilder via java system property

[Hrishikesh Gadre (JIRA)]

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Hrishikesh Gadre commented on  SOLR-9997 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
  Re: Enable configuring SolrHttpClientBuilder via java system property  
 
 
 
 
 
 
 
 
 
 
Jan Høydahl Could you please review the latest patch whenever you get a chance? 
 
 
 
 
 
 
 
 
 
 
 
 

 
 Add Comment 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 
 
 

 This message was sent by Atlassian JIRA (v6.3.15#6346-sha1:dbc023d) 
 
 
 
 
  
 
 
 
 
 
 
 
 
   

[JENKINS-EA] Lucene-Solr-6.x-Linux (64bit/jdk-9-ea+153) - Build # 2768 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Linux/2768/
Java: 64bit/jdk-9-ea+153 -XX:+UseCompressedOops -XX:+UseSerialGC

1 tests failed.
FAILED:  org.apache.solr.cloud.DocValuesNotIndexedTest.testGroupingDVOnly

Error Message:
Unexpected number of elements in the group for intGSF: 5

Stack Trace:
java.lang.AssertionError: Unexpected number of elements in the group for 
intGSF: 5
at 
__randomizedtesting.SeedInfo.seed([6E668EC65E6AFB57:F5DDE09E1332C909]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.DocValuesNotIndexedTest.testGroupingDVOnly(DocValuesNotIndexedTest.java:376)
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:543)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
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:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.base/java.lang.Thread.run(Thread.java:844)




Build Log:
[...truncated 11757 lines...]
   [junit4] Suite: org.apache.solr.cloud.DocValuesNotIndexedTest
   [junit4]   2> Creating dataDir: 
/home/jenkins/workspace/Lucene-Solr-6.x-Linux/solr/build/solr-core/test/J1/temp/solr.cloud.DocValuesNotIndexedTest_6E668EC65E6AFB57-001/init-core-data-001
   

[GitHub] lucene-solr pull request #149: Cleanup snapshot metadata during collection d...

[hgadre]

GitHub user hgadre opened a pull request:

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

Cleanup snapshot metadata during collection deletion

Also fixed small issues in the SolrSnapshotsTool

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

$ git pull https://github.com/hgadre/lucene-solr SOLR-10049_fix

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

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


commit 7acc93f46e10e3e95b405e385e0f6a50051557d3
Author: Hrishikesh Gadre 
Date:   2017-01-28T00:01:13Z

Cleanup snapshot metadata during collection deletion

Also fixed small issues in the SolrSnapshotsTool




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

[jira] (SOLR-10015) Remove strong reference to Field Cache key (optional) so that GC can release some Field Cache entries when Solr is under memory pressure

[Michael Sun (JIRA)]

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Michael Sun commented on  SOLR-10015 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
  Re: Remove strong reference to Field Cache key (optional) so that GC can release some Field Cache entries when Solr is under memory pressure  
 
 
 
 
 
 
 
 
 
 

Removing the strong references means that cache entries that are hugely expensive to build can be dropped without warning (and not even in response to memory pressure... just dropped because of any old GC event).
 
Thanks Yonik Seeley for your insight. The original intention of this JIRA is to 'enable' the weakhashmap used in field cache (FC) but it's good to know that WeakHashMap is not intended to release memory during GC. In that case, soft reference would be a better choice in general. 

it makes more sense to create a bounded cache (like other Solr caches) that can be controlled by size (number of elements or RAM usage).
 
The LRU cache in Solr caches is a good choice. Meanwhile I would argue that the idea of soft reference is also creating a 'sort' of bounded cache which is bounded by available heap, which has its own eviction policy. 

Once an entry was instantiated for a reader, it was never removed until the reader itself went away.
 
Can you tell us more details about this design? More importantly, if FC is further optimized, is there any reason to keep the cache design in this way. 
 
 
 
 
 
 
 
 
 
 
 
 

 
 Add Comment 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 
 
 

 This message was sent by Atlassian JIRA (v6.3.15#6346-sha1:dbc023d) 
 
 
 
 
  
 
 
 
 
 
 
 
 
   

[jira] (LUCENE-7669) Rectangle.fromPolygon could compute smaller bounding boxes

[Adrien Grand (JIRA)]

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Adrien Grand updated an issue 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 Lucene - Core /  LUCENE-7669 
 
 
 
  Rectangle.fromPolygon could compute smaller bounding boxes  
 
 
 
 
 
 
 
 
 
 
Here is a patch. I am seeing a 6% QPS increase when benchmarking the Russia polygon with IndexAndSearchOpenStreetMaps. 
 
 
 
 
 
 
 
 
 

Change By:
 
 Adrien Grand 
 
 
 

Attachment:
 
 LUCENE-7669.patch 
 
 
 
 
 
 
 
 
 
 
 
 

 
 Add Comment 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 
 
 

 This message was sent by Atlassian JIRA (v6.3.15#6346-sha1:dbc023d) 
 
 
 
 
  
 
 
 
 
 
 
 
 
   

[jira] (LUCENE-7669) Rectangle.fromPolygon could compute smaller bounding boxes

[Adrien Grand (JIRA)]

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Adrien Grand created an issue 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 Lucene - Core /  LUCENE-7669 
 
 
 
  Rectangle.fromPolygon could compute smaller bounding boxes  
 
 
 
 
 
 
 
 
 

Issue Type:
 
  Improvement 
 
 
 

Assignee:
 

 Unassigned 
 
 
 

Created:
 

 30/Jan/17 18:22 
 
 
 

Priority:
 
  Minor 
 
 
 

Reporter:
 
 Adrien Grand 
 
 
 
 
 
 
 
 
 
 
Currently it computes the smallest bounding box that does not cross the dateline. However allowing to cross the dateline could allow to create smaller bounding boxes. For instance, because of that, the bounding box of the Russia polygon has a width of 360 longitude degrees. By allowing rectangles that cross the dateline, we could get a polygon whose width is only 171 longitude degrees. This is useful combined with 

LUCENE-7661
 since it means the grid would have higher resolution. 
 
 
 
 
 
 
 
 
 
 
 
 

 
 Add Comment 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
  

Re: 6.4.1

[Adrien Grand]

Thanks Steve, I had looked at whether there were existing infra issues but
had not thought about looking at their mailing-list. I'll have a look
tomorrow at whether the GPG import succeeded.

Le lun. 30 janv. 2017 à 19:06, Steve Rowe  a écrit :

> FYI yesterday morning on the users@infra mailing list, sebb posted with
> subject “committers keys job failed last night”:
>
> > As some of you may have noticed, the committers pgp keys job did not
> > retrieve any keys last night.
> >
> > I made a change to use gpg instead of curl for downloading keys.
> > Unfortunately it looks like the gpg version on home.apache.org is not
> > as up to date as the version I tested on, and one of the options did
> > not work.
> >
> > Hopefully the code is now fixed to work on the older version, but we
> > won't know until tomorrow as the job only runs once a day.
>
> --
> Steve
> www.lucidworks.com
>
> > On Jan 30, 2017, at 12:46 PM, Adrien Grand  wrote:
> >
> > There is an issue with GPG keys that prevents me from building a first
> RC: https://issues.apache.org/jira/browse/INFRA-13427. I'll monitor that
> issue and build a RC once it is resolved.
> >
> > Le jeu. 26 janv. 2017 à 16:01, Adrien Grand  a écrit
> :
> > +1 to get the change in if it is safe.
> >
> > Le jeu. 26 janv. 2017 à 15:59, Shawn Heisey  a
> écrit :
> > On 1/25/2017 4:40 AM, Adrien Grand wrote:
> > > These are annoying bugs so I would like to do a 6.4.1 release that
> > > includes these fixes.
> >
> > The immediate simple fix for SOLR-10035 is a one-liner.  Even the larger
> > fix of including redundant information that preserves backward API
> > compatibility would be very safe.
> >
> > Thanks,
> > Shawn
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> > For additional commands, e-mail: dev-h...@lucene.apache.org
> >
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

RE: Disable HTML mails

[Uwe Schindler]

Hi,

-1 for TEXT
+1 for HTML

I am very used to the fact of having HTML mails for all JIRA systems I work 
with, so I was happy that ASF suddenly sent them as HTML (funny: I did not even 
notice).

Uwe

-
Uwe Schindler
Achterdiek 19, D-28357 Bremen
http://www.thetaphi.de
eMail: u...@thetaphi.de

> -Original Message-
> From: Chris Hostetter [mailto:hossman_luc...@fucit.org]
> Sent: Monday, January 30, 2017 6:26 PM
> To: dev@lucene.apache.org
> Subject: RE: Disable HTML mails
> 
> 
> 
> : It sends mails to the dev@lao mailing list in HTML (which I really
> : like!), but you can still configure the ones sent to yourself as TXT
> : only. Not sure how to change the mailing list ones to be text only!
> 
> I agree with ishan -- the new HTML formatted mails to the list are pretty
> much impossible for me to read in my mail client.
> 
> They are also now about 5X larger then before for a single one line
> comment, and the subject formatting is completely broken and no longer
> includes the Created/Commented/Resolved/Closed action details.
> 
> If it's at all possible to get infra to change this back, then i am
> absolutely +1 to doing so for the jira emails to dev@
> 
> 
> -Hoss
> http://www.lucidworks.com/
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org


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

Re: 6.4.1

[Steve Rowe]

FYI yesterday morning on the users@infra mailing list, sebb posted with subject 
“committers keys job failed last night”:

> As some of you may have noticed, the committers pgp keys job did not
> retrieve any keys last night.
>
> I made a change to use gpg instead of curl for downloading keys.
> Unfortunately it looks like the gpg version on home.apache.org is not
> as up to date as the version I tested on, and one of the options did
> not work.
>
> Hopefully the code is now fixed to work on the older version, but we
> won't know until tomorrow as the job only runs once a day.

--
Steve
www.lucidworks.com

> On Jan 30, 2017, at 12:46 PM, Adrien Grand  wrote:
> 
> There is an issue with GPG keys that prevents me from building a first RC: 
> https://issues.apache.org/jira/browse/INFRA-13427. I'll monitor that issue 
> and build a RC once it is resolved.
> 
> Le jeu. 26 janv. 2017 à 16:01, Adrien Grand  a écrit :
> +1 to get the change in if it is safe.
> 
> Le jeu. 26 janv. 2017 à 15:59, Shawn Heisey  a écrit :
> On 1/25/2017 4:40 AM, Adrien Grand wrote:
> > These are annoying bugs so I would like to do a 6.4.1 release that
> > includes these fixes.
> 
> The immediate simple fix for SOLR-10035 is a one-liner.  Even the larger
> fix of including redundant information that preserves backward API
> compatibility would be very safe.
> 
> Thanks,
> Shawn
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
> 


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

Re: Disable HTML mails

[Steve Rowe]

+1 for TXT.

--
Steve
www.lucidworks.com

> On Jan 30, 2017, at 12:57 PM, David Smiley  wrote:
> 
> Yeah, +1 to change dev@ emails to TXT.
> 
> On Mon, Jan 30, 2017 at 12:26 PM Chris Hostetter  
> wrote:
> 
> 
> : It sends mails to the dev@lao mailing list in HTML (which I really
> : like!), but you can still configure the ones sent to yourself as TXT
> : only. Not sure how to change the mailing list ones to be text only!
> 
> I agree with ishan -- the new HTML formatted mails to the list are pretty
> much impossible for me to read in my mail client.
> 
> They are also now about 5X larger then before for a single one line
> comment, and the subject formatting is completely broken and no longer
> includes the Created/Commented/Resolved/Closed action details.
> 
> If it's at all possible to get infra to change this back, then i am
> absolutely +1 to doing so for the jira emails to dev@
> 
> 
> -Hoss
> http://www.lucidworks.com/
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
> 
> -- 
> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
> LinkedIn: http://linkedin.com/in/davidwsmiley | Book: 
> http://www.solrenterprisesearchserver.com


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

Re: Disable HTML mails

[David Smiley]

Yeah, +1 to change dev@ emails to TXT.

On Mon, Jan 30, 2017 at 12:26 PM Chris Hostetter 
wrote:

>
>
> : It sends mails to the dev@lao mailing list in HTML (which I really
> : like!), but you can still configure the ones sent to yourself as TXT
> : only. Not sure how to change the mailing list ones to be text only!
>
> I agree with ishan -- the new HTML formatted mails to the list are pretty
> much impossible for me to read in my mail client.
>
> They are also now about 5X larger then before for a single one line
> comment, and the subject formatting is completely broken and no longer
> includes the Created/Commented/Resolved/Closed action details.
>
> If it's at all possible to get infra to change this back, then i am
> absolutely +1 to doing so for the jira emails to dev@
>
>
> -Hoss
> http://www.lucidworks.com/
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
> --
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
http://www.solrenterprisesearchserver.com

Re: 6.4.1

[Adrien Grand]

There is an issue with GPG keys that prevents me from building a first RC:
https://issues.apache.org/jira/browse/INFRA-13427. I'll monitor that issue
and build a RC once it is resolved.

Le jeu. 26 janv. 2017 à 16:01, Adrien Grand  a écrit :

> +1 to get the change in if it is safe.
>
> Le jeu. 26 janv. 2017 à 15:59, Shawn Heisey  a
> écrit :
>
> On 1/25/2017 4:40 AM, Adrien Grand wrote:
> > These are annoying bugs so I would like to do a 6.4.1 release that
> > includes these fixes.
>
> The immediate simple fix for SOLR-10035 is a one-liner.  Even the larger
> fix of including redundant information that preserves backward API
> compatibility would be very safe.
>
> Thanks,
> Shawn
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

RE: Disable HTML mails

[Chris Hostetter]

: It sends mails to the dev@lao mailing list in HTML (which I really 
: like!), but you can still configure the ones sent to yourself as TXT 
: only. Not sure how to change the mailing list ones to be text only!

I agree with ishan -- the new HTML formatted mails to the list are pretty 
much impossible for me to read in my mail client.

They are also now about 5X larger then before for a single one line 
comment, and the subject formatting is completely broken and no longer 
includes the Created/Commented/Resolved/Closed action details.

If it's at all possible to get infra to change this back, then i am 
absolutely +1 to doing so for the jira emails to dev@ 


-Hoss
http://www.lucidworks.com/

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

[jira] (LUCENE-7658) queryparser/xml CoreParser to implement SpanQueryBuilder interface

[ASF subversion and git services (JIRA)]

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 ASF subversion and git services commented on  LUCENE-7658 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
  Re: queryparser/xml CoreParser to implement SpanQueryBuilder interface  
 
 
 
 
 
 
 
 
 
 
Commit 59390ef76dd83426b3dad5b2067760606e14687d in lucene-solr's branch refs/heads/branch_6x from Christine Poerschke [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=59390ef ] 
LUCENE-7658: queryparser/xml CoreParser now implements SpanQueryBuilder interface. (Daniel Collins, Christine Poerschke) 
 
 
 
 
 
 
 
 
 
 
 
 

 
 Add Comment 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 
 
 

 This message was sent by Atlassian JIRA (v6.3.15#6346-sha1:dbc023d) 
 
 
 
 
  
 
 
 
 
 
 
 
 
   

[jira] (LUCENE-7665) Remove grouping dependency from the join module

[ASF subversion and git services (JIRA)]

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 ASF subversion and git services commented on  LUCENE-7665 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
  Re: Remove grouping dependency from the join module  
 
 
 
 
 
 
 
 
 
 
Commit 0d5c3558caa1432a6f5604c63efe0af0d7be5794 in lucene-solr's branch refs/heads/branch_6x from Martijn van Groningen [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=0d5c355 ] 


LUCENE-7665
: Remove grouping dependency from the join module. 
 
 
 
 
 
 
 
 
 
 
 
 

 
 Add Comment 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 
 
 

 This message was sent by Atlassian JIRA (v6.3.15#6346-sha1:dbc023d) 
 
 
 
 
  
 
 
 
 
 
 
 
 
   

[jira] (LUCENE-7665) Remove grouping dependency from the join module

[Martijn van Groningen (JIRA)]

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Martijn van Groningen resolved as Fixed 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 Lucene - Core /  LUCENE-7665 
 
 
 
  Remove grouping dependency from the join module  
 
 
 
 
 
 
 
 
 

Change By:
 
 Martijn van Groningen 
 
 
 

Resolution:
 
 Fixed 
 
 
 

Status:
 
 Open Resolved 
 
 
 
 
 
 
 
 
 
 
 
 

 
 Add Comment 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 
 
 

 This message was sent by Atlassian JIRA (v6.3.15#6346-sha1:dbc023d) 
 
 
 
 
  
 
 
 
 
 
 
 
 
   

[jira] (LUCENE-7665) Remove grouping dependency from the join module

[ASF subversion and git services (JIRA)]

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 ASF subversion and git services commented on  LUCENE-7665 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
  Re: Remove grouping dependency from the join module  
 
 
 
 
 
 
 
 
 
 
Commit e5dbfa4c52c9963f67aea1da12f3628e6869 in lucene-solr's branch refs/heads/master from Martijn van Groningen [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=e5dbfa4 ] 


LUCENE-7665
: Remove grouping dependency from the join module. 
 
 
 
 
 
 
 
 
 
 
 
 

 
 Add Comment 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 
 
 

 This message was sent by Atlassian JIRA (v6.3.15#6346-sha1:dbc023d) 
 
 
 
 
  
 
 
 
 
 
 
 
 
   

Re: [JENKINS] Lucene-Solr-SmokeRelease-6.4 - Build # 10 - Failure

[Adrien Grand]

This build failed because http://home.apache.org/keys/group/lucene.asc is
empty. I opened an INFRA issue
https://issues.apache.org/jira/browse/INFRA-13427.

Le lun. 30 janv. 2017 à 05:37, Apache Jenkins Server <
jenk...@builds.apache.org> a écrit :

> Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-6.4/10/
>
> No tests ran.
>
> Build Log:
> [...truncated 41914 lines...]
> prepare-release-no-sign:
> [mkdir] Created dir:
> /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.4/lucene/build/smokeTestRelease/dist
>  [copy] Copying 476 files to
> /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.4/lucene/build/smokeTestRelease/dist/lucene
>  [copy] Copying 260 files to
> /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.4/lucene/build/smokeTestRelease/dist/solr
>[smoker] Java 1.8 JAVA_HOME=/home/jenkins/tools/java/latest1.8
>[smoker] NOTE: output encoding is UTF-8
>[smoker]
>[smoker] Load release URL
> "file:/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.4/lucene/build/smokeTestRelease/dist/"...
>[smoker]
>[smoker] Test Lucene...
>[smoker]   test basics...
>[smoker]   get KEYS
>[smoker] 0.0 MB in 0.01 sec (0.0 MB/sec)
>[smoker]
>[smoker] command "gpg --homedir
> /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.4/lucene/build/smokeTestRelease/tmp/lucene.gpg
> --import
> /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.4/lucene/build/smokeTestRelease/tmp/lucene.KEYS"
> failed:
>[smoker] gpg: keyring
> `/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.4/lucene/build/smokeTestRelease/tmp/lucene.gpg/secring.gpg'
> created
>[smoker] gpg: keyring
> `/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.4/lucene/build/smokeTestRelease/tmp/lucene.gpg/pubring.gpg'
> created
>[smoker] gpg: no valid OpenPGP data found.
>[smoker] gpg: Total number processed: 0
>[smoker]
>[smoker]
>[smoker] Traceback (most recent call last):
>[smoker]   File
> "/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.4/dev-tools/scripts/smokeTestRelease.py",
> line 1472, in 
>[smoker] main()
>[smoker]   File
> "/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.4/dev-tools/scripts/smokeTestRelease.py",
> line 1416, in main
>[smoker] smokeTest(c.java, c.url, c.revision, c.version, c.tmp_dir,
> c.is_signed, ' '.join(c.test_args))
>[smoker]   File
> "/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.4/dev-tools/scripts/smokeTestRelease.py",
> line 1451, in smokeTest
>[smoker] checkSigs('lucene', lucenePath, version, tmpDir, isSigned)
>[smoker]   File
> "/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.4/dev-tools/scripts/smokeTestRelease.py",
> line 363, in checkSigs
>[smoker] '%s/%s.gpg.import.log' % (tmpDir, project))
>[smoker]   File
> "/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.4/dev-tools/scripts/smokeTestRelease.py",
> line 547, in run
>[smoker] raise RuntimeError('command "%s" failed; see log file %s'
> % (command, logPath))
>[smoker] RuntimeError: command "gpg --homedir
> /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.4/lucene/build/smokeTestRelease/tmp/lucene.gpg
> --import
> /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.4/lucene/build/smokeTestRelease/tmp/lucene.KEYS"
> failed; see log file
> /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.4/lucene/build/smokeTestRelease/tmp/lucene.gpg.import.log
>
> BUILD FAILED
> /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.4/build.xml:571:
> exec returned: 1
>
> Total time: 10 minutes 30 seconds
> Build step 'Invoke Ant' marked build as failure
> Email was triggered for: Failure - Any
> Sending email for trigger: Failure - Any
>
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org

RE: dev-unsubscribe

[Rowe, William - 1180 - MITLL]

dev-unsubscribe

-Original Message-
From: Rowe, William - 1180 - MITLL
Sent: Monday, January 30, 2017 7:53 AM
To: 'dev@lucene.apache.org'
Subject: Re: dev-unsubscribe



-Original Message-
From: Erick Erickson [mailto:erickerick...@gmail.com]
Sent: Saturday, January 28, 2017 1:12 PM
To: solr-user
Subject: Re: dev-unsubscribe

Please follow the instructions here:
http://lucene.apache.org/solr/community.html#mailing-lists-irc

Note, you must use the exact e-mail address you originally used to subscribe.

If you have trouble and the "Problems?" link doesn't help resolve them let us
know.

Best,
Erick

On Sat, Jan 28, 2017 at 12:25 AM, Robin Wei  wrote:
>


smime.p7s
Description: S/MIME cryptographic signature

[JENKINS] Lucene-Solr-6.4-Linux (64bit/jdk1.8.0_121) - Build # 77 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.4-Linux/77/
Java: 64bit/jdk1.8.0_121 -XX:-UseCompressedOops -XX:+UseParallelGC

1 tests failed.
FAILED:  
org.apache.solr.cloud.CollectionsAPIDistributedZkTest.testCollectionsAPI

Error Message:
No live SolrServers available to handle this 
request:[https://127.0.0.1:36360/solr/awhollynewcollection_0]

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: No live SolrServers available 
to handle this request:[https://127.0.0.1:36360/solr/awhollynewcollection_0]
at 
__randomizedtesting.SeedInfo.seed([AA3A44820EA7835:42D6D0FC26D957A0]:0)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:414)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1344)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:1095)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:1037)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:149)
at org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:942)
at 
org.apache.solr.cloud.CollectionsAPIDistributedZkTest.testCollectionsAPI(CollectionsAPIDistributedZkTest.java:516)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
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:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:811)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:462)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
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 

[jira] (LUCENE-7658) queryparser/xml CoreParser to implement SpanQueryBuilder interface

[ASF subversion and git services (JIRA)]

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 ASF subversion and git services commented on  LUCENE-7658 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
  Re: queryparser/xml CoreParser to implement SpanQueryBuilder interface  
 
 
 
 
 
 
 
 
 
 
Commit 61ab4e338e3532210881ab7c8d66927e4459d447 in lucene-solr's branch refs/heads/master from Christine Poerschke [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=61ab4e3 ] 
LUCENE-7658: queryparser/xml CoreParser now implements SpanQueryBuilder interface. (Daniel Collins, Christine Poerschke) 
 
 
 
 
 
 
 
 
 
 
 
 

 
 Add Comment 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 
 
 

 This message was sent by Atlassian JIRA (v6.3.15#6346-sha1:dbc023d) 
 
 
 
 
  
 
 
 
 
 
 
 
 
   

RE: Disable HTML mails

[Uwe Schindler]

Hi,

 

It sends mails to the dev@lao mailing list in HTML (which I really like!), but 
you can still configure the ones sent to yourself as TXT only. Not sure how to 
change the mailing list ones to be text only!

 

Uwe

 

-

Uwe Schindler

Achterdiek 19, D-28357 Bremen

  http://www.thetaphi.de

eMail: u...@thetaphi.de

 

From: Ishan Chattopadhyaya [mailto:ichattopadhy...@gmail.com] 
Sent: Monday, January 30, 2017 4:00 PM
To: dev@lucene.apache.org
Subject: Disable HTML mails

 

It seems, lately, JIRA is sending mails in HTML. I have my settings set to Text 
mails, but seems ot have had no effect. Are text based emails obsolete?

How to have this issue fixed/reported?

Regards,

Ishan

p.s.: Pine users would be very annoyed, I'm sure. :-(

Disable HTML mails

[Ishan Chattopadhyaya]

It seems, lately, JIRA is sending mails in HTML. I have my settings set to
Text mails, but seems ot have had no effect. Are text based emails obsolete?

How to have this issue fixed/reported?

Regards,
Ishan

p.s.: Pine users would be very annoyed, I'm sure. :-(

[jira] (SOLR-10053) TestSolrCloudWithDelegationTokens failures

[Ishan Chattopadhyaya (JIRA)]

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Ishan Chattopadhyaya created an issue 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 Solr /  SOLR-10053 
 
 
 
  TestSolrCloudWithDelegationTokens failures  
 
 
 
 
 
 
 
 
 

Issue Type:
 
  Test 
 
 
 

Assignee:
 

 Unassigned 
 
 
 

Created:
 

 30/Jan/17 14:47 
 
 
 

Priority:
 
  Major 
 
 
 

Reporter:
 
 Ishan Chattopadhyaya 
 
 
 

Security Level:
 

 Public (Default Security Level. Issues are Public) 
 
 
 
 
 
 
 
 
 
 
The TestSolrCloudWithDelegationTokens tests fail often at Jenkins. I have been so far unable to reproduce them using the failing seeds. However, beasting these tests seem to cause failures (once after about 10-12 runs). 
Latest Jenkins failure: https://builds.apache.org/job/Lucene-Solr-NightlyTests-6.4/12/ 
It wasn't apparent what caused these failures. To cut down the noise on Jenkins, I propose that we disable the fix with @AwaitsFix annotation and continue to debug and fix this test. 
WDYT, Mark Miller? 
 
 
 
 
 
 
 
 
 
 
 
 

 
 Add Comment 
 
 
  

[jira] (SOLR-10053) TestSolrCloudWithDelegationTokens failures

[Ishan Chattopadhyaya (JIRA)]

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Ishan Chattopadhyaya updated an issue 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 Solr /  SOLR-10053 
 
 
 
  TestSolrCloudWithDelegationTokens failures  
 
 
 
 
 
 
 
 
 

Change By:
 
 Ishan Chattopadhyaya 
 
 
 
 
 
 
 
 
 
 The TestSolrCloudWithDelegationTokens tests fail often at Jenkins. I have been so far unable to reproduce them using the failing seeds. However, beasting these tests seem to cause failures (once after about 10-12 runs).Latest Jenkins failure: https://builds.apache.org/job/Lucene-Solr-NightlyTests-6.4/12/It wasn't apparent what caused these failures. To cut down the noise on Jenkins, I propose that we disable the  fix  test  with @AwaitsFix  (or bad apple)  annotation and continue to debug and fix this test.WDYT, [~markrmil...@gmail.com]? 
 
 
 
 
 
 
 
 
 
 
 
 

 
 Add Comment 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 
 
 

 This message was sent by Atlassian JIRA (v6.3.15#6346-sha1:dbc023d) 
 
 
 
 
  
 
 
 
 
 
 
 
 
   

[jira] (LUCENE-7650) Complexphrase queryparser stumbles on phrase query with trailing escaped colon

[Mikhail Khludnev (JIRA)]

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Mikhail Khludnev commented on  LUCENE-7650 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
  Re: Complexphrase queryparser stumbles on phrase query with trailing escaped colon  
 
 
 
 
 
 
 
 
 
 
since Complexphraseqp parses query twice, you need escape it twice. That is.  
 
 
 
 
 
 
 
 
 
 
 
 

 
 Add Comment 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 
 
 

 This message was sent by Atlassian JIRA (v6.3.15#6346-sha1:dbc023d)