Re: Do we leverage index sort for filters?

2020-03-04 Thread David Smiley 
I suspect you might ask in the context of Solr?  AFAIK I don't think Solr
takes advantage of any index sorting that might exist.  Maybe Christine
knows; she added the configuration of index sorting to Solr --
https://issues.apache.org/jira/browse/SOLR-13681

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


On Wed, Mar 4, 2020 at 6:56 PM Varun Thacker  wrote:

> If I have an index sorted by category and at search time filter on one
> category
>
> Do we currently take advantage of index sort for this sort of a filter
> query?
>
>

Do we leverage index sort for filters?

2020-03-04 Thread Varun Thacker 
If I have an index sorted by category and at search time filter on one
category

Do we currently take advantage of index sort for this sort of a filter
query?

Re: Solr: "Upgrade Notes" no longer in CHANGES.txt; See Ref Guide

2020-03-04 Thread Cassandra Targett 
Thanks David, that helps.

For sure we’ll have a separate page for 9.0, likely along the lines as we have 
for 6, 7, and 8. Maybe also starting in 9.0 I’ll revisit the idea of doing 
separate upgrade note pages too, but won’t do it now.
On Mar 3, 2020, 4:10 PM -0600, David Smiley , wrote:
>
> > On Tue, Mar 3, 2020 at 4:35 PM Cassandra Targett  
> > wrote:
> > > The Release Notes (feature/improvement highlights) will still be in 
> > > CWIKI, right (even if just for now)?
> >
> > Yes I think so.  This really should be strictly a major highlights kind of 
> > info -- somewhat brief.  We rely on the ref guide + CHANGES.txt for deeper 
> > info.
> >
> > > Do we want to try to include the Version of Major Components section in 
> > > the Ref Guide, or are we dropping it entirely?
> >
> > Drop entirely IMO.  We have separate pages with info for ZK & Java which 
> > are probably the only pertinent version numbers of related software.
> >
> > > Do we want to try to separate out the upgrade notes for each version into 
> > > separate pages at this point, or also save that as a possibility for 
> > > later?
> >
> > No opinion; your call.  Maybe start a new page at 9.0.
> >
> > ~ David
> >
> > > Thanks again -
> > >
> > > Cassandra
> > > On Feb 2, 2020, 11:16 PM -0600, David Smiley , 
> > > wrote:
> > > > I want to draw attention to an issue I've worked on that makes some 
> > > > notable changes to CHANGES.txt maintenance: 
> > > > https://issues.apache.org/jira/browse/SOLR-14149
> > > > It's already code-reviewed by Jan and Cassandra approves (a huge fan).  
> > > > In particular I want to draw attention to the move of the "upgrade 
> > > > notes" subject to be strictly in the Solr Ref Guide which goes here: 
> > > > https://github.com/apache/lucene-solr/blob/master/solr/solr-ref-guide/src/solr-upgrade-notes.adoc
> > > >   You can see the PR to see what it looks like.  I repeat, NO MORE 
> > > > adding upgrade notes to the top of CHANGES.txt.  If you have opposing 
> > > > views on this, please speak up in JIRA.  I plan to commit the issue in 
> > > > a couple days.
> > > >
> > > > ~ David Smiley
> > > > Apache Lucene/Solr Search Developer
> > > > http://www.linkedin.com/in/davidwsmiley

[jira] [Created] (PYLUCENE-54) Add download page

2020-03-04 Thread Jira 
Jan Høydahl created PYLUCENE-54:
---

 Summary: Add download page
 Key: PYLUCENE-54
 URL: https://issues.apache.org/jira/browse/PYLUCENE-54
 Project: PyLucene
  Issue Type: Task
Reporter: Jan Høydahl
Assignee: Andreas Vajda


I see that the Download button for PyLucene goes directly to closer.lua. Most 
people will end up in a mirror without the ASC and SHA files.

Some while ago there were new stricter requirements to link to ASC and SHA 
files directly from download pages of projects. We should probably do this for 
PyLucene as well, after the same template as we do for core and solr. We just 
need a config variable for LATEST_PYLUCENE_VERSION that you will change for 
every release, and the rest will update itself.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Re: "Cannot start mini solr cloud cluster" errors

2020-03-04 Thread Mike Drob 
Yep, this was definitely my change, sorry for the mess I've made of things
on Windows. Regardless, not trying to make excuses for myself here.

I've pushed a change that should make Windows happy, although I am not able
to reproduce it myself.

On Wed, Mar 4, 2020 at 10:27 AM Chris Hostetter 
wrote:

