Search Track at ApacheCon 2021, Sep 21-23

Hi Everyone, ApacheCon 2021 is scheduled to begin next week. Like last year, the event is 1*00% virtual and free to register*. Also, just like last year, we have a dedicated Search track that has a lot of interesting talks and panel discussion about Apache Lucene and Solr. With 2 full days of ses

Re: New branch and feature freeze for Lucene/Solr 8.10.0

But its irrelevant that is "valid" when virtually no tools match it. In other words, I'd agree with you if the "jar" command had some ability to read these manifests and print stuff to stdout, e.g. if there was ANY interop at all here. But there isn't. So IMO it makes no sense to cause confusion

Re: New branch and feature freeze for Lucene/Solr 8.10.0

>Can we read the manifest properly on the smoke tester side somehow This would be my option #3? These are apparently going to need different solutions for ant and gradle, so we'll handle them separately. Created https://issues.apache.org/jira/browse/LUCENE-10107 for 8.x and https://issues.apach

Re: New branch and feature freeze for Lucene/Solr 8.10.0

This is valid manifest line-breaking though... Can we read the manifest properly on the smoke tester side somehow (for example, run a Java process that reads and extracts the required attribute)? This way we wouldn't care about the implementation details of how manifest wraps the lines (or escapes

Re: New branch and feature freeze for Lucene/Solr 8.10.0

+1 for option #1 Let's control the hash to a reasonable size, so that the version number will "fit" We would hit this same problem with 10.0.0 and then we'd have to revisit it again with 10.10.0, so let's not try to solve it onesy-twosey at this time On Wed, Sep 15, 2021 at 2:46 PM Mike Drob wro

Re: New branch and feature freeze for Lucene/Solr 8.10.0

The benchmark jar has the info we need… sort of. When I built it, it has: Implementation-Version: 8.10.0 75a5061d3715cc5d93c4cbe4f1fa62bf035eea1 1 - mdrob - 2021-09-15 11:40:36 and it’s looking for Implementation-Version: 8.10.0 75a5061d3715cc5d93c4cbe4f1fa62bf035eea11 on one line. Because 8.1

Re: New branch and feature freeze for Lucene/Solr 8.10.0

can someone also please look into that benchmark jar issue? Sent from my iPhone > On Sep 15, 2021, at 9:44 AM, Nhat Nguyen > wrote: > >  > Thanks Mayya and Mike! I will backport it to the 8.10 branch. > >> On Wed, Sep 15, 2021 at 10:12 AM Mike Drob wrote: >> I think since Tim is out on vaca

Re: New branch and feature freeze for Lucene/Solr 8.10.0

Thanks Mayya and Mike! I will backport it to the 8.10 branch. On Wed, Sep 15, 2021 at 10:12 AM Mike Drob wrote: > I think since Tim is out on vacation, it's probably not too late. That > looks like a good fix to have, do we know how long the bug has been present? > > On Wed, Sep 15, 2021 at 7:56

Re: New branch and feature freeze for Lucene/Solr 8.10.0

Hello everyone, We have discovered a bug and fixed a bug in Lucene sort optimization (LUCENE-10106) and would like to merge it to Lucene 8.10 if it is not too late. I apologize for the inconvenience, the bug was discovered just yesterday. On Tue, Sep 14,

Re: Discuss SIP-14 Embedded Zookeeper

> If people are running 100 or 1000 node clusters and use each node as a ZK server, by default, what kind of impact would that have? Bad. Very very bad. The largest ZK quorum I've personally seen is 9, and I've heard rumors of somebody running 15. I think the recommended approach for distributing

Re: New branch and feature freeze for Lucene/Solr 8.10.0

I think since Tim is out on vacation, it's probably not too late. That looks like a good fix to have, do we know how long the bug has been present? On Wed, Sep 15, 2021 at 7:56 AM Mayya Sharipova wrote: > Hello everyone, > We have discovered a bug and fixed a bug in Lucene sort optimization >

Re: Discuss SIP-14 Embedded Zookeeper

If we were to make this work, and support productionized embedded Zookeeper, then it would absolutely be something that we want to support by default in the Solr Operator. I don't think we'd be able to cut the Zookeeper Operator dependency really quickly, because this is going in at the earliest i