>
>
> https://lists.apache.org/thread.html/r830f54ed63361fcb3dbe13669d60cabbe87bca0309f3b5076c15d6af%40%3Cdev.lucene.apache.org%3E
>
> : Date: Tue, 3 Mar 2020 17:24:23 -0700
> : From: Erick Erickson 
> : Reply-To: dev@lucene.apache.org
> : To: dev@lucene.apache.org
> : Subject: "Cannot start mini solr cloud cluster" errors
> :
> : Here's one of the stack traces, anyone have a clue? Can't tell if it
> : reproduces, my internet connections are iffy for the next few days:
> :
> : Here's a seed, not sure whether it reproduces or not, train's pulling
> out:
> :
> : ant test  -Dtestcase=LegacyFieldFacetCloudTest
> : -Dtests.seed=CFEFCCB6130E91BE -Dtests.slow=true
> : -Dtests.badapples=trueDtests.locale=fr-CF
> : -Dtests.timezone=Asia/Nicosia -Dtests.asserts=true
> : -Dtests.file.encoding=ISO-8859-1
> :
> : Stack traces look like:
> :
> : [junit4]   2> 28559 INFO  (jetty-launcher-25-thread-2) [ ]
> : o.a.s.c.c.ConnectionManager Waiting for client to connect to ZooKeeper
> :[junit4]   2> 28845 INFO  (zkConnectionManagerCallback-27-thread-1)
> : [ ] o.a.s.c.c.ConnectionManager zkClient has connected
> :[junit4]   2> 28850 INFO  (jetty-launcher-25-thread-1) [ ]
> : o.a.s.c.c.ConnectionManager Client is connected to ZooKeeper
> :[junit4]   2> 28890 INFO  (zkConnectionManagerCallback-29-thread-1)
> : [ ] o.a.s.c.c.ConnectionManager zkClient has connected
> :[junit4]   2> 28891 INFO  (jetty-launcher-25-thread-2) [ ]
> : o.a.s.c.c.ConnectionManager Client is connected to ZooKeeper
> :[junit4]   2> 28896 INFO  (jetty-launcher-25-thread-1) [ ]
> : o.a.s.s.SolrDispatchFilter solr.xml found in ZooKeeper. Loading...
> :[junit4]   2> 28901 INFO  (jetty-launcher-25-thread-2) [ ]
> : o.a.s.s.SolrDispatchFilter solr.xml found in ZooKeeper. Loading...
> :[junit4]   2> 29071 ERROR (jetty-launcher-25-thread-1) [ ]
> : o.a.s.s.SolrDispatchFilter Could not start Solr. Check solr/home
> : property and the logs
> :[junit4]   2> 29071 ERROR (jetty-launcher-25-thread-1) [ ]
> : o.a.s.c.SolrCore null:java.lang.IllegalArgumentException: String
> : length must be a multiple of four.
> :[junit4]   2> at
> : org.apache.solr.common.util.Base64.base64ToByteArray(Base64.java:102)
> :[junit4]   2> at
> : org.apache.solr.util.CryptoKeys$RSAKeyPair.(CryptoKeys.java:369)
> :[junit4]   2> at
> :
> org.apache.solr.security.PublicKeyHandler.createKeyPair(PublicKeyHandler.java:59)
> :[junit4]   2> at
> :
> org.apache.solr.security.PublicKeyHandler.(PublicKeyHandler.java:43)
> :[junit4]   2> at
> : org.apache.solr.core.CoreContainer.(CoreContainer.java:342)
> :[junit4]   2> at
> : org.apache.solr.core.CoreContainer.(CoreContainer.java:330)
> :[junit4]   2> at
> :
> org.apache.solr.servlet.SolrDispatchFilter.createCoreContainer(SolrDispatchFilter.java:262)
> :[junit4]   2> at
> :
> org.apache.solr.servlet.SolrDispatchFilter.init(SolrDispatchFilter.java:183)
> :[junit4]   2> at
> : org.eclipse.jetty.servlet.FilterHolder.initialize(FilterHolder.java:134)
> :[junit4]   2> at
> :
> org.eclipse.jetty.servlet.ServletHandler.lambda$initialize$0(ServletHandler.java:751)
> :[junit4]   2> at
> :
> java.base/java.util.Spliterators$ArraySpliterator.forEachRemaining(Spliterators.java:948)
> :[junit4]   2> at
> :
> java.base/java.util.stream.Streams$ConcatSpliterator.forEachRemaining(Streams.java:734)
> :[junit4]   2> at
> :
> java.base/java.util.stream.Streams$ConcatSpliterator.forEachRemaining(Streams.java:734)
> :[junit4]   2> at
> :
> java.base/java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:658)
> :[junit4]   2> at
> :
> org.eclipse.jetty.servlet.ServletHandler.initialize(ServletHandler.java:744)
> :[junit4]   2> at
> :
> org.eclipse.jetty.servlet.ServletHandler.updateMappings(ServletHandler.java:1448)
> :[junit4]   2> at
> :
> org.eclipse.jetty.servlet.ServletHandler.setFilterMappings(ServletHandler.java:1507)
> :[junit4]   2> at
> :
> org.eclipse.jetty.servlet.ServletHandler.addFilterMapping(ServletHandler.java:1164)
> :[junit4]   2> at
> :
> org.eclipse.jetty.servlet.ServletHandler.addFilterWithMapping(ServletHandler.java:1003)
> :[junit4]   2> at
> :
> org.eclipse.jetty.servlet.ServletContextHandler.addFilter(ServletContextHandler.java:459)
> :[junit4]   2> at
> :
> org.apache.solr.client.solrj.embedded.JettySolrRunner$1.lifeCycleStarted(JettySolrRunner.java:382)
> :[junit4]   2> at
> :
> org.eclipse.jetty.util.component.AbstractLifeCycle.setStarted(AbstractLifeCycle.java:193)
> :[junit4]   2>

Re: "Cannot start mini solr cloud cluster" errors

2020-03-04 Thread Chris Hostetter 


https://lists.apache.org/thread.html/r830f54ed63361fcb3dbe13669d60cabbe87bca0309f3b5076c15d6af%40%3Cdev.lucene.apache.org%3E

: Date: Tue, 3 Mar 2020 17:24:23 -0700
: From: Erick Erickson 
: Reply-To: dev@lucene.apache.org
: To: dev@lucene.apache.org
: Subject: "Cannot start mini solr cloud cluster" errors
: 
: Here's one of the stack traces, anyone have a clue? Can't tell if it
: reproduces, my internet connections are iffy for the next few days:
: 
: Here's a seed, not sure whether it reproduces or not, train's pulling out:
: 
: ant test  -Dtestcase=LegacyFieldFacetCloudTest
: -Dtests.seed=CFEFCCB6130E91BE -Dtests.slow=true
: -Dtests.badapples=trueDtests.locale=fr-CF
: -Dtests.timezone=Asia/Nicosia -Dtests.asserts=true
: -Dtests.file.encoding=ISO-8859-1
: 
: Stack traces look like:
: 
: [junit4]   2> 28559 INFO  (jetty-launcher-25-thread-2) [ ]
: o.a.s.c.c.ConnectionManager Waiting for client to connect to ZooKeeper
:[junit4]   2> 28845 INFO  (zkConnectionManagerCallback-27-thread-1)
: [ ] o.a.s.c.c.ConnectionManager zkClient has connected
:[junit4]   2> 28850 INFO  (jetty-launcher-25-thread-1) [ ]
: o.a.s.c.c.ConnectionManager Client is connected to ZooKeeper
:[junit4]   2> 28890 INFO  (zkConnectionManagerCallback-29-thread-1)
: [ ] o.a.s.c.c.ConnectionManager zkClient has connected
:[junit4]   2> 28891 INFO  (jetty-launcher-25-thread-2) [ ]
: o.a.s.c.c.ConnectionManager Client is connected to ZooKeeper
:[junit4]   2> 28896 INFO  (jetty-launcher-25-thread-1) [ ]
: o.a.s.s.SolrDispatchFilter solr.xml found in ZooKeeper. Loading...
:[junit4]   2> 28901 INFO  (jetty-launcher-25-thread-2) [ ]
: o.a.s.s.SolrDispatchFilter solr.xml found in ZooKeeper. Loading...
:[junit4]   2> 29071 ERROR (jetty-launcher-25-thread-1) [ ]
: o.a.s.s.SolrDispatchFilter Could not start Solr. Check solr/home
: property and the logs
:[junit4]   2> 29071 ERROR (jetty-launcher-25-thread-1) [ ]
: o.a.s.c.SolrCore null:java.lang.IllegalArgumentException: String
: length must be a multiple of four.
:[junit4]   2> at
: org.apache.solr.common.util.Base64.base64ToByteArray(Base64.java:102)
:[junit4]   2> at
: org.apache.solr.util.CryptoKeys$RSAKeyPair.(CryptoKeys.java:369)
:[junit4]   2> at
: 
org.apache.solr.security.PublicKeyHandler.createKeyPair(PublicKeyHandler.java:59)
:[junit4]   2> at
: org.apache.solr.security.PublicKeyHandler.(PublicKeyHandler.java:43)
:[junit4]   2> at
: org.apache.solr.core.CoreContainer.(CoreContainer.java:342)
:[junit4]   2> at
: org.apache.solr.core.CoreContainer.(CoreContainer.java:330)
:[junit4]   2> at
: 
org.apache.solr.servlet.SolrDispatchFilter.createCoreContainer(SolrDispatchFilter.java:262)
:[junit4]   2> at
: org.apache.solr.servlet.SolrDispatchFilter.init(SolrDispatchFilter.java:183)
:[junit4]   2> at
: org.eclipse.jetty.servlet.FilterHolder.initialize(FilterHolder.java:134)
:[junit4]   2> at
: 
org.eclipse.jetty.servlet.ServletHandler.lambda$initialize$0(ServletHandler.java:751)
:[junit4]   2> at
: 
java.base/java.util.Spliterators$ArraySpliterator.forEachRemaining(Spliterators.java:948)
:[junit4]   2> at
: 
java.base/java.util.stream.Streams$ConcatSpliterator.forEachRemaining(Streams.java:734)
:[junit4]   2> at
: 
java.base/java.util.stream.Streams$ConcatSpliterator.forEachRemaining(Streams.java:734)
:[junit4]   2> at
: 
java.base/java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:658)
:[junit4]   2> at
: org.eclipse.jetty.servlet.ServletHandler.initialize(ServletHandler.java:744)
:[junit4]   2> at
: 
org.eclipse.jetty.servlet.ServletHandler.updateMappings(ServletHandler.java:1448)
:[junit4]   2> at
: 
org.eclipse.jetty.servlet.ServletHandler.setFilterMappings(ServletHandler.java:1507)
:[junit4]   2> at
: 
org.eclipse.jetty.servlet.ServletHandler.addFilterMapping(ServletHandler.java:1164)
:[junit4]   2> at
: 
org.eclipse.jetty.servlet.ServletHandler.addFilterWithMapping(ServletHandler.java:1003)
:[junit4]   2> at
: 
org.eclipse.jetty.servlet.ServletContextHandler.addFilter(ServletContextHandler.java:459)
:[junit4]   2> at
: 
org.apache.solr.client.solrj.embedded.JettySolrRunner$1.lifeCycleStarted(JettySolrRunner.java:382)
:[junit4]   2> at
: 
org.eclipse.jetty.util.component.AbstractLifeCycle.setStarted(AbstractLifeCycle.java:193)
:[junit4]   2> at
: 
org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:73)
:[junit4]   2> at
: 
org.apache.solr.client.solrj.embedded.JettySolrRunner.retryOnPortBindFailure(JettySolrRunner.java:565)
:[junit4]   2> at
: 
org.apache.solr.client.solrj.embedded.JettySolrRunner.start(JettySolrRunner.java:504)
:[junit4]   2> at
: 
org.apache.solr.client.solrj.embedded.JettySolrRunner.start(JettySolrRunner.java:472)
:[junit4]   2> at
:

Re: 8.5 release

2020-03-04 Thread Alan Woodward 
I’ve created a branch for the 8.5 release (`branch_8_5`) and pushed it to the 
apache repository.  We’re now at feature freeze, so only bug fixes should be 
pushed to the branch.

I can see from 
https://issues.apache.org/jira/issues/?jql=project%20in%20(SOLR%2C%20LUCENE)%20AND%20status%20in%20(Open%2C%20Reopened)%20AND%20priority%20%3D%20Blocker%20AND%20fixVersion%20%3D%208.5%20ORDER%20BY%20priority%20DESC
 

 that we have 4 tickets marked as Blockers for this release.  I plan to build a 
first release candidate next Monday, which gives us a few days to resolve 
these.  If that’s not going to be long enough, please let me know.

Uwe, Steve, can one of you start the Jenkins tasks for the new branch?

Thanks, Alan

> On 3 Mar 2020, at 14:50, Alan Woodward  wrote:
> 
> PSA: I’ve had to generate a new GPG key for this release, and it takes a 
> while for it to get mirrored to the lucene KEYS file.  I’ll hold off cutting 
> the branch until everything is ready, so it will probably now be tomorrow UK 
> time before I start the release proper.
> 
>> On 25 Feb 2020, at 07:49, Noble Paul  wrote:
>> 
>> +1
>> 
>> On Wed, Feb 19, 2020 at 9:35 PM Ignacio Vera  wrote:
>>> 
>>> +1
>>> 
>>> On Tue, Feb 18, 2020 at 7:26 PM Jan Høydahl  wrote:
 
 +1
 
 That should give us time to update release docs for the new website too.
 
 Jan Høydahl
 
 18. feb. 2020 kl. 18:28 skrev Adrien Grand :
 
 
 +1
 
 On Tue, Feb 18, 2020 at 4:58 PM Alan Woodward  wrote:
> 
> Hi all,
> 
> It’s been a while since we released lucene-solr 8.4, and we’ve 
> accumulated quite a few nice new features since then.  I’d like to 
> volunteer to be a release manager for an 8.5 release.  If there's 
> agreement, then I plan to cut the release branch two weeks today, on 
> Tuesday 3rd March.
> 
> - Alan
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
> 
 
 
 --
 Adrien
>> 
>> 
>> 
>> -- 
>> -
>> Noble Paul
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>> 
>

Re: Welcome Nhat Nguyen to the PMC

2020-03-04 Thread Jan Høydahl 
Welcome Nhat!

Jan

> 3. mar. 2020 kl. 17:34 skrev Adrien Grand :
> 
> I am pleased to announce that Nhat Nguyen has accepted the PMC's invitation 
> to join.
> 
> Welcome Nhat!
> 
> -- 
> Adrien


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

Re: "Cannot start mini solr cloud cluster" errors

2020-03-04 Thread Erick Erickson 
Sending the one i saved to your personal email...


On Wed, Mar 4, 2020, 07:38 Mike Drob  wrote:

> I suspect it’s related to my changes in SOLR-14223, can you share more
> logs?
>
> On Wed, Mar 4, 2020 at 6:34 AM Erick Erickson 
> wrote:
>
>> I see 2-3 failures a day come by the dev list with this failure. I have
>> the full console output from one of them if you’d like to see it. Been
>> happening for the last couple of weeks (?).
>>
>> Best,
>> Erick
>>
>> On Mar 3, 2020, at 20:31, David Smiley  wrote:
>>
>> 
>>
>> I wasn't able to reproduce this.
>>
>> ~ David Smiley
>> Apache Lucene/Solr Search Developer
>> http://www.linkedin.com/in/davidwsmiley
>>
>>
>> On Tue, Mar 3, 2020 at 7:25 PM Erick Erickson 
>> wrote:
>>
>>> Here's one of the stack traces, anyone have a clue? Can't tell if it
>>> reproduces, my internet connections are iffy for the next few days:
>>>
>>> Here's a seed, not sure whether it reproduces or not, train's pulling
>>> out:
>>>
>>> ant test  -Dtestcase=LegacyFieldFacetCloudTest
>>> -Dtests.seed=CFEFCCB6130E91BE -Dtests.slow=true
>>> -Dtests.badapples=trueDtests.locale=fr-CF
>>> -Dtests.timezone=Asia/Nicosia -Dtests.asserts=true
>>> -Dtests.file.encoding=ISO-8859-1
>>>
>>> Stack traces look like:
>>>
>>> [junit4]   2> 28559 INFO  (jetty-launcher-25-thread-2) [ ]
>>> o.a.s.c.c.ConnectionManager Waiting for client to connect to ZooKeeper
>>>[junit4]   2> 28845 INFO  (zkConnectionManagerCallback-27-thread-1)
>>> [ ] o.a.s.c.c.ConnectionManager zkClient has connected
>>>[junit4]   2> 28850 INFO  (jetty-launcher-25-thread-1) [ ]
>>> o.a.s.c.c.ConnectionManager Client is connected to ZooKeeper
>>>[junit4]   2> 28890 INFO  (zkConnectionManagerCallback-29-thread-1)
>>> [ ] o.a.s.c.c.ConnectionManager zkClient has connected
>>>[junit4]   2> 28891 INFO  (jetty-launcher-25-thread-2) [ ]
>>> o.a.s.c.c.ConnectionManager Client is connected to ZooKeeper
>>>[junit4]   2> 28896 INFO  (jetty-launcher-25-thread-1) [ ]
>>> o.a.s.s.SolrDispatchFilter solr.xml found in ZooKeeper. Loading...
>>>[junit4]   2> 28901 INFO  (jetty-launcher-25-thread-2) [ ]
>>> o.a.s.s.SolrDispatchFilter solr.xml found in ZooKeeper. Loading...
>>>[junit4]   2> 29071 ERROR (jetty-launcher-25-thread-1) [ ]
>>> o.a.s.s.SolrDispatchFilter Could not start Solr. Check solr/home
>>> property and the logs
>>>[junit4]   2> 29071 ERROR (jetty-launcher-25-thread-1) [ ]
>>> o.a.s.c.SolrCore null:java.lang.IllegalArgumentException: String
>>> length must be a multiple of four.
>>>[junit4]   2> at
>>> org.apache.solr.common.util.Base64.base64ToByteArray(Base64.java:102)
>>>[junit4]   2> at
>>> org.apache.solr.util.CryptoKeys$RSAKeyPair.(CryptoKeys.java:369)
>>>[junit4]   2> at
>>>
>>> org.apache.solr.security.PublicKeyHandler.createKeyPair(PublicKeyHandler.java:59)
>>>[junit4]   2> at
>>>
>>> org.apache.solr.security.PublicKeyHandler.(PublicKeyHandler.java:43)
>>>[junit4]   2> at
>>> org.apache.solr.core.CoreContainer.(CoreContainer.java:342)
>>>[junit4]   2> at
>>> org.apache.solr.core.CoreContainer.(CoreContainer.java:330)
>>>[junit4]   2> at
>>>
>>> org.apache.solr.servlet.SolrDispatchFilter.createCoreContainer(SolrDispatchFilter.java:262)
>>>[junit4]   2> at
>>>
>>> org.apache.solr.servlet.SolrDispatchFilter.init(SolrDispatchFilter.java:183)
>>>[junit4]   2> at
>>> org.eclipse.jetty.servlet.FilterHolder.initialize(FilterHolder.java:134)
>>>[junit4]   2> at
>>>
>>> org.eclipse.jetty.servlet.ServletHandler.lambda$initialize$0(ServletHandler.java:751)
>>>[junit4]   2> at
>>>
>>> java.base/java.util.Spliterators$ArraySpliterator.forEachRemaining(Spliterators.java:948)
>>>[junit4]   2> at
>>>
>>> java.base/java.util.stream.Streams$ConcatSpliterator.forEachRemaining(Streams.java:734)
>>>[junit4]   2> at
>>>
>>> java.base/java.util.stream.Streams$ConcatSpliterator.forEachRemaining(Streams.java:734)
>>>[junit4]   2> at
>>>
>>> java.base/java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:658)
>>>[junit4]   2> at
>>>
>>> org.eclipse.jetty.servlet.ServletHandler.initialize(ServletHandler.java:744)
>>>[junit4]   2> at
>>>
>>> org.eclipse.jetty.servlet.ServletHandler.updateMappings(ServletHandler.java:1448)
>>>[junit4]   2> at
>>>
>>> org.eclipse.jetty.servlet.ServletHandler.setFilterMappings(ServletHandler.java:1507)
>>>[junit4]   2> at
>>>
>>> org.eclipse.jetty.servlet.ServletHandler.addFilterMapping(ServletHandler.java:1164)
>>>[junit4]   2> at
>>>
>>> org.eclipse.jetty.servlet.ServletHandler.addFilterWithMapping(ServletHandler.java:1003)
>>>[junit4]   2> at
>>>
>>> org.eclipse.jetty.servlet.ServletContextHandler.addFilter(ServletContextHandler.java:459)
>>>[junit4]   2> at
>>>
>>> org.apache.solr.client.solrj.embedded.JettySolrRunner$1.lifeCycleStarted(JettySolrRunner.java:382)
>>>[junit4]

Re: "Cannot start mini solr cloud cluster" errors

2020-03-04 Thread Mike Drob 
I suspect it’s related to my changes in SOLR-14223, can you share more logs?

On Wed, Mar 4, 2020 at 6:34 AM Erick Erickson 
wrote:

> I see 2-3 failures a day come by the dev list with this failure. I have
> the full console output from one of them if you’d like to see it. Been
> happening for the last couple of weeks (?).
>
> Best,
> Erick
>
> On Mar 3, 2020, at 20:31, David Smiley  wrote:
>
> 
>
> I wasn't able to reproduce this.
>
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley
>
>
> On Tue, Mar 3, 2020 at 7:25 PM Erick Erickson 
> wrote:
>
>> Here's one of the stack traces, anyone have a clue? Can't tell if it
>> reproduces, my internet connections are iffy for the next few days:
>>
>> Here's a seed, not sure whether it reproduces or not, train's pulling out:
>>
>> ant test  -Dtestcase=LegacyFieldFacetCloudTest
>> -Dtests.seed=CFEFCCB6130E91BE -Dtests.slow=true
>> -Dtests.badapples=trueDtests.locale=fr-CF
>> -Dtests.timezone=Asia/Nicosia -Dtests.asserts=true
>> -Dtests.file.encoding=ISO-8859-1
>>
>> Stack traces look like:
>>
>> [junit4]   2> 28559 INFO  (jetty-launcher-25-thread-2) [ ]
>> o.a.s.c.c.ConnectionManager Waiting for client to connect to ZooKeeper
>>[junit4]   2> 28845 INFO  (zkConnectionManagerCallback-27-thread-1)
>> [ ] o.a.s.c.c.ConnectionManager zkClient has connected
>>[junit4]   2> 28850 INFO  (jetty-launcher-25-thread-1) [ ]
>> o.a.s.c.c.ConnectionManager Client is connected to ZooKeeper
>>[junit4]   2> 28890 INFO  (zkConnectionManagerCallback-29-thread-1)
>> [ ] o.a.s.c.c.ConnectionManager zkClient has connected
>>[junit4]   2> 28891 INFO  (jetty-launcher-25-thread-2) [ ]
>> o.a.s.c.c.ConnectionManager Client is connected to ZooKeeper
>>[junit4]   2> 28896 INFO  (jetty-launcher-25-thread-1) [ ]
>> o.a.s.s.SolrDispatchFilter solr.xml found in ZooKeeper. Loading...
>>[junit4]   2> 28901 INFO  (jetty-launcher-25-thread-2) [ ]
>> o.a.s.s.SolrDispatchFilter solr.xml found in ZooKeeper. Loading...
>>[junit4]   2> 29071 ERROR (jetty-launcher-25-thread-1) [ ]
>> o.a.s.s.SolrDispatchFilter Could not start Solr. Check solr/home
>> property and the logs
>>[junit4]   2> 29071 ERROR (jetty-launcher-25-thread-1) [ ]
>> o.a.s.c.SolrCore null:java.lang.IllegalArgumentException: String
>> length must be a multiple of four.
>>[junit4]   2> at
>> org.apache.solr.common.util.Base64.base64ToByteArray(Base64.java:102)
>>[junit4]   2> at
>> org.apache.solr.util.CryptoKeys$RSAKeyPair.(CryptoKeys.java:369)
>>[junit4]   2> at
>>
>> org.apache.solr.security.PublicKeyHandler.createKeyPair(PublicKeyHandler.java:59)
>>[junit4]   2> at
>> org.apache.solr.security.PublicKeyHandler.(PublicKeyHandler.java:43)
>>[junit4]   2> at
>> org.apache.solr.core.CoreContainer.(CoreContainer.java:342)
>>[junit4]   2> at
>> org.apache.solr.core.CoreContainer.(CoreContainer.java:330)
>>[junit4]   2> at
>>
>> org.apache.solr.servlet.SolrDispatchFilter.createCoreContainer(SolrDispatchFilter.java:262)
>>[junit4]   2> at
>>
>> org.apache.solr.servlet.SolrDispatchFilter.init(SolrDispatchFilter.java:183)
>>[junit4]   2> at
>> org.eclipse.jetty.servlet.FilterHolder.initialize(FilterHolder.java:134)
>>[junit4]   2> at
>>
>> org.eclipse.jetty.servlet.ServletHandler.lambda$initialize$0(ServletHandler.java:751)
>>[junit4]   2> at
>>
>> java.base/java.util.Spliterators$ArraySpliterator.forEachRemaining(Spliterators.java:948)
>>[junit4]   2> at
>>
>> java.base/java.util.stream.Streams$ConcatSpliterator.forEachRemaining(Streams.java:734)
>>[junit4]   2> at
>>
>> java.base/java.util.stream.Streams$ConcatSpliterator.forEachRemaining(Streams.java:734)
>>[junit4]   2> at
>>
>> java.base/java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:658)
>>[junit4]   2> at
>>
>> org.eclipse.jetty.servlet.ServletHandler.initialize(ServletHandler.java:744)
>>[junit4]   2> at
>>
>> org.eclipse.jetty.servlet.ServletHandler.updateMappings(ServletHandler.java:1448)
>>[junit4]   2> at
>>
>> org.eclipse.jetty.servlet.ServletHandler.setFilterMappings(ServletHandler.java:1507)
>>[junit4]   2> at
>>
>> org.eclipse.jetty.servlet.ServletHandler.addFilterMapping(ServletHandler.java:1164)
>>[junit4]   2> at
>>
>> org.eclipse.jetty.servlet.ServletHandler.addFilterWithMapping(ServletHandler.java:1003)
>>[junit4]   2> at
>>
>> org.eclipse.jetty.servlet.ServletContextHandler.addFilter(ServletContextHandler.java:459)
>>[junit4]   2> at
>>
>> org.apache.solr.client.solrj.embedded.JettySolrRunner$1.lifeCycleStarted(JettySolrRunner.java:382)
>>[junit4]   2> at
>>
>> org.eclipse.jetty.util.component.AbstractLifeCycle.setStarted(AbstractLifeCycle.java:193)
>>[junit4]   2> at
>>
>> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:73)
>>

Re: Welcome Nhat Nguyen to the PMC

2020-03-04 Thread Erick Erickson 
Welcome Nhat!

Best,
Erick

> On Mar 4, 2020, at 06:39, Michael McCandless  
> wrote:
> 
> 
> Welcome Nhat!
> 
> Mike McCandless
> 
> http://blog.mikemccandless.com
> 
> 
>> On Tue, Mar 3, 2020 at 11:34 AM Adrien Grand  wrote:
>> I am pleased to announce that Nhat Nguyen has accepted the PMC's invitation 
>> to join.
>> 
>> Welcome Nhat!
>> 
>> -- 
>> Adrien

Re: Welcome Nhat Nguyen to the PMC

2020-03-04 Thread Michael McCandless 
Welcome Nhat!

Mike McCandless

http://blog.mikemccandless.com


On Tue, Mar 3, 2020 at 11:34 AM Adrien Grand  wrote:

> I am pleased to announce that Nhat Nguyen has accepted the PMC's
> invitation to join.
>
> Welcome Nhat!
>
> --
> Adrien
>

Re: "Cannot start mini solr cloud cluster" errors

2020-03-04 Thread Erick Erickson 
I see 2-3 failures a day come by the dev list with this failure. I have the 
full console output from one of them if you’d like to see it. Been happening 
for the last couple of weeks (?).

Best,
Erick

> On Mar 3, 2020, at 20:31, David Smiley  wrote:
> 
> 
> I wasn't able to reproduce this.
> 
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley
> 
> 
>> On Tue, Mar 3, 2020 at 7:25 PM Erick Erickson  
>> wrote:
>> Here's one of the stack traces, anyone have a clue? Can't tell if it
>> reproduces, my internet connections are iffy for the next few days:
>> 
>> Here's a seed, not sure whether it reproduces or not, train's pulling out:
>> 
>> ant test  -Dtestcase=LegacyFieldFacetCloudTest
>> -Dtests.seed=CFEFCCB6130E91BE -Dtests.slow=true
>> -Dtests.badapples=trueDtests.locale=fr-CF
>> -Dtests.timezone=Asia/Nicosia -Dtests.asserts=true
>> -Dtests.file.encoding=ISO-8859-1
>> 
>> Stack traces look like:
>> 
>> [junit4]   2> 28559 INFO  (jetty-launcher-25-thread-2) [ ]
>> o.a.s.c.c.ConnectionManager Waiting for client to connect to ZooKeeper
>>[junit4]   2> 28845 INFO  (zkConnectionManagerCallback-27-thread-1)
>> [ ] o.a.s.c.c.ConnectionManager zkClient has connected
>>[junit4]   2> 28850 INFO  (jetty-launcher-25-thread-1) [ ]
>> o.a.s.c.c.ConnectionManager Client is connected to ZooKeeper
>>[junit4]   2> 28890 INFO  (zkConnectionManagerCallback-29-thread-1)
>> [ ] o.a.s.c.c.ConnectionManager zkClient has connected
>>[junit4]   2> 28891 INFO  (jetty-launcher-25-thread-2) [ ]
>> o.a.s.c.c.ConnectionManager Client is connected to ZooKeeper
>>[junit4]   2> 28896 INFO  (jetty-launcher-25-thread-1) [ ]
>> o.a.s.s.SolrDispatchFilter solr.xml found in ZooKeeper. Loading...
>>[junit4]   2> 28901 INFO  (jetty-launcher-25-thread-2) [ ]
>> o.a.s.s.SolrDispatchFilter solr.xml found in ZooKeeper. Loading...
>>[junit4]   2> 29071 ERROR (jetty-launcher-25-thread-1) [ ]
>> o.a.s.s.SolrDispatchFilter Could not start Solr. Check solr/home
>> property and the logs
>>[junit4]   2> 29071 ERROR (jetty-launcher-25-thread-1) [ ]
>> o.a.s.c.SolrCore null:java.lang.IllegalArgumentException: String
>> length must be a multiple of four.
>>[junit4]   2> at
>> org.apache.solr.common.util.Base64.base64ToByteArray(Base64.java:102)
>>[junit4]   2> at
>> org.apache.solr.util.CryptoKeys$RSAKeyPair.(CryptoKeys.java:369)
>>[junit4]   2> at
>> org.apache.solr.security.PublicKeyHandler.createKeyPair(PublicKeyHandler.java:59)
>>[junit4]   2> at
>> org.apache.solr.security.PublicKeyHandler.(PublicKeyHandler.java:43)
>>[junit4]   2> at
>> org.apache.solr.core.CoreContainer.(CoreContainer.java:342)
>>[junit4]   2> at
>> org.apache.solr.core.CoreContainer.(CoreContainer.java:330)
>>[junit4]   2> at
>> org.apache.solr.servlet.SolrDispatchFilter.createCoreContainer(SolrDispatchFilter.java:262)
>>[junit4]   2> at
>> org.apache.solr.servlet.SolrDispatchFilter.init(SolrDispatchFilter.java:183)
>>[junit4]   2> at
>> org.eclipse.jetty.servlet.FilterHolder.initialize(FilterHolder.java:134)
>>[junit4]   2> at
>> org.eclipse.jetty.servlet.ServletHandler.lambda$initialize$0(ServletHandler.java:751)
>>[junit4]   2> at
>> java.base/java.util.Spliterators$ArraySpliterator.forEachRemaining(Spliterators.java:948)
>>[junit4]   2> at
>> java.base/java.util.stream.Streams$ConcatSpliterator.forEachRemaining(Streams.java:734)
>>[junit4]   2> at
>> java.base/java.util.stream.Streams$ConcatSpliterator.forEachRemaining(Streams.java:734)
>>[junit4]   2> at
>> java.base/java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:658)
>>[junit4]   2> at
>> org.eclipse.jetty.servlet.ServletHandler.initialize(ServletHandler.java:744)
>>[junit4]   2> at
>> org.eclipse.jetty.servlet.ServletHandler.updateMappings(ServletHandler.java:1448)
>>[junit4]   2> at
>> org.eclipse.jetty.servlet.ServletHandler.setFilterMappings(ServletHandler.java:1507)
>>[junit4]   2> at
>> org.eclipse.jetty.servlet.ServletHandler.addFilterMapping(ServletHandler.java:1164)
>>[junit4]   2> at
>> org.eclipse.jetty.servlet.ServletHandler.addFilterWithMapping(ServletHandler.java:1003)
>>[junit4]   2> at
>> org.eclipse.jetty.servlet.ServletContextHandler.addFilter(ServletContextHandler.java:459)
>>[junit4]   2> at
>> org.apache.solr.client.solrj.embedded.JettySolrRunner$1.lifeCycleStarted(JettySolrRunner.java:382)
>>[junit4]   2> at
>> org.eclipse.jetty.util.component.AbstractLifeCycle.setStarted(AbstractLifeCycle.java:193)
>>[junit4]   2> at
>> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:73)
>>[junit4]   2> at
>> org.apache.solr.client.solrj.embedded.JettySolrRunner.retryOnPortBindFailure(JettySolrRunner.java:565)
>>[junit4]   2> at
>>

Re: Welcome Nhat Nguyen to the PMC

2020-03-04 Thread Ignacio Vera 
Congratulations and welcome, Nhat!

On Wed, Mar 4, 2020 at 12:58 PM Dawid Weiss  wrote:

> Welcome, Nhat!
> Dawid
>
> On Tue, Mar 3, 2020 at 5:34 PM Adrien Grand  wrote:
> >
> > I am pleased to announce that Nhat Nguyen has accepted the PMC's
> invitation to join.
> >
> > Welcome Nhat!
> >
> > --
> > Adrien
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

Re: Docs on our build infrastructure

2020-03-04 Thread Martin Gainty 
https://builds.apache.org/job/Lucene-Solr-Maven-master/lastBuild/

lastBuild on jenkins build spent 1hr 35min waiting
what is it that the build is waiting on?
where is the pom?
where is the gradle?
where is the ant build.xml ?

it is very concerning that these files are perhaps on individual machines but 
not on repos while the build files are
missing
undocumented

?
m-


From: David Smiley 
Sent: Wednesday, March 4, 2020 12:55 AM
To: Solr/Lucene Dev 
Subject: Docs on our build infrastructure

Why do we have CI builds at not just the ASF but also Uwe's machine and also 
Steve Rowe's?  I'm not sure more is better.  Can someone knowledgeable about 
our build situation consider writing a bit of developer documentation on what 
is where and why?  I recently wanted to share this info but didn't find it... 
and I know very little of it.  We've got this old cwiki page: 
https://cwiki.apache.org/confluence/display/LUCENE/NightlyBuilds  and also 
Hossman's page is nice: http://fucit.org/solr-jenkins-reports/

BTW I was chatting with the "Klera" team about their tools and they are 
interested in exploring if their tools can help us put out the build failure 
fires -- e.g. email alerts to pertinent individuals as one example.  I'm 
following up with them.

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

Re: Commit / Code Review Policy

2020-03-04 Thread Daniel Ruggeri 
Hi, all;
   I could have *sworn* I replied... but could find no record in my sent folder 
when David dutifully followed up with a ping. *facepalm*

   Yes, I volunteered to participate and help where I can as a member of The 
ASF board, VP Fundraising, ComDev participant, or whatever hat I might be able 
to bring with me. Of course, I bear no special credentials here... we all hang 
out as volunteers. Reviewing the most recent board report[1], I detected:
> We're discussing how to semi-require code reviews by defining project 
> guidelines. We invite a board member to help/advice how to navigate this 
> balance. 
So, yeah, here I am :-) My primary interest is to be sure we're approaching the 
discussion with community as our primary lens.

   I definitely reviewed the email thread, replies, and Confluence wiki 
document. In my interpretation of the discussion, a few things stood out:
- There were some synchronous discussions that occurred off the list, which can 
lead to accidentally excluding important community voices from the 
conversation. By bringing the discussion back to the list before attempting to 
make a decision, the critical levels of transparency are maintained. This is 
definitely A Good Thing.
- I perceived a lot of constructive feedback on the initial draft which appears 
(to me) to have brought the draft much closer to a document that represents 
consensus. Said another way, I don't detect conflict per se (please correct me 
if I'm wrong)
- I think the feedback (and subsequent incorporation of that feedback into the 
guidelines) about exception cases like doc fixes and "small" changes is 
brilliant. On the httpd project, as a parallel example, we have a RTC policy 
for release branches except for docs - which are CTR. Indeed, a "docs 
committer" is the same as an "httpd committer"... we don't separate privileges 
because this social contract has worked well for 2 decades.
- The current content of the document seems reasonable given the current 
environment. One thing that is unclear to me based on a quick browsing of the 
docs is what the branching strategy is for the project. What I gather is that 
the master branch is the release branch and features are added to master or 
merged in from short-lived feature branches. It'd be helpful to clarify this.
- The proposed document draws additional parallels to things that work for 
httpd. Often times, we will share patches to the list for feedback before 
commits (similar to the Jira tickets proposed). We also operate trunk as CTR, 
but require 3 +1 backport votes to the long-lived release branches. This 
proposal has a similar net effect: bits that get released are (generally) 
intended to be "actively" reviewed before commit. It does fall short of 
requiring a consensus-style vote for release branches as httpd does... but 
that's OK.

All told, this proposal seems quite reasonable to me because it has been 
discussed by the community, feedback has been incorporated, and the content of 
the proposal seems totally doable. That said, I'm open to other inquiries if 
there's something an external perspective can provide. How can I help?


[1] https://whimsy.apache.org/board/minutes/Lucene.html

P.S.
Nabble, mbox, etc... they're OK, but have you tried Ponymail?
https://lists.apache.org/x/thread.html/770ef83a8ed3a3d5d161c4a2cd812b4bdde47464d439c09ec31164dd@%3Cdev.lucene.apache.org%3E
I'm a convert, for sure!
-- 
Daniel Ruggeri
Director, VP Fundraising, member, httpd PMC
The Apache Software Foundation

On February 7, 2020 9:14:37 AM CST, David Smiley  
wrote:
>I neglected to try and close up this long thread on the subject of code
>review guidance.  In the project's board report to the ASF, I asked for
>help; Daniel Ruggeri (an ASF VP) graciously volunteered.  He's on the
>"To"
>line to my message here; he's not a member of our dev list.
>
>Daniel:
>
>Thanks in advance for any assistance / guidance you have to offer.
>
>I suggest first reading through this thread:
>https://lucene.472066.n3.nabble.com/Commit-Code-Review-Policy-td4452928.html
>I find Nabble much easier to navigate than the ASF official archive,
>but
>that's here if you prefer:
>http://mail-archives.apache.org/mod_mbox/lucene-dev/201911.mbox/%3ccabewpvet1u4xgxqadddhes+uybexmuw33c8fbs5bzdlzulc...@mail.gmail.com%3e
>  It starts November 26th and ended December 8th.
>
>The second thing is my proposal document stored in Confluence.  I have
>yet
>to rename it as I said I would but I'll let it be for a little bit so
>the
>links continue to work for the moment:
>https://cwiki.apache.org/confluence/display/LUCENE/Commit+Policy+-+DRAFT
>Everything from "Tests" heading onwards has a "[PENDING DISCUSSION]"
>notice
>and can be ignored for the time being.
>
>~ David

Re: Welcome Nhat Nguyen to the PMC

2020-03-04 Thread Dawid Weiss 
Welcome, Nhat!
Dawid

On Tue, Mar 3, 2020 at 5:34 PM Adrien Grand  wrote:
>
> I am pleased to announce that Nhat Nguyen has accepted the PMC's invitation 
> to join.
>
> Welcome Nhat!
>
> --
> Adrien

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

Re: Welcome Nhat Nguyen to the PMC

2020-03-04 Thread Koji Sekiguchi 

Congratulations and welcome, Nhat!

Koji


On 2020/03/04 1:34, Adrien Grand wrote:

I am pleased to announce that Nhat Nguyen has accepted the PMC's invitation to 
join.

Welcome Nhat!

--
Adrien


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

Re: CHANGES.txt and issue categorization

2020-03-04 Thread Adrien Grand 
+1 to move these entries.

On Wed, Mar 4, 2020 at 4:27 AM David Smiley 
wrote:

> I'll simply move these items around tomorrow this time, unless I hear
> feedback to the contrary.
>
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley
>
>
> On Mon, Mar 2, 2020 at 1:07 PM David Smiley 
> wrote:
>
>> I'd like us to reflect on how we categorize issues in CHANGES.txt.  We
>> have these categories:
>> (Lucene) 'API Changes', 'New Features', 'Improvements', 'Optimizations',
>> 'Bug Fixes', 'Other'
>> (Solr) 'New Features', 'Improvements', 'Optimizations', 'Bug Fixes',
>> 'Other Changes'
>> (I lifted these from dev-tools/scripts/addVersion.py line 215)
>>
>> In particular, I'm often surprised at how some of us categorize New
>> Features or Improvements that should better be categorized as something
>> else.  I think the root cause of these problems may be that we don't have
>> JIRA categories that directly align.  Furthermore, our dev practices will
>> typically result in a CHANGES.txt being added out of band from the
>> code-review process, and thus no peer-review on ideal placement.
>> Furthermore the message itself is often not code reviewed but should be.
>> Perhaps we can simply get in the habit of adding a JIRA comment (or GH code
>> review) what we propose the category & issue summary should be.
>>
>> Here is my attempt at a definition for _some_ of these categories.  I
>> don't pretend to think we all agree 100% but it's up for discussion:
>> 
>> * New Features:  A user-visible new capability.  Usually opt-in.
>>
>> * Improvements:  A user-visible improvement to an existing capability
>> that somehow expands its ability or that which improves the behavior.  Not
>> a refactoring, not an optimization.
>>
>> * Optimizations: Something is now more efficient.  Usually automatic (not
>> opt-in).
>>
>> * Other:  Anything else: Refactorings, tests, build, docs, etc.  And
>> adding log statements.
>> 
>>
>> I recommend the following changes to Lucene 8.5:
>>
>> These are "Improvements" that I think are better categorized as
>> "Optimizations"
>> * LUCENE-9211: Add compression for Binary doc value fields. (Mark Harwood)
>> * LUCENE-4702: Better compression of terms dictionaries. (Adrien Grand)
>> * LUCENE-9228: Sort dvUpdates in the term order before applying if they
>> all update a
>>   single field to the same value. This optimization can reduce the flush
>> time by around
>>   20% for the docValues update user cases. (Nhat Nguyen, Adrien Grand,
>> Simon Willnauer)
>> * LUCENE-9245: Reduce AutomatonTermsEnum memory usage. (Bruno Roustant,
>> Robert Muir)
>> * LUCENE-9237: Faster UniformSplit intersect TermsEnum. (Bruno Roustant)
>>
>> These "Improvements" I think are better categorized as "Other":
>> * LUCENE-9109: Backport some changes from master (except StackWalker) to
>> improve
>>   TestSecurityManager (Uwe Schindler)
>> * LUCENE-9110: Backport refactored stack analysis in tests to use
>> generalized
>>   LuceneTestCase methods (Uwe Schindler)
>> * LUCENE-9141: Simplify LatLonShapeXQuery API by adding a new abstract
>> class called LatLonGeometry. Queries are
>>   executed with input objects that extend such interface. (Ignacio Vera)
>> * LUCENE-9194: Simplify XYShapeXQuery API by adding a new abstract class
>> called XYGeometry. Queries are
>>   executed with input objects that extend such interface. (Ignacio Vera)
>>
>> Maybe this "Other" item should be  "Optimization"? (not sure):
>> * LUCENE-9068: FuzzyQuery builds its Automaton up-front (Alan Woodward,
>> Mike Drob)
>>
>> Solr:
>>
>> "New Features" that maybe should be "Improvements":
>>  * SOLR-13892: New "top-level" docValues join implementation (Jason
>> Gerlowski, Joel Bernstein)
>>  * SOLR-14242: HdfsDirectory now supports indexing geo-points, ranges or
>> shapes. (Adrien Grand)
>>
>> "Improvements" that maybe should be "Optimizations":
>> * SOLR-13808: filter in BoolQParser and {"bool":{"filter":..}} in Query
>> DSL are cached by default (Mikhail Khludnev)
>>
>> "Improvements" that maybe should be "Other":
>> * SOLR-14114: Add WARN to Solr log that embedded ZK is not supported in
>> production (janhoy)
>>
>> Thoughts?
>>
>> ~ David Smiley
>> Apache Lucene/Solr Search Developer
>> http://www.linkedin.com/in/davidwsmiley
>>
>

-- 
Adrien

Re: CHANGES.txt and issue categorization

2020-03-04 Thread Mikhail Khludnev 
I'm ok with it. Thank you, David. Will you put it somewhere on wiki?

On Mon, Mar 2, 2020 at 10:07 AM David Smiley 
wrote:

> I'd like us to reflect on how we categorize issues in CHANGES.txt.  We
> have these categories:
> (Lucene) 'API Changes', 'New Features', 'Improvements', 'Optimizations',
> 'Bug Fixes', 'Other'
> (Solr) 'New Features', 'Improvements', 'Optimizations', 'Bug Fixes',
> 'Other Changes'
> (I lifted these from dev-tools/scripts/addVersion.py line 215)
>
> In particular, I'm often surprised at how some of us categorize New
> Features or Improvements that should better be categorized as something
> else.  I think the root cause of these problems may be that we don't have
> JIRA categories that directly align.  Furthermore, our dev practices will
> typically result in a CHANGES.txt being added out of band from the
> code-review process, and thus no peer-review on ideal placement.
> Furthermore the message itself is often not code reviewed but should be.
> Perhaps we can simply get in the habit of adding a JIRA comment (or GH code
> review) what we propose the category & issue summary should be.
>
> Here is my attempt at a definition for _some_ of these categories.  I
> don't pretend to think we all agree 100% but it's up for discussion:
> 
> * New Features:  A user-visible new capability.  Usually opt-in.
>
> * Improvements:  A user-visible improvement to an existing capability that
> somehow expands its ability or that which improves the behavior.  Not a
> refactoring, not an optimization.
>
> * Optimizations: Something is now more efficient.  Usually automatic (not
> opt-in).
>
> * Other:  Anything else: Refactorings, tests, build, docs, etc.  And
> adding log statements.
> 
>
> I recommend the following changes to Lucene 8.5:
>
> These are "Improvements" that I think are better categorized as
> "Optimizations"
> * LUCENE-9211: Add compression for Binary doc value fields. (Mark Harwood)
> * LUCENE-4702: Better compression of terms dictionaries. (Adrien Grand)
> * LUCENE-9228: Sort dvUpdates in the term order before applying if they
> all update a
>   single field to the same value. This optimization can reduce the flush
> time by around
>   20% for the docValues update user cases. (Nhat Nguyen, Adrien Grand,
> Simon Willnauer)
> * LUCENE-9245: Reduce AutomatonTermsEnum memory usage. (Bruno Roustant,
> Robert Muir)
> * LUCENE-9237: Faster UniformSplit intersect TermsEnum. (Bruno Roustant)
>
> These "Improvements" I think are better categorized as "Other":
> * LUCENE-9109: Backport some changes from master (except StackWalker) to
> improve
>   TestSecurityManager (Uwe Schindler)
> * LUCENE-9110: Backport refactored stack analysis in tests to use
> generalized
>   LuceneTestCase methods (Uwe Schindler)
> * LUCENE-9141: Simplify LatLonShapeXQuery API by adding a new abstract
> class called LatLonGeometry. Queries are
>   executed with input objects that extend such interface. (Ignacio Vera)
> * LUCENE-9194: Simplify XYShapeXQuery API by adding a new abstract class
> called XYGeometry. Queries are
>   executed with input objects that extend such interface. (Ignacio Vera)
>
> Maybe this "Other" item should be  "Optimization"? (not sure):
> * LUCENE-9068: FuzzyQuery builds its Automaton up-front (Alan Woodward,
> Mike Drob)
>
> Solr:
>
> "New Features" that maybe should be "Improvements":
>  * SOLR-13892: New "top-level" docValues join implementation (Jason
> Gerlowski, Joel Bernstein)
>  * SOLR-14242: HdfsDirectory now supports indexing geo-points, ranges or
> shapes. (Adrien Grand)
>
> "Improvements" that maybe should be "Optimizations":
> * SOLR-13808: filter in BoolQParser and {"bool":{"filter":..}} in Query
> DSL are cached by default (Mikhail Khludnev)
>
> "Improvements" that maybe should be "Other":
> * SOLR-14114: Add WARN to Solr log that embedded ZK is not supported in
> production (janhoy)
>
> Thoughts?
>
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley
>


-- 
Sincerely yours
Mikhail Khludnev

Re: Typo in the documentation of Spell Check

2020-03-04 Thread Carlos .Sponchiado 
Thank you very much Christine.

Em ter., 3 de mar. de 2020 às 18:38, Christine Poerschke (BLOOMBERG/
LONDON)  escreveu:

> Thanks for the detailed report Carlos!
>
> I've just committed a fix for the typo:
>
> https://github.com/apache/lucene-solr/commit/4a0063f04a91c6d68e11252396e8c8d5e722b7b2
>
> https://github.com/apache/lucene-solr/commit/def6816f48598ce8e8757239b98969b5e18b21af
>
> Christine
>
> From: dev@lucene.apache.org At: 02/27/20 15:23:34
> To: jan@cominvent.com
> Cc: dev@lucene.apache.org
> Subject: Re: Typo in the documentation of Spell Check
>
> Hi Jan,
>
> It is exactly this documentation. it says spellcheck.queryAnalyzerField*type,
> *but should be spellcheck.queryAnalyzerField*Type.*
>
> I can share with you where I found the correct use of this parameter here:
>
> https://github.com/apache/lucene-solr/search?l=XML=queryAnalyzerFieldType
>
> All the examples the Type is uppercase and here at line 739 is using
> correct
>
>
> https://github.com/apache/lucene-solr/blob/8cde1277ec7151bd6ab62950ac93cbdd6ff04d9f/solr/core/src/java/org/apache/solr/handler/component/SpellCheckComponent.java
>
> I configured my spellcheck in this way and now it uses my analyser and the
> term of search is only in q parameter and spellcheck.q is empty:
>
> 
>
> text-spellcheck
>
> 
>
> default
>
> spellcheck
>
> solr.DirectSolrSpellChecker
>
> internal
>
> 0.7
>
> 2
>
> 1
>
> 5
>
> 4
>
> 0.01
>
> 
>
> 
>
>
> Initially I was thinking that I should use this parameter inside the
> requestHandler, as a parameter of the search. Then reading the book  Apache
> Solr Enterprise Search Server
> 
>  I
> noticed it.
>
>
>
>
> Em qui., 27 de fev. de 2020 às 14:47, Jan Høydahl 
> escreveu:
>
>> Thanks for reporting bugs.
>>
>> I checked the Reference Guide and the documentation seems correct:
>> https://lucene.apache.org/solr/guide/8_4/spell-checking.html#spell-check-parameters
>> In fact that parameter was only added to the documentation from version
>> 7.3. Please specify exactly which documentation your are looking at.
>>
>> Jan
>>
>> 27. feb. 2020 kl. 15:21 skrev Carlos .Sponchiado :
>>
>> Hello,
>>
>> I'd like sharing an error in the documentation of Solr related to
>> SpellCheck.
>> I was investigating why the parameter spellcheck.queryAnalyzerFieldtype 
>> wasn't
>> working and I saw that type was lowercase in the documentation. The correct
>> should be spellcheck.queryAnalyzerFieldType
>>
>> Hope to be helpful
>>
>> Best Regards
>> Carlos Sponchiado
>>
>>
>>
>
> --
> Abraços
> Carlos Sponchiado
>
> -
> 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



-- 
Abraços
Carlos Sponchiado