Re: [VOTE] Release Lucene/Solr 8.11.2 RC2

[Timothy Potter]

I guess this is a -0 ? test suite failed and I don't have time to
fight with it :-(

   [junit4] Tests with failures [seed: B73581D35178CCBC]:
   [junit4]   - org.apache.solr.cloud.LeaderVoteWaitTimeoutTest.basicTest

On Tue, Jun 14, 2022 at 4:36 AM Jan Høydahl  wrote:
>
> +1 (binding)
>
> SUCCESS! [1:19:45.192785]
>
> Jan
>
> 13. jun. 2022 kl. 21:05 skrev Mike Drob :
>
> Please vote for release candidate 2 for Lucene/Solr 8.11.2
>
> The artifacts can be downloaded from:
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.11.2-RC2-rev17dee71932c683e345508113523e764c3e4c80fa
>
> You can run the smoke tester directly with this command:
>
> python3 -u dev-tools/scripts/smokeTestRelease.py \
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.11.2-RC2-rev17dee71932c683e345508113523e764c3e4c80fa
>
> The vote will be open for at least 72 hours i.e. until 2022-06-16 20:00 UTC
>
> [ ] +1  approve
> [ ] +0  no opinion
> [ ] -1  disapprove (and reason why)
>
> Here is my +1
> 
>
>

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

Re: Bugfix release Lucene/Solr 8.11.2

[Timothy Potter]

Thanks Mike for stepping up to do 8.11.2!

We recently uncovered some unexpected behavior with SQL LIKE queries
and I'd like to get a fix for
https://issues.apache.org/jira/browse/SOLR-16199 into 8.11.2. Will be
working on it today / tomorrow.

Cheers,
Tim

On Sun, May 15, 2022 at 5:49 PM Gus Heck  wrote:
>
> commit and backport of course :)
>
> On Sun, May 15, 2022 at 7:47 PM Gus Heck  wrote:
>>
>>  https://issues.apache.org/jira/browse/SOLR-16194 now has a PR 
>> (https://github.com/apache/solr/pull/864) will commit after review or 3 days 
>> without objections
>>
>> On Fri, May 13, 2022 at 12:19 PM Gus Heck  wrote:
>>>
>>> I think it would be good if we can get 
>>> https://issues.apache.org/jira/browse/SOLR-16194 into 8.11.2 I plan to work 
>>> on it this weekend. I'm hoping it will be a straightforward matter of 
>>> adding a check for existing collections.
>>>
>>> On Fri, May 13, 2022 at 4:21 AM Anshum Gupta  wrote:

 Yes please! I assumed that was already the case as both lists are copied :)

 On Fri, May 13, 2022 at 12:47 AM Uwe Schindler  wrote:
>
> Should we maybe also ask on the Lucene side if any backports to 8.11 
> would be good?
>
>
>
> Uwe
>
>
>
> -
>
> Uwe Schindler
>
> Achterdiek 19, D-28357 Bremen
>
> https://www.thetaphi.de
>
> eMail: u...@thetaphi.de
>
>
>
> From: Anshum Gupta 
> Sent: Friday, May 13, 2022 1:23 AM
> To: d...@solr.apache.org
> Cc: Solr/Lucene Dev 
> Subject: Re: Bugfix release Lucene/Solr 8.11.2
>
>
>
> Thanks for volunteering, Mike!
>
>
>
> I think the commits I was tracking to be in 8x are already there, but 
> I'll confirm this over the weekend and let you know in case I intend to 
> backport anything more.
>
>
>
> On Thu, May 12, 2022 at 4:03 PM Mike Drob  wrote:
>
> To: dev@lucene, dev@solr
>
>
>
> NOTICE:
>
>
> I am planning on preparing a bugfix release from branch branch_8_11 
> (likely mid next week)
>
> Please observe the normal rules for committing to this branch:
>
> * Before committing to the branch, reply to this thread and argue
>   why the fix needs backporting and how long it will take.
>
> ** If you're backporting stuff this week still or over the weekend, then 
> skip
>
> the bit about how long it will take.
> * All issues accepted for backporting should be marked with 8.11.2
>   in JIRA, and issues that should delay the release must be marked as 
> Blocker
> * All patches that are intended for the branch should first be committed
>   to the unstable branch, merged into the stable branch, and then into
>   the current release branch.
> * Only Jira issues with Fix version 8.11.2 and priority "Blocker" will 
> delay
>   a release candidate build.
>
>
>
> Also, please observe that since 9.0 already exists, there cannot be any 
> index format breaking changes. It really should only be bug fixes that 
> have already been verified on the 9x branch.
>
>
>
> Thanks,
>
> Mike
>
>
>
>
> --
>
> Anshum Gupta



 --
 Anshum Gupta
>>>
>>>
>>>
>>> --
>>> http://www.needhamsoftware.com (work)
>>> http://www.the111shift.com (play)
>>
>>
>>
>> --
>> http://www.needhamsoftware.com (work)
>> http://www.the111shift.com (play)
>
>
>
> --
> http://www.needhamsoftware.com (work)
> http://www.the111shift.com (play)

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

Re: [VOTE] Release Lucene/Solr 8.11.1 RC1

[Timothy Potter]

Awesome, thanks Uwe!

On Wed, Dec 15, 2021 at 1:39 PM Uwe Schindler  wrote:
>
> Hi,
>
> I was able to start the solr.cmd and boot up techproducts. I also quickly 
> checked the changed endpoints like "export", "status", "api". Only 
> "autoscaling" showed exceptions about zookeeper, not sure if this should show 
> some help info instead (I ran scripts without any solr node running)..
>
> I haven't any problem with whitespace in my CWD.
>
> Uwe
>
> -
> Uwe Schindler
> Achterdiek 19, D-28357 Bremen
> https://www.thetaphi.de
> eMail: u...@thetaphi.de
>
> > -Original Message-
> > From: Uwe Schindler 
> > Sent: Wednesday, December 15, 2021 9:27 PM
> > To: dev@lucene.apache.org
> > Subject: RE: [VOTE] Release Lucene/Solr 8.11.1 RC1
> >
> > Will do!
> >
> > Uwe
> >
> > -----
> > Uwe Schindler
> > Achterdiek 19, D-28357 Bremen
> > https://www.thetaphi.de
> > eMail: u...@thetaphi.de
> >
> > > -Original Message-
> > > From: Timothy Potter 
> > > Sent: Wednesday, December 15, 2021 9:19 PM
> > > To: lucene dev 
> > > Subject: Re: [VOTE] Release Lucene/Solr 8.11.1 RC1
> > >
> > > Anyone try manually launching the RC on Windows? There's a change to
> > > bin/solr.cmd in this release. I tested before I committed but always
> > > good to re-test with the RC just in case.
> > >
> > > Tim
> > >
> > > On Wed, Dec 15, 2021 at 12:30 PM Dawid Weiss 
> > > wrote:
> > > >
> > > > SUCCESS! [0:56:37.756257]
> > > >
> > > > +1
> > > >
> > > > On Tue, Dec 14, 2021 at 3:36 PM Jan Høydahl 
> > > wrote:
> > > > >
> > > > > Please vote for release candidate 1 for Lucene/Solr 8.11.1
> > > > >
> > > > > The artifacts can be downloaded from:
> > > > > https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.11.1-RC1-
> > > rev0b002b11819df70783e83ef36b42ed1223c14b50
> > > > >
> > > > > You can run the smoke tester directly (from a fresh branch_8_11
> > checkout),
> > > with this command:
> > > > >
> > > > > python3 -u dev-tools/scripts/smokeTestRelease.py \
> > > > > https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.11.1-RC1-
> > > rev0b002b11819df70783e83ef36b42ed1223c14b50
> > > > >
> > > > > The vote will be open for at least 72 hours i.e. until 2021-12-17 
> > > > > 15:00
> > UTC.
> > > > >
> > > > > [ ] +1  approve
> > > > > [ ] +0  no opinion
> > > > > [ ] -1  disapprove (and reason why)
> > > > >
> > > > > Here is my +1
> > > > >
> > > > > SUCCESS! [0:54:56.979538]
> > > > >
> > > > > NOTE: You must run the smoke tester from latest commit on
> > branch_8_11,
> > > since my surname contains a unicode-character, needing a fix in the gpg
> > > command ran by the smoketester.
> > > > > -
> > > > > 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
> >
> >
> > -
> > 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

Re: [VOTE] Release Lucene/Solr 8.11.1 RC1

[Timothy Potter]

Anyone try manually launching the RC on Windows? There's a change to
bin/solr.cmd in this release. I tested before I committed but always
good to re-test with the RC just in case.

Tim

On Wed, Dec 15, 2021 at 12:30 PM Dawid Weiss  wrote:
>
> SUCCESS! [0:56:37.756257]
>
> +1
>
> On Tue, Dec 14, 2021 at 3:36 PM Jan Høydahl  wrote:
> >
> > Please vote for release candidate 1 for Lucene/Solr 8.11.1
> >
> > The artifacts can be downloaded from:
> > https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.11.1-RC1-rev0b002b11819df70783e83ef36b42ed1223c14b50
> >
> > You can run the smoke tester directly (from a fresh branch_8_11 checkout), 
> > with this command:
> >
> > python3 -u dev-tools/scripts/smokeTestRelease.py \
> > https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.11.1-RC1-rev0b002b11819df70783e83ef36b42ed1223c14b50
> >
> > The vote will be open for at least 72 hours i.e. until 2021-12-17 15:00 UTC.
> >
> > [ ] +1  approve
> > [ ] +0  no opinion
> > [ ] -1  disapprove (and reason why)
> >
> > Here is my +1
> >
> > SUCCESS! [0:54:56.979538]
> >
> > NOTE: You must run the smoke tester from latest commit on branch_8_11, 
> > since my surname contains a unicode-character, needing a fix in the gpg 
> > command ran by the smoketester.
> > -
> > 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

Re: [VOTE] Release Lucene/Solr 8.11.1 RC1

[Timothy Potter]

+1 (binding) ~ just ran smoke tester this time

SUCCESS! [1:16:20.247006]

On Tue, Dec 14, 2021 at 7:36 AM Jan Høydahl  wrote:
>
> Please vote for release candidate 1 for Lucene/Solr 8.11.1
>
> The artifacts can be downloaded from:
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.11.1-RC1-rev0b002b11819df70783e83ef36b42ed1223c14b50
>
> You can run the smoke tester directly (from a fresh branch_8_11 checkout), 
> with this command:
>
> python3 -u dev-tools/scripts/smokeTestRelease.py \
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.11.1-RC1-rev0b002b11819df70783e83ef36b42ed1223c14b50
>
> The vote will be open for at least 72 hours i.e. until 2021-12-17 15:00 UTC.
>
> [ ] +1  approve
> [ ] +0  no opinion
> [ ] -1  disapprove (and reason why)
>
> Here is my +1
>
> SUCCESS! [0:54:56.979538]
>
> NOTE: You must run the smoke tester from latest commit on branch_8_11, since 
> my surname contains a unicode-character, needing a fix in the gpg command ran 
> by the smoketester.
> -
> 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: Lucene/Solr 8.11.1 release

[Timothy Potter]

agreed! thanks for stepping up to be the RM Jan ;-)

On Tue, Dec 7, 2021 at 6:05 PM Jan Høydahl  wrote:
>
> Hi,
>
> Solr has 13 bug fixes lined up in branch_8_11 already. Lucene has no changes.
> Now that Lucene 9.0 is out the door (congrats!), let's do the 8.11.1 release.
>
> I volunteer as RM and propose a first RC on Monday 13th. That should allow 
> some time to merge any last bug fixes both for Lucene and Solr.
> Please feel free to backport bug fixes with your own judgement (no new 
> features please). If you are uncertain whether a backport is "safe", please 
> raise a question here.
>
> I'll re-enable Jenkins for branch_8_11 now. Commits that fix or @BadApples 
> unstable tests highly appreciated.
>
> Jan
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org
> For additional commands, e-mail: dev-h...@solr.apache.org
>

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

Re: What should we do of branch_8x?

[Timothy Potter]

A Solr 8.12 with Lucene 8.11? Not sure of the details on that but
sounds like a giant mess waiting to happen (at the very least, would
require a bunch of complicated changes to the release process). We
need to stop adding features to 8x and focus on 9. I can foresee an
8.11.2 with bug fixes only (8.11.1 is already planned to drop
soon'ish). Why would Solr need an 8.12? I suspect it's related to
upgrading plugins, but that's been an open issue for a long while and
seems to keep getting pushed out. We can't just keep planning new
feature releases because of this plugin upgrade problem. If we really
need an 8.12, then we need to see a concrete design on how the upgrade
process will work in an 8.12. Perhaps there's a better approach that
only relies on code changes to the 9x line? Tough to say, we have no
designs or descriptions of the upgrade problem at this point.

As of today, I'd be strongly against a Solr 8.12 release.

Tim

On Sat, Nov 20, 2021 at 8:32 AM Ishan Chattopadhyaya
 wrote:
>
> I think we should keep the door open for a 8.12 release of Solr (based on 
> 8.11 Lucene). This might mean some split in the codebase, and this can either 
> happen in the lucene-solr repo or the solr repo (I'm okay with either).
>
> On Sat, Nov 20, 2021 at 7:59 PM Adrien Grand  wrote:
>>
>> Uwe brought up the question on a the vote thread: we are not going to do a 
>> 8.12 release, so what should we do of branch_8x?

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

Re: [VOTE] Release Lucene/Solr 8.11.0 RC1

[Timothy Potter]

+1 (binding)
SUCCESS! [1:21:09.867850]

+ kicked the tires on the UI locally and deployed to EKS using the
Solr operator!

Cheers,
Tim

On Wed, Nov 10, 2021 at 4:15 AM Jan Høydahl  wrote:
>
> +1
>
> SUCCESS! [1:06:33.517455]
>
> Jan
>
> 9. nov. 2021 kl. 21:50 skrev Adrien Grand :
>
> Please vote for release candidate 1 for Lucene/Solr 8.11.0
>
> The artifacts can be downloaded from:
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.11.0-RC1-reve912fdd5b632267a9088507a2a6bcbc75108f381
>
> You can run the smoke tester directly with this command:
>
> python3 -u dev-tools/scripts/smokeTestRelease.py \
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.11.0-RC1-reve912fdd5b632267a9088507a2a6bcbc75108f381
>
> The vote will be open for at least 72 hours i.e. until 2021-11-12 21:00 UTC.
>
> [ ] +1  approve
> [ ] +0  no opinion
> [ ] -1  disapprove (and reason why)
>
> Here is my +1
>
> --
> Adrien
>
>

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

Re: [VOTE] Release Lucene/Solr 8.11.0 RC1

[Timothy Potter]

totally unofficial, but I posted a Docker image for testing 8.11.0 RC1
on K8s here: thelabdude/apache-solr-dev:8.11.0-rc1

On Tue, Nov 9, 2021 at 1:50 PM Adrien Grand  wrote:
>
> Please vote for release candidate 1 for Lucene/Solr 8.11.0
>
> The artifacts can be downloaded from:
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.11.0-RC1-reve912fdd5b632267a9088507a2a6bcbc75108f381
>
> You can run the smoke tester directly with this command:
>
> python3 -u dev-tools/scripts/smokeTestRelease.py \
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.11.0-RC1-reve912fdd5b632267a9088507a2a6bcbc75108f381
>
> The vote will be open for at least 72 hours i.e. until 2021-11-12 21:00 UTC.
>
> [ ] +1  approve
> [ ] +0  no opinion
> [ ] -1  disapprove (and reason why)
>
> Here is my +1
>
> --
> Adrien

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

Re: Lucene 9.0 release

[Timothy Potter]

Sounds like a good plan Adrien, thanks for nailing down some concrete
milestones and dates :-)

Cheers,
Tim

On Fri, Oct 15, 2021 at 7:04 AM David Smiley  wrote:
>
> +1 Adrien.  Thanks for moving things along.
>
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley
>
>
> On Fri, Oct 15, 2021 at 3:30 AM Adrien Grand  wrote:
>>
>> For visibility, I recently opened a new issue about a case of index 
>> corruption which is a blocker for 9.0. Nhat is looking into it.
>>
>> We've been discussing releasing 9.0 for a long time now and I think that 
>> everybody agrees with moving forward, there's even some good momentum around 
>> making the build and release tooling ready. So I'd like to propose the 
>> following timeline for the 9.0 release to get some feedback:
>>
>> 2021-11-01: Feature freeze:
>>  - branch_9x gets created from main
>>  - branch_8_11 gets created from branch_8x
>> This gives us ~2 weeks to do some last-minute work. The reasoning for doing 
>> 8.11 as well is that we have some enhancements merged to branch_8x that I 
>> suspect some users would like to see released in 8.x. Important note: 8.11 
>> will be the last minor release of major version 8. There might be new patch 
>> releases in the future such as 8.11.1 or 8.11.2, but there won't be a 8.12 
>> or a 8.13.
>>
>> 2021-11-04: First RC for 8.11
>> Since we had 8.10 not long ago, hopefully the release process will go 
>> smoothly.
>>
>> ~2021-11-10: First RC for 9.0
>> The date is indicative, the plan would be to move forward with the first 9.0 
>> RC as soon as the following conditions are met:
>>  - 8.11 is out
>>  - all 9.0 blockers have been addressed
>>
>> Mike, your previous email suggests that you would like someone else to step 
>> up. If that's correct I'm happy to be the release manager for both 8.11 and 
>> 9.0.
>>
>>
>> On Sat, Oct 2, 2021 at 11:54 PM Michael Sokolov  wrote:
>>>
>>> Yes! I'm curious to give it a go, but getting pulled in many different
>>> directions. If nobody else steps up, I will be free to shepherd the
>>> release along in a  couple of weeks, assuming the current firestorm
>>> subsides...
>>>
>>> On Thu, Sep 30, 2021 at 9:54 AM Jan Høydahl  wrote:
>>> >
>>> > +1
>>> >
>>> > Blockers seem to be done with. So I guess we just need an RM to get the 
>>> > ball rolling? :)
>>> >
>>> > I know that the Release Wizard in new Lucene repo needs some updates 
>>> > https://issues.apache.org/jira/browse/LUCENE-9809 - I may help some with 
>>> > that...
>>> >
>>> > Cross-ref other 9.0 release mail-threads:
>>> > - "Now that 8.10 is out ... let's get rolling on 9!" 
>>> > https://lists.apache.org/thread.html/r868028d42a19ae02d5bbe2e3329da26869045002b9bb4760b8056c56%40%3Cdev.lucene.apache.org%3E
>>> > - "9.0 release": 
>>> > https://lists.apache.org/thread.html/r7bef0af668860fdbfedb4b58261efd01d9fb26dc280915284c121065%40%3Cdev.lucene.apache.org%3E
>>> >
>>> > Jan
>>> >
>>> > 17. aug. 2021 kl. 11:13 skrev Adrien Grand :
>>> >
>>> > +1 to your suggestions
>>> >
>>> > I just commented on LUCENE-9959 to suggest reverting since the changes 
>>> > are currently half baked and I don't think that they should block 9.0. 
>>> > There are no other blockers left to my knowledge.
>>> >
>>> > On Sat, Aug 14, 2021 at 6:24 PM Michael Sokolov  
>>> > wrote:
>>> >>
>>> >> It's been two years since our last release, we had lots of +1 when we
>>> >> raised this last December, and IMO we are close to baked at this
>>> >> point.
>>> >>
>>> >> I checked JIRA and found two remaining Blockers
>>> >>
>>> >> 1. https://issues.apache.org/jira/browse/LUCENE-10016
>>> >> VectorReader.search needs rethought, o.a.l.search integration?
>>> >> 2. https://issues.apache.org/jira/browse/LUCENE-8638 Remove deprecated
>>> >> code in main
>>> >>
>>> >> The first one is very close to resolved;
>>> >>
>>> >> On the deprecations, the issue has lingered for 1-1/2 years now, and
>>> >> some progress has been made, but more work remains. Some new
>>> >> deprecations have been added since it was opened too. Maybe we make a
>>> >> concerted effort to clean out as much as we can, and then decide if
>>> >> it's enough? Anyway this seems to be the only outstanding issue, so
>>> >> let's see if we can make progress there
>>> >>
>>> >> Q: any other blockers?
>>> >>
>>> >> -
>>> >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>>> >> For additional commands, e-mail: dev-h...@lucene.apache.org
>>> >>
>>> >
>>> >
>>> > --
>>> > Adrien
>>> >
>>> >
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>>
>>
>>
>> --
>> Adrien

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

Re: 8.10.1 Patch release?

[Timothy Potter]

Ah ok thanks for clarifying Nhat. In light of this, doing an 8.10.1
makes sense to me.

Cheers,
Tim

On Wed, Oct 6, 2021 at 12:57 PM Nhat Nguyen
 wrote:
>
> Hello everyone!
>
> Thank you for discussing this.
>
> There were two bugs during the release of 8.10.0. I considered the first bug 
> wasn't a blocker to respin 8.10.0 RC1 and it made into 8.10.0 RC2. However, 
> Mayya discovered that the second bug had a severe impact on search after 
> requests with sort, and we didn't fully understand its severity until 8.10.0 
> was out.
> Although the bug has been in the previous versions, I am +1 to release 8.10.1 
>  to reduce the impact.
>
> Best Regards,
> Nhat
>
> On Wed, Oct 6, 2021 at 2:36 PM Timothy Potter  wrote:
>>
>> I agree with Mike on this one as well. In addition, I'm surprised
>> nobody asked to halt the RC1 and make RC2 with Nhat's fix while I was
>> doing 8.10. Nhat made it sound like it was not a big deal at the time,
>> but now there's some urgency in releasing it?
>>
>> Tim
>>
>> On Wed, Oct 6, 2021 at 11:15 AM Mike Drob  wrote:
>> >
>> > It feels weird to say that I’m against releases, but generally I feel like 
>> > bug fix releases should be scoped either for a regression discovered in 
>> > that release or for rapid security fixes. Otherwise, what’s the harm in 
>> > waiting for the next release train?
>> >
>> > Obviously any committee is free to create a release candidate on any 
>> > commit, and if there are three PMC members in support then a release can 
>> > happen, but I don’t want to be putting pressure on ourselves where we are 
>> > constantly in the middle of a release cycle.
>> >
>> > Or waiting a month and doing 8.11 seems fine too?
>> >
>> > On Wed, Oct 6, 2021 at 8:17 AM Adrien Grand  wrote:
>> >>
>> >> Mike, it's unclear to me if you are suggesting waiting before doing a 
>> >> 8.10.1 release? On my end I'm good with doing a 8.10.1 release now, we 
>> >> could still do a 8.10.2 release later in case we find new bugs?
>> >>
>> >> On Tue, Oct 5, 2021 at 10:41 PM Mayya Sharipova 
>> >>  wrote:
>> >>>
>> >>> No, the bug is not new and was present in the previous versions as well, 
>> >>> but was discovered quite recently.
>> >>>
>> >>> On Tue, Oct 5, 2021 at 3:54 PM Mike Drob  wrote:
>> >>>>
>> >>>> Is the bug new in 8.10? If it affects older versions as well then I 
>> >>>> feel like 8.10.1 might be less urgent.
>> >>>>
>> >>>> Mike
>> >>>>
>> >>>> On Tue, Oct 5, 2021 at 2:14 PM Adrien Grand  wrote:
>> >>>>>
>> >>>>> +1 to a 8.10.1 patch release
>> >>>>>
>> >>>>> On Tue, Oct 5, 2021 at 2:03 AM Mayya Sharipova 
>> >>>>>  wrote:
>> >>>>>>
>> >>>>>> Thanks for the update, Robert.  Would be nice to have these  bug 
>> >>>>>> fixes as well.
>> >>>>>>
>> >>>>>> On Mon, Oct 4, 2021 at 7:56 PM Robert Muir  wrote:
>> >>>>>>>
>> >>>>>>> FYI Looks like there are already six items currently listed under
>> >>>>>>> "Bugfixes" for 8.11.0, so those could be candidates for the patch
>> >>>>>>> release.
>> >>>>>>>
>> >>>>>>> Bug Fixes
>> >>>>>>> -
>> >>>>>>> * LUCENE-10110: MultiCollector now handles single leaf collector that
>> >>>>>>> wants to skip low-scoring hits
>> >>>>>>> but the combined score mode doesn't allow it. (Jim Ferenczi)
>> >>>>>>> * LUCENE-10111: Missing calculating the bytes used of 
>> >>>>>>> DocsWithFieldSet
>> >>>>>>> in NormValuesWriter.
>> >>>>>>> (Lu Xugang)
>> >>>>>>> * LUCENE-10116: Missing calculating the bytes used of 
>> >>>>>>> DocsWithFieldSet
>> >>>>>>> and currentValues in SortedSetDocValuesWriter.
>> >>>>>>> (Lu Xugang)
>> >>>>>>> * LUCENE-10070 Skip deleted docs when accumulating facet counts for
>> >>>>>>> all docs. (Ankur Goel, Greg Miller)
>> >>>

Re: 8.10.1 Patch release?

[Timothy Potter]

I agree with Mike on this one as well. In addition, I'm surprised
nobody asked to halt the RC1 and make RC2 with Nhat's fix while I was
doing 8.10. Nhat made it sound like it was not a big deal at the time,
but now there's some urgency in releasing it?

Tim

On Wed, Oct 6, 2021 at 11:15 AM Mike Drob  wrote:
>
> It feels weird to say that I’m against releases, but generally I feel like 
> bug fix releases should be scoped either for a regression discovered in that 
> release or for rapid security fixes. Otherwise, what’s the harm in waiting 
> for the next release train?
>
> Obviously any committee is free to create a release candidate on any commit, 
> and if there are three PMC members in support then a release can happen, but 
> I don’t want to be putting pressure on ourselves where we are constantly in 
> the middle of a release cycle.
>
> Or waiting a month and doing 8.11 seems fine too?
>
> On Wed, Oct 6, 2021 at 8:17 AM Adrien Grand  wrote:
>>
>> Mike, it's unclear to me if you are suggesting waiting before doing a 8.10.1 
>> release? On my end I'm good with doing a 8.10.1 release now, we could still 
>> do a 8.10.2 release later in case we find new bugs?
>>
>> On Tue, Oct 5, 2021 at 10:41 PM Mayya Sharipova 
>>  wrote:
>>>
>>> No, the bug is not new and was present in the previous versions as well, 
>>> but was discovered quite recently.
>>>
>>> On Tue, Oct 5, 2021 at 3:54 PM Mike Drob  wrote:

 Is the bug new in 8.10? If it affects older versions as well then I feel 
 like 8.10.1 might be less urgent.

 Mike

 On Tue, Oct 5, 2021 at 2:14 PM Adrien Grand  wrote:
>
> +1 to a 8.10.1 patch release
>
> On Tue, Oct 5, 2021 at 2:03 AM Mayya Sharipova 
>  wrote:
>>
>> Thanks for the update, Robert.  Would be nice to have these  bug fixes 
>> as well.
>>
>> On Mon, Oct 4, 2021 at 7:56 PM Robert Muir  wrote:
>>>
>>> FYI Looks like there are already six items currently listed under
>>> "Bugfixes" for 8.11.0, so those could be candidates for the patch
>>> release.
>>>
>>> Bug Fixes
>>> -
>>> * LUCENE-10110: MultiCollector now handles single leaf collector that
>>> wants to skip low-scoring hits
>>> but the combined score mode doesn't allow it. (Jim Ferenczi)
>>> * LUCENE-10111: Missing calculating the bytes used of DocsWithFieldSet
>>> in NormValuesWriter.
>>> (Lu Xugang)
>>> * LUCENE-10116: Missing calculating the bytes used of DocsWithFieldSet
>>> and currentValues in SortedSetDocValuesWriter.
>>> (Lu Xugang)
>>> * LUCENE-10070 Skip deleted docs when accumulating facet counts for
>>> all docs. (Ankur Goel, Greg Miller)
>>> * LUCENE-10126: Sort optimization with a chunked bulk scorer
>>> can wrongly skip documents (Nhat Nguyen, Mayya Sharipova)
>>> * LUCENE-10134: ConcurrentSortedSetDocValuesFacetCounts shouldn't
>>> share liveDocs Bits across threads.
>>> (Ankur Goel)
>>>
>>> On Mon, Oct 4, 2021 at 7:46 PM Mayya Sharipova  wrote:
>>> >
>>> > Hello everyone!
>>> > Thank you, Timothy, for the recent 8.10 release.
>>> >
>>> > I wonder if we are ok to do a 8.10.1 patch release and do it fairly 
>>> > soon? this week?
>>> > Nhat fixed a bad bug where "sort with after" on a numeric field can 
>>> > incorrectly miss documents. This bug only manifests when sort 
>>> > optimization on numeric fields is explicitly enabled.
>>> >
>>> > Given that we are not sure when the next minor release will be, it 
>>> > would be useful to have a patch release.  If nobody is opposed to it, 
>>> >  I can volunteer to be the Release Manager.
>>> >
>>> > Thanks.
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>>
>
>
> --
> Adrien
>>
>>
>>
>> --
>> Adrien

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

Re: Now that 8.10 is out ... let's get rolling on 9!

[Timothy Potter]

Correction, the PR is https://github.com/apache/lucene/pull/343

On Thu, Sep 30, 2021 at 9:43 AM Timothy Potter  wrote:
>
> I went ahead and added the 8.10 version manually ->
> https://github.com/apache/lucene/pull/342
>
> On Thu, Sep 30, 2021 at 9:25 AM Timothy Potter  wrote:
> >
> > I don't know what creates that 8.10 version constant? I didn't skip
> > any steps afaik except for this
> > https://issues.apache.org/jira/browse/LUCENE-10131 ... could this step
> > failing be the cause of the missing version 8.10?
> >
> > On Thu, Sep 30, 2021 at 5:45 AM Alan Woodward  wrote:
> > >
> > > +1 to start pushing for a 9.0 release.
> > >
> > > There isn’t an 8.10 version constant in the 9.0 branch at the moment - 
> > > are there some release tasks that have been missed?
> > >
> > > > On 29 Sep 2021, at 17:58, Timothy Potter  wrote:
> > > >
> > > > Hi Folks,
> > > >
> > > > Having just finished up the 8.10 release, it feels like this is a good
> > > > time to start pushing harder for a 9.0 release.
> > > >
> > > > There are so many improvements in the 9 (main) branches and
> > > > backporting features to 8x is becoming onerous. I realize Solr needs a
> > > > Lucene 9 release before it can proceed. I'm seeing one open blocker on
> > > > the Lucene side: https://issues.apache.org/jira/browse/LUCENE-8638
> > > >
> > > > Can we at least start to nail down a more concrete timeline on a 9.0 
> > > > release?
> > > >
> > > > Cheers,
> > > > Tim
> > > >
> > > > -
> > > > 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

Re: Now that 8.10 is out ... let's get rolling on 9!

[Timothy Potter]

I went ahead and added the 8.10 version manually ->
https://github.com/apache/lucene/pull/342

On Thu, Sep 30, 2021 at 9:25 AM Timothy Potter  wrote:
>
> I don't know what creates that 8.10 version constant? I didn't skip
> any steps afaik except for this
> https://issues.apache.org/jira/browse/LUCENE-10131 ... could this step
> failing be the cause of the missing version 8.10?
>
> On Thu, Sep 30, 2021 at 5:45 AM Alan Woodward  wrote:
> >
> > +1 to start pushing for a 9.0 release.
> >
> > There isn’t an 8.10 version constant in the 9.0 branch at the moment - are 
> > there some release tasks that have been missed?
> >
> > > On 29 Sep 2021, at 17:58, Timothy Potter  wrote:
> > >
> > > Hi Folks,
> > >
> > > Having just finished up the 8.10 release, it feels like this is a good
> > > time to start pushing harder for a 9.0 release.
> > >
> > > There are so many improvements in the 9 (main) branches and
> > > backporting features to 8x is becoming onerous. I realize Solr needs a
> > > Lucene 9 release before it can proceed. I'm seeing one open blocker on
> > > the Lucene side: https://issues.apache.org/jira/browse/LUCENE-8638
> > >
> > > Can we at least start to nail down a more concrete timeline on a 9.0 
> > > release?
> > >
> > > Cheers,
> > > Tim
> > >
> > > -
> > > 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

Re: Now that 8.10 is out ... let's get rolling on 9!

[Timothy Potter]

I don't know what creates that 8.10 version constant? I didn't skip
any steps afaik except for this
https://issues.apache.org/jira/browse/LUCENE-10131 ... could this step
failing be the cause of the missing version 8.10?

On Thu, Sep 30, 2021 at 5:45 AM Alan Woodward  wrote:
>
> +1 to start pushing for a 9.0 release.
>
> There isn’t an 8.10 version constant in the 9.0 branch at the moment - are 
> there some release tasks that have been missed?
>
> > On 29 Sep 2021, at 17:58, Timothy Potter  wrote:
> >
> > Hi Folks,
> >
> > Having just finished up the 8.10 release, it feels like this is a good
> > time to start pushing harder for a 9.0 release.
> >
> > There are so many improvements in the 9 (main) branches and
> > backporting features to 8x is becoming onerous. I realize Solr needs a
> > Lucene 9 release before it can proceed. I'm seeing one open blocker on
> > the Lucene side: https://issues.apache.org/jira/browse/LUCENE-8638
> >
> > Can we at least start to nail down a more concrete timeline on a 9.0 
> > release?
> >
> > Cheers,
> > Tim
> >
> > -
> > 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

Now that 8.10 is out ... let's get rolling on 9!

[Timothy Potter]

Hi Folks,

Having just finished up the 8.10 release, it feels like this is a good
time to start pushing harder for a 9.0 release.

There are so many improvements in the 9 (main) branches and
backporting features to 8x is becoming onerous. I realize Solr needs a
Lucene 9 release before it can proceed. I'm seeing one open blocker on
the Lucene side: https://issues.apache.org/jira/browse/LUCENE-8638

Can we at least start to nail down a more concrete timeline on a 9.0 release?

Cheers,
Tim

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

[ANNOUNCE] Apache Lucene 8.10.0 released

[Timothy Potter]

The Lucene PMC is pleased to announce the release of Apache Lucene 8.10.0.

Apache Lucene is a high-performance, full-featured text search engine
library written entirely in Java. It is a technology suitable for
nearly any application that requires full-text search, especially
cross-platform.

This release contains numerous bug fixes, optimizations, and
improvements, some of which are highlighted below. The release is
available for immediate download at:

  

### Lucene 8.10.0 Release Highlights:

 New features
- Multi-valued fields are now supported in numeric range facet counting
- Added new analyzer for Telugu
- Near-real-time readers opened from an IndexCommit can now sort their leaves
- SimpleText codec now implements skipping for its postings lists

 Optimizations
- Performance improvements for faceting, including a new protected API
to control which fields are counted for drill-down during drill
sideways, and optimized drill sideways iterating
- RegexpQuery's detection of adversarial (ReDoS) regular expressions
is improved, catching exotic cases that it missed before, and throwing
TooComplexToDeterminizeException
- Speedup for computing the leading prefix and trailing suffix from an
Automaton, and for managing powersets during determinize
- Speedups for stored fields retrieval with the default codec (BEST_SPEED)
- IndexWriter uses less RAM when buffering documents, especially in
the case of many unique fields
- forceMerge will now merge any number of segments at once, making it
much faster in many cases
- Compression improvements for docvalues storage

... plus a number of exciting bug fixes!

Please read CHANGES.txt for a full list of new features and changes:

  

Note: The Apache Software Foundation uses an extensive mirroring network for
distributing releases. It is possible that the mirror you are using may not have
replicated the release yet. If that is the case, please try another mirror.
This also applies to Maven access.

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

[RESULT] [VOTE] Release Lucene/Solr 8.10.0 RC1

[Timothy Potter]

It's been >72h since the vote was initiated and the result is:

+1  7  (6 binding)
 0  0
-1  0

This vote has PASSED

-- Forwarded message -
From: Houston Putman 
Date: Sat, Sep 25, 2021 at 9:50 AM
Subject: Re: [VOTE] Release Lucene/Solr 8.10.0 RC1
To: Solr/Lucene Dev 


SUCCESS! [1:04:04.335749]

I also ran through some manual testing with the new s3-repository
contrib using your convenience docker image, and it worked as
expected.

+1

On Fri, Sep 24, 2021 at 4:37 AM Namgyu Kim  wrote:
>
> +1 SUCCESS! [1:01:04.224368]
>
> On Thu, Sep 23, 2021 at 12:42 AM Timothy Potter  wrote:
>>
>> Please vote for release candidate 1 for Lucene/Solr 8.10.0
>>
>> The artifacts can be downloaded from:
>> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.10.0-RC1-rev377e7349979f8e418eacf03f1379b3dfacf7cccb
>>
>> You can run the smoke tester directly with this command:
>>
>> python3 -u dev-tools/scripts/smokeTestRelease.py \
>> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.10.0-RC1-rev377e7349979f8e418eacf03f1379b3dfacf7cccb
>>
>> The vote will be open for at least 72 hours i.e. until 2021-09-25 16:00 UTC.
>>
>> [ ] +1  approve
>> [ ] +0  no opinion
>> [ ] -1  disapprove (and reason why)
>>
>> Here is my +1 (binding) SUCCESS! [0:56:24.357153]
>>
>>
>> Lastly, for those interested in kicking the tires on Solr using
>> Docker, I posted an *unofficial* Docker image built locally from the
>> RC to: thelabdude/apache-solr-dev:8.10.0-rc1
>>
>> We just released v0.4.0 of the Apache Solr Operator, so if you want to
>> try out this RC on Kubernetes, you can use the following YAML config
>> in your SolrCloud CR definition:
>>
>> solrImage:
>>   repository: thelabdude/apache-solr-dev
>>   tag: 8.10.0-rc1
>>
>>
>> Cheers,
>> Tim
>>
>> -
>> 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: [VOTE] Release Lucene/Solr 8.10.0 RC1

[Timothy Potter]

Thank you Cassandra! Any idea why the schema designer images are
showing as broken links?
https://solr.apache.org/guide/8_10/schema-designer.html ... the images
are in images/schema-designer

On Wed, Sep 22, 2021 at 2:31 PM Cassandra Targett  wrote:
>
> I uploaded the 8.10 Ref Guide to https://solr.apache.org/guide/8_10/ in DRAFT 
> while we’re voting on the release.
>
> I accidentally first uploaded a version of the Ref Guide built on `main` 
> branch back in March (a leftover from before the project split that didn’t 
> get caught with `ant clean`). I’m confident I cleaned it up but please let me 
> know if you see something that shouldn’t be there.
> On Sep 22, 2021, 1:24 PM -0500, Jan Høydahl , wrote:
>
> +1
>
> SUCCESS! [1:09:04.477915]
>
> Just ran smoke tester.
>
> Jan
>
> 22. sep. 2021 kl. 17:41 skrev Timothy Potter :
>
> Please vote for release candidate 1 for Lucene/Solr 8.10.0
>
> The artifacts can be downloaded from:
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.10.0-RC1-rev377e7349979f8e418eacf03f1379b3dfacf7cccb
>
> You can run the smoke tester directly with this command:
>
> python3 -u dev-tools/scripts/smokeTestRelease.py \
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.10.0-RC1-rev377e7349979f8e418eacf03f1379b3dfacf7cccb
>
> The vote will be open for at least 72 hours i.e. until 2021-09-25 16:00 UTC.
>
> [ ] +1 approve
> [ ] +0 no opinion
> [ ] -1 disapprove (and reason why)
>
> Here is my +1 (binding) SUCCESS! [0:56:24.357153]
>
>
> Lastly, for those interested in kicking the tires on Solr using
> Docker, I posted an *unofficial* Docker image built locally from the
> RC to: thelabdude/apache-solr-dev:8.10.0-rc1
>
> We just released v0.4.0 of the Apache Solr Operator, so if you want to
> try out this RC on Kubernetes, you can use the following YAML config
> in your SolrCloud CR definition:
>
> solrImage:
> repository: thelabdude/apache-solr-dev
> tag: 8.10.0-rc1
>
>
> Cheers,
> Tim
>
> -
> 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

[VOTE] Release Lucene/Solr 8.10.0 RC1

[Timothy Potter]

Please vote for release candidate 1 for Lucene/Solr 8.10.0

The artifacts can be downloaded from:
https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.10.0-RC1-rev377e7349979f8e418eacf03f1379b3dfacf7cccb

You can run the smoke tester directly with this command:

python3 -u dev-tools/scripts/smokeTestRelease.py \
https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.10.0-RC1-rev377e7349979f8e418eacf03f1379b3dfacf7cccb

The vote will be open for at least 72 hours i.e. until 2021-09-25 16:00 UTC.

[ ] +1  approve
[ ] +0  no opinion
[ ] -1  disapprove (and reason why)

Here is my +1 (binding) SUCCESS! [0:56:24.357153]


Lastly, for those interested in kicking the tires on Solr using
Docker, I posted an *unofficial* Docker image built locally from the
RC to: thelabdude/apache-solr-dev:8.10.0-rc1

We just released v0.4.0 of the Apache Solr Operator, so if you want to
try out this RC on Kubernetes, you can use the following YAML config
in your SolrCloud CR definition:

solrImage:
  repository: thelabdude/apache-solr-dev
  tag: 8.10.0-rc1


Cheers,
Tim

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

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

[Timothy Potter]

Just an update here ... I'm still trying to get an RC built but the
test suite continues to fail with flaky tests, this past run it was:
org.apache.solr.util.TestCircuitBreaker.testResponseWithCBTiming,
which doesn't look like it fails all that much, see:
http://fucit.org/solr-jenkins-reports/history-trend-of-recent-failures.html#series/org.apache.solr.util.TestCircuitBreaker.testResponseWithCBTiming


On Mon, Sep 20, 2021 at 3:14 PM Mike Drob  wrote:
>
> That was a bad backport from main, and I was mainly paying attention to the 
> main jenkins tests. Apologies about that oversight. Please see PR 
> https://github.com/apache/lucene-solr/pull/2578
>
> On Mon, Sep 20, 2021 at 2:21 PM Uwe Schindler  wrote:
>>
>> Hi,
>>
>> This test also fails on Jenkins all the time. In all branches and on all 
>> platforms. All the time, it's definitely a regression.
>>
>> Uwe
>>
>> Am 20. September 2021 19:13:56 UTC schrieb Timothy Potter 
>> :
>>>
>>> Started building the RC1 again today and the smoke tester failed. The
>>> culprit was: org.apache.solr.search.TestFiltering.testRandomFiltering
>>>
>>> Re-ran that test from the RC checkout and it failed again:
>>>
>>>[junit4]   2> 5490 ERROR
>>> (TEST-TestFiltering.testRandomFiltering-seed#[9A85A1D74D8AACF9]) [
>>> ] o.a.s.SolrTestCaseJ4 REQUEST FAILED:
>>> facet.query=*:*={!key%3DmultiSelect+ex%3Dt}*:*={!key%3DfacetQuery+cache%3Dfalse}+val_i:2+val_i:4={!+cost%3D7+tag%3Dt}-_query_:"{!frange+v%3Dval_i+l%3D2+u%3D5}"=true=xml
>>>[junit4]   2> 5491 INFO
>>> (TEST-TestFiltering.testRandomFiltering-seed#[9A85A1D74D8AACF9]) [
>>> ] o.a.s.SolrTestCaseJ4 ###Ending testRandomFiltering
>>>[junit4]   2> NOTE: reproduce with: ant test
>>> -Dtestcase=TestFiltering -Dtests.method=testRandomFiltering
>>> -Dtests.seed=9A85A1D74D8AACF9 -Dtests.slow=true -Dtests.badapples=true
>>> -Dtests.locale=mgh -Dtests.timezone=Iceland -Dtests.asserts=true
>>> -Dtests.file.encoding=US-ASCII
>>>[junit4] FAILURE 0.82s | TestFiltering.testRandomFiltering <<<
>>>[junit4]> Throwable #1: java.lang.AssertionError: should have 
>>> unwrapped
>>>[junit4]> at
>>> __randomizedtesting.SeedInfo.seed([9A85A1D74D8AACF9:85E60212A8ADECF0]:0)
>>>[junit4]> at
>>> org.apache.solr.search.SolrIndexSearcher.getAndCacheDocSet(SolrIndexSearcher.java:862)
>>>[junit4]> at
>>> org.apache.solr.search.SolrIndexSearcher.getDocSet(SolrIndexSearcher.java:824)
>>>[junit4]> at
>>> org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:1367)
>>>[junit4]> at
>>> org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:596)
>>>[junit4]> at
>>> org.apache.solr.handler.component.QueryComponent.doProcessUngroupedSearch(QueryComponent.java:1511)
>>>[junit4]> at
>>> org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:390)
>>>[junit4]> at
>>> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:368)
>>>[junit4]> at
>>> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:216)
>>>[junit4]> at 
>>> org.apache.solr.core.SolrCore.execute(SolrCore.java:2637)
>>>
>>> Looking at the stats for this test, it seems like it started failing
>>> more consistently over the past week or so:
>>> http://fucit.org/solr-jenkins-reports/history-trend-of-recent-failures.html#series/org.apache.solr.search.TestFiltering.testRandomFiltering
>>>
>>> I beasted it and 3/10 failed:
>>>
>>>   [beaster] Tests with failures [seed: A5F8AAEF7994FE2B] (first 3 out of 
>>> 10):
>>>   [beaster]   - org.apache.solr.search.TestFiltering.testRandomFiltering
>>>   [beaster]   - org.apache.solr.search.TestFiltering.testRandomFiltering
>>>   [beaster]   - org.apache.solr.search.TestFiltering.testRandomFiltering
>>>
>>> I could just mark it as a BadApple and move on, but wanted to see if
>>> anyone had any ideas about this test flakiness?
>>>
>>> Cheers,
>>> Tim
>>>
>>> On Fri, Sep 17, 2021 at 4:06 PM Mike Drob  wrote:
>>>>
>>>>
>>>>  Can we move discussion about the implementation to the JIRA issue or the 
>>>> PR?
>>>>
>>>>  I'm not a lawyer, so not playing with the GPL fire is the easiest way for 
>>>> 

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

[Timothy Potter]

t;>>>> >> : >
>>>>> >> : > Jar command doesn't have it, true. But it's fairly trivial to do, 
>>>>> >> even
>>>>> >> : > with an inline snippet like this one?
>>>>> >> : >
>>>>> >> : > public class PrintManifest {
>>>>> >> : >   public static void main(String[] jars) throws IOException {
>>>>> >> : > for (var jar : jars) {
>>>>> >> : >   var manifest = new 
>>>>> >> JarFile(Paths.get(jar).toFile()).getManifest();
>>>>> >> : >   var attrs = manifest.getMainAttributes();
>>>>> >> : >   System.out.println(jar + ": " + 
>>>>> >> attrs.getValue("Implementation-Version"));
>>>>> >> : > }
>>>>> >> : >   }
>>>>> >> : > }
>>>>> >> : >
>>>>> >> : > I have this in my lucene-core-9.0.0-SNAPSHOT.jar:
>>>>> >> : >
>>>>> >> : > Implementation-Version: 9.0.0-SNAPSHOT 
>>>>> >> de45b68c909815ce5ea7b6b9e1a2ce337
>>>>> >> : >  5b6334d [snapshot build, details omitted]
>>>>> >> : >
>>>>> >> : > and running:
>>>>> >> : >
>>>>> >> : > java PrintManifest.java lucene-core-9.0.0-SNAPSHOT.jar
>>>>> >> : >
>>>>> >> : > shows:
>>>>> >> : >
>>>>> >> : > lucene-core-9.0.0-SNAPSHOT.jar: 9.0.0-SNAPSHOT
>>>>> >> : > de45b68c909815ce5ea7b6b9e1a2ce3375b6334d [snapshot build, details
>>>>> >> : > omitted]
>>>>> >> : >
>>>>> >> : > This seems easier to me than trying to remember and keep the 
>>>>> >> length of
>>>>> >> : > that line shorter than an arbitrary limit.
>>>>> >> : >
>>>>> >> : > Dawid
>>>>> >> : >
>>>>> >> : >
>>>>> >> : > On Wed, Sep 15, 2021 at 9:46 PM Robert Muir  
>>>>> >> wrote:
>>>>> >> : > >
>>>>> >> : > > 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 and 
>>>>> >> chaos
>>>>> >> : > > by adding an unnecessarily long git commit hash.
>>>>> >> : > >
>>>>> >> : > > On Wed, Sep 15, 2021 at 3:26 PM Dawid Weiss 
>>>>> >>  wrote:
>>>>> >> : > > >
>>>>> >> : > > >
>>>>> >> : > > > 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 characters).
>>>>> >> : > > >
>>>>> >> : > > > D.
>>>>> >> : > > >
>>>>> >> : > > > On Wed, Sep 15, 2021 at 8:46 PM Mike Drob  
>>>>> >> wrote:
>>>>> >> : > > >>
>>>>> >> : > > >> 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
>>>>> >> : > > >>
>>>>> >> : > > >>
>>>>> >> :

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

[Timothy potter]

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 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 
>>> (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, 2021 at 9:26 PM Timothy Potter  
>>>> wrote:
>>>> Ahem ... unfortunately there will not be an 8.10 RC this week. I'm
>>>> headed out on vacation tomorrow, back at keys on Monday, Sept 20
>>>> unless someone else wants to pick up the RM duties before then?
>>>> 
>>>> After failing the test suite at various places and other weirdness
>>>> like .asc files not getting created, I finally got to the smoke test
>>>> part, which is now failing with:
>>>> 
>>>>   File 
>>>> "/Users/tjp/.lucene-releases/8.10.0/lucene-solr/dev-tools/scripts/smokeTestRelease.py",
>>>> line 176, in checkJARMetaData
>>>> raise RuntimeError('%s is missing "%s" inside its
>>>> META-INF/MANIFEST.MF (wrong git revision?)' % \
>>>> RuntimeError: JAR file
>>>> "/Users/tjp/.lucene-releases/8.10.0/RC1/smoketest/unpack/lucene-8.10.0/benchmark/lucene-benchmark-8.10.0.jar"
>>>> is missing "Implementation-Version: 8.10.0
>>>> ecf5c747e6df418dd05a18af327c20051f0584d7" inside its
>>>> META-INF/MANIFEST.MF (wrong git revision?)
>>>> 
>>>> FWIW, I verified that the other Lucene JAR files have this line in
>>>> them, such as core:
>>>> 
>>>> Manifest-Version: 1.0
>>>> Ant-Version: Apache Ant 1.9.15
>>>> Created-By: 1.8.0_265-b01 (AppleJDK-8.0.265.1.1)
>>>> Extension-Name: org.apache.lucene
>>>> Specification-Title: Lucene Search Engine: core
>>>> Specification-Version: 8.10.0
>>>> Specification-Vendor: The Apache Software Foundation
>>>> Implementation-Title: org.apache.lucene
>>>> Implementation-Version: 8.10.0 ecf5c747e6df418dd05a18af327c20051f0584d
>>>>  7 - tjp - 2021-09-14 19:08:42
>>>> Implementation-Vendor: The Apache Software Foundation
>>>> X-Compile-Source-JDK: 8
>>>> X-Compile-Target-JDK: 8
>>>> Multi-Release: true
>>>> 
>>>> On Tue, Sep 14, 2021 at 1:21 PM Ishan Chattopadhyaya
>>>>  wrote:
>>>> >
>>>> > All the best, this is the worst step.
>>>> >
>>>> > On Tue, 14 Sep, 2021, 10:47 pm Timothy Potter,  
>>>> > wrote:
>>>> >>
>>>> >> Building RC1 now ... stay tuned.
>>>> >>
>>>> >> On Thu, Sep 9, 2021 at 2:30 PM Timothy Potter  
>>>> >> wrote:
>>>> >> >
>>>> >> > Thanks for the update Mike!
>>>> >> >
>>>> >> > I'm backporting SOLR-15620 right now and am cooking up a quick PR for
>>>> >> > SOLR-15621, which looks like an easy win for the issue Cassandra
>>>> >> > reported on Slack earlier today.
>>>> >> >
>>>> >> > Cheers,
>>>> >> > Tim
>>>> >> >
>>>> >> > On Thu, Sep 9, 2021 at 11:32 AM Mike Drob  wrote:
>>>> >> > >
>>>> >> > > Hi Tim, I'm still working on SOLR-1, the code and benchmarking
>>>> >> > > both look pretty good, but I've got a few last unit tests that I 
>>>> >> > > need
>>>> >> > > to chase down. Hopefully taken care of by today or tomorrow, I'll be
>>>> >> > > sure to keep you updated though.
>>>> >> > >
>>>> >> > >
>>>> >> > > On Thu, Sep 9, 2021 at 11:39 AM Timothy Potter 
>>>> >> > >  wrote:
>>>> >> > > >
>>>> >> &g

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

[Timothy Potter]

Ahem ... unfortunately there will not be an 8.10 RC this week. I'm
headed out on vacation tomorrow, back at keys on Monday, Sept 20
unless someone else wants to pick up the RM duties before then?

After failing the test suite at various places and other weirdness
like .asc files not getting created, I finally got to the smoke test
part, which is now failing with:

  File 
"/Users/tjp/.lucene-releases/8.10.0/lucene-solr/dev-tools/scripts/smokeTestRelease.py",
line 176, in checkJARMetaData
raise RuntimeError('%s is missing "%s" inside its
META-INF/MANIFEST.MF (wrong git revision?)' % \
RuntimeError: JAR file
"/Users/tjp/.lucene-releases/8.10.0/RC1/smoketest/unpack/lucene-8.10.0/benchmark/lucene-benchmark-8.10.0.jar"
is missing "Implementation-Version: 8.10.0
ecf5c747e6df418dd05a18af327c20051f0584d7" inside its
META-INF/MANIFEST.MF (wrong git revision?)

FWIW, I verified that the other Lucene JAR files have this line in
them, such as core:

Manifest-Version: 1.0
Ant-Version: Apache Ant 1.9.15
Created-By: 1.8.0_265-b01 (AppleJDK-8.0.265.1.1)
Extension-Name: org.apache.lucene
Specification-Title: Lucene Search Engine: core
Specification-Version: 8.10.0
Specification-Vendor: The Apache Software Foundation
Implementation-Title: org.apache.lucene
Implementation-Version: 8.10.0 ecf5c747e6df418dd05a18af327c20051f0584d
 7 - tjp - 2021-09-14 19:08:42
Implementation-Vendor: The Apache Software Foundation
X-Compile-Source-JDK: 8
X-Compile-Target-JDK: 8
Multi-Release: true

On Tue, Sep 14, 2021 at 1:21 PM Ishan Chattopadhyaya
 wrote:
>
> All the best, this is the worst step.
>
> On Tue, 14 Sep, 2021, 10:47 pm Timothy Potter,  wrote:
>>
>> Building RC1 now ... stay tuned.
>>
>> On Thu, Sep 9, 2021 at 2:30 PM Timothy Potter  wrote:
>> >
>> > Thanks for the update Mike!
>> >
>> > I'm backporting SOLR-15620 right now and am cooking up a quick PR for
>> > SOLR-15621, which looks like an easy win for the issue Cassandra
>> > reported on Slack earlier today.
>> >
>> > Cheers,
>> > Tim
>> >
>> > On Thu, Sep 9, 2021 at 11:32 AM Mike Drob  wrote:
>> > >
>> > > Hi Tim, I'm still working on SOLR-1, the code and benchmarking
>> > > both look pretty good, but I've got a few last unit tests that I need
>> > > to chase down. Hopefully taken care of by today or tomorrow, I'll be
>> > > sure to keep you updated though.
>> > >
>> > >
>> > > On Thu, Sep 9, 2021 at 11:39 AM Timothy Potter  
>> > > wrote:
>> > > >
>> > > > I found https://issues.apache.org/jira/browse/SOLR-15620 while testing
>> > > > the schema designer. I haven't built the RC yet, so going to see if I
>> > > > can get this in today.
>> > > >
>> > > > On Tue, Sep 7, 2021 at 12:36 PM Timothy Potter  
>> > > > wrote:
>> > > > >
>> > > > > NOTICE:
>> > > > >
>> > > > > Branch branch_8_10 has been cut and versions updated to 8.11 on 
>> > > > > stable branch.
>> > > > >
>> > > > > Please observe the normal rules:
>> > > > >
>> > > > > * No new features may be committed to the branch.
>> > > > >
>> > > > > * Documentation patches, build patches and serious bug fixes may be
>> > > > >   committed to the branch. However, you should submit all patches you
>> > > > >   want to commit to Jira first to give others the chance to review
>> > > > >   and possibly vote against the patch. Keep in mind that it is our
>> > > > >   main intention to keep the branch as stable as possible.
>> > > > >
>> > > > > * All patches that are intended for the branch should first be 
>> > > > > committed
>> > > > >   to the unstable branch, merged into the stable branch, and then 
>> > > > > into
>> > > > >   the current release branch.
>> > > > >
>> > > > > * Normal unstable and stable branch development may continue as 
>> > > > > usual.
>> > > > >   However, if you plan to commit a big change to the unstable branch
>> > > > >   while the branch feature freeze is in effect, think twice: can't 
>> > > > > the
>> > > > >   addition wait a couple more days? Merges of bug fixes into the 
>> > > > > branch
>> > > > >   may become more difficult.
>> > > > >
>> > &

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

[Timothy Potter]

Building RC1 now ... stay tuned.

On Thu, Sep 9, 2021 at 2:30 PM Timothy Potter  wrote:
>
> Thanks for the update Mike!
>
> I'm backporting SOLR-15620 right now and am cooking up a quick PR for
> SOLR-15621, which looks like an easy win for the issue Cassandra
> reported on Slack earlier today.
>
> Cheers,
> Tim
>
> On Thu, Sep 9, 2021 at 11:32 AM Mike Drob  wrote:
> >
> > Hi Tim, I'm still working on SOLR-1, the code and benchmarking
> > both look pretty good, but I've got a few last unit tests that I need
> > to chase down. Hopefully taken care of by today or tomorrow, I'll be
> > sure to keep you updated though.
> >
> >
> > On Thu, Sep 9, 2021 at 11:39 AM Timothy Potter  wrote:
> > >
> > > I found https://issues.apache.org/jira/browse/SOLR-15620 while testing
> > > the schema designer. I haven't built the RC yet, so going to see if I
> > > can get this in today.
> > >
> > > On Tue, Sep 7, 2021 at 12:36 PM Timothy Potter  
> > > wrote:
> > > >
> > > > NOTICE:
> > > >
> > > > Branch branch_8_10 has been cut and versions updated to 8.11 on stable 
> > > > branch.
> > > >
> > > > Please observe the normal rules:
> > > >
> > > > * No new features may be committed to the branch.
> > > >
> > > > * Documentation patches, build patches and serious bug fixes may be
> > > >   committed to the branch. However, you should submit all patches you
> > > >   want to commit to Jira first to give others the chance to review
> > > >   and possibly vote against the patch. Keep in mind that it is our
> > > >   main intention to keep the branch as stable as possible.
> > > >
> > > > * All patches that are intended for the branch should first be committed
> > > >   to the unstable branch, merged into the stable branch, and then into
> > > >   the current release branch.
> > > >
> > > > * Normal unstable and stable branch development may continue as usual.
> > > >   However, if you plan to commit a big change to the unstable branch
> > > >   while the branch feature freeze is in effect, think twice: can't the
> > > >   addition wait a couple more days? Merges of bug fixes into the branch
> > > >   may become more difficult.
> > > >
> > > > * Only Jira issues with Fix version 8.10 and priority "Blocker" will 
> > > > delay
> > > >   a release candidate build.
> > > > 
> > >
> > > -
> > > 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

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

[Timothy Potter]

Thanks for the update Mike!

I'm backporting SOLR-15620 right now and am cooking up a quick PR for
SOLR-15621, which looks like an easy win for the issue Cassandra
reported on Slack earlier today.

Cheers,
Tim

On Thu, Sep 9, 2021 at 11:32 AM Mike Drob  wrote:
>
> Hi Tim, I'm still working on SOLR-1, the code and benchmarking
> both look pretty good, but I've got a few last unit tests that I need
> to chase down. Hopefully taken care of by today or tomorrow, I'll be
> sure to keep you updated though.
>
>
> On Thu, Sep 9, 2021 at 11:39 AM Timothy Potter  wrote:
> >
> > I found https://issues.apache.org/jira/browse/SOLR-15620 while testing
> > the schema designer. I haven't built the RC yet, so going to see if I
> > can get this in today.
> >
> > On Tue, Sep 7, 2021 at 12:36 PM Timothy Potter  
> > wrote:
> > >
> > > NOTICE:
> > >
> > > Branch branch_8_10 has been cut and versions updated to 8.11 on stable 
> > > branch.
> > >
> > > Please observe the normal rules:
> > >
> > > * No new features may be committed to the branch.
> > >
> > > * Documentation patches, build patches and serious bug fixes may be
> > >   committed to the branch. However, you should submit all patches you
> > >   want to commit to Jira first to give others the chance to review
> > >   and possibly vote against the patch. Keep in mind that it is our
> > >   main intention to keep the branch as stable as possible.
> > >
> > > * All patches that are intended for the branch should first be committed
> > >   to the unstable branch, merged into the stable branch, and then into
> > >   the current release branch.
> > >
> > > * Normal unstable and stable branch development may continue as usual.
> > >   However, if you plan to commit a big change to the unstable branch
> > >   while the branch feature freeze is in effect, think twice: can't the
> > >   addition wait a couple more days? Merges of bug fixes into the branch
> > >   may become more difficult.
> > >
> > > * Only Jira issues with Fix version 8.10 and priority "Blocker" will delay
> > >   a release candidate build.
> > > 
> >
> > -
> > 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

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

[Timothy Potter]

I found https://issues.apache.org/jira/browse/SOLR-15620 while testing
the schema designer. I haven't built the RC yet, so going to see if I
can get this in today.

On Tue, Sep 7, 2021 at 12:36 PM Timothy Potter  wrote:
>
> NOTICE:
>
> Branch branch_8_10 has been cut and versions updated to 8.11 on stable branch.
>
> Please observe the normal rules:
>
> * No new features may be committed to the branch.
>
> * Documentation patches, build patches and serious bug fixes may be
>   committed to the branch. However, you should submit all patches you
>   want to commit to Jira first to give others the chance to review
>   and possibly vote against the patch. Keep in mind that it is our
>   main intention to keep the branch as stable as possible.
>
> * All patches that are intended for the branch should first be committed
>   to the unstable branch, merged into the stable branch, and then into
>   the current release branch.
>
> * Normal unstable and stable branch development may continue as usual.
>   However, if you plan to commit a big change to the unstable branch
>   while the branch feature freeze is in effect, think twice: can't the
>   addition wait a couple more days? Merges of bug fixes into the branch
>   may become more difficult.
>
> * Only Jira issues with Fix version 8.10 and priority "Blocker" will delay
>   a release candidate build.
> 

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

New branch and feature freeze for Lucene/Solr 8.10.0

[Timothy Potter]

NOTICE:

Branch branch_8_10 has been cut and versions updated to 8.11 on stable branch.

Please observe the normal rules:

* No new features may be committed to the branch.

* Documentation patches, build patches and serious bug fixes may be
  committed to the branch. However, you should submit all patches you
  want to commit to Jira first to give others the chance to review
  and possibly vote against the patch. Keep in mind that it is our
  main intention to keep the branch as stable as possible.

* All patches that are intended for the branch should first be committed
  to the unstable branch, merged into the stable branch, and then into
  the current release branch.

* Normal unstable and stable branch development may continue as usual.
  However, if you plan to commit a big change to the unstable branch
  while the branch feature freeze is in effect, think twice: can't the
  addition wait a couple more days? Merges of bug fixes into the branch
  may become more difficult.

* Only Jira issues with Fix version 8.10 and priority "Blocker" will delay
  a release candidate build.


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

Re: 8.10 release soon?

[Timothy Potter]

That's the process I've been following, so not sure what your point is
David? The release branch didn't get cut last week because there were
a number of JIRAs marked as blockers for 8.10 and we needed clarity
about how to move forward from the committers involved with those
tickets. Also, I don't see the point in requiring an extra backport
even if trivial if we know some features are coming in soon. From
where I sit, any code change that hits 8.x should be releasable
immediately or it shouldn't be committed.

Tim

On Tue, Sep 7, 2021 at 9:31 AM David Smiley  wrote:
>
> The release branch separate from cutting the RC used to be quite normal; not 
> exceptional.  We should continue the practice for release stability.  It also 
> gives clarity for those of us like me that have something ready-ish to merge 
> on which 8x version it should go into.
>
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley
>
>
> On Tue, Sep 7, 2021 at 10:26 AM Timothy Potter  wrote:
>>
>> Thanks for the heads up on LUCENE-10088 Mike. I'd still like to cut
>> the release branch today, but won't start the RC until I get word back
>> from you on that issue. I know this adds another backport for you but
>> I can do that once it lands on 8x.
>>
>> On Tue, Sep 7, 2021 at 7:18 AM Michael McCandless
>>  wrote:
>> >
>> > Hi Timothy,
>> >
>> > Heads up: I'm currently digging on this issue (LUCENE-10088: "too many 
>> > open files" in two failed builds, one in main, one in 8.x), and I'm 
>> > worried that maybe the root cause was backported to 8.x, i.e. maybe we 
>> > have a new file handle leak.
>> >
>> > If so, this might be a blocker for 8.10.0 release.
>> >
>> > I'll try to make progress today on getting to the root cause.
>> >
>> > Mike McCandless
>> >
>> > http://blog.mikemccandless.com
>> >
>> >
>> > On Thu, Sep 2, 2021 at 1:43 PM Timothy Potter  wrote:
>> >>
>> >> Thanks for the feedback.
>> >>
>> >> My plan right now is to cut the release branch for 8.10 on *Tuesday,
>> >> Sept. 7* (Monday is a US holiday).  Hopefully this gives enough time
>> >> to get the remaining issues addressed.
>> >>
>> >> After the release branch is cut, there should be some discussion on
>> >> any new changes coming into that branch before RC1 comes out (I
>> >> usually give a day or two after creating the release branch before
>> >> creating RC1)
>> >>
>> >> May I please ask for some help with the Lucene 8.10 release notes?
>> >> I'll do the notes for Solr. Please add the notes here:
>> >> https://cwiki.apache.org/confluence/display/LUCENE/ReleaseNote8_10
>> >>
>> >> Cheers,
>> >> Tim
>> >>
>> >> On Thu, Sep 2, 2021 at 11:15 AM Nicholas Knize  wrote:
>> >> >
>> >> > +1 to cutting the 8.10 branch and getting the release moving. Will be 
>> >> > good to get the #9981 patch out there. Tests seem happy for a while. 
>> >> > Thanks for chasing these blockers.
>> >> >
>> >> > Nicholas Knize, Ph.D., GISP
>> >> > Principal Engineer - Search  |  Amazon
>> >> > Apache Lucene PMC Member and Committer
>> >> > nkn...@apache.org
>> >> >
>> >> >
>> >> > On Sat, Aug 28, 2021 at 11:18 AM Michael McCandless 
>> >> >  wrote:
>> >> >>
>> >> >> Yeah +1!  Lucene's first "non floating point" compliant release in a 
>> >> >> long time?
>> >> >>
>> >> >> Mike
>> >> >>
>> >> >> On Thu, Aug 26, 2021 at 4:09 AM Adrien Grand  wrote:
>> >> >>>
>> >> >>> +1 to a 8.10 release and cutting a branch next week
>> >> >>>
>> >> >>> On Tue, Aug 24, 2021 at 8:02 PM Timothy Potter  
>> >> >>> wrote:
>> >> >>>>
>> >> >>>> Hi folks,
>> >> >>>>
>> >> >>>> Looks like we have a number of nice enhancements and bug fixes in
>> >> >>>> Lucene and Solr for 8.10.
>> >> >>>>
>> >> >>>> https://github.com/apache/lucene-solr/blob/branch_8x/lucene/CHANGES.txt
>> >> >>>> https://github.com/apache/lucene-solr/blob/branch_8x/solr/CHANGES.txt
>> >> >&

Re: 8.10 release soon?

[Timothy Potter]

Thanks for the heads up on LUCENE-10088 Mike. I'd still like to cut
the release branch today, but won't start the RC until I get word back
from you on that issue. I know this adds another backport for you but
I can do that once it lands on 8x.

On Tue, Sep 7, 2021 at 7:18 AM Michael McCandless
 wrote:
>
> Hi Timothy,
>
> Heads up: I'm currently digging on this issue (LUCENE-10088: "too many open 
> files" in two failed builds, one in main, one in 8.x), and I'm worried that 
> maybe the root cause was backported to 8.x, i.e. maybe we have a new file 
> handle leak.
>
> If so, this might be a blocker for 8.10.0 release.
>
> I'll try to make progress today on getting to the root cause.
>
> Mike McCandless
>
> http://blog.mikemccandless.com
>
>
> On Thu, Sep 2, 2021 at 1:43 PM Timothy Potter  wrote:
>>
>> Thanks for the feedback.
>>
>> My plan right now is to cut the release branch for 8.10 on *Tuesday,
>> Sept. 7* (Monday is a US holiday).  Hopefully this gives enough time
>> to get the remaining issues addressed.
>>
>> After the release branch is cut, there should be some discussion on
>> any new changes coming into that branch before RC1 comes out (I
>> usually give a day or two after creating the release branch before
>> creating RC1)
>>
>> May I please ask for some help with the Lucene 8.10 release notes?
>> I'll do the notes for Solr. Please add the notes here:
>> https://cwiki.apache.org/confluence/display/LUCENE/ReleaseNote8_10
>>
>> Cheers,
>> Tim
>>
>> On Thu, Sep 2, 2021 at 11:15 AM Nicholas Knize  wrote:
>> >
>> > +1 to cutting the 8.10 branch and getting the release moving. Will be good 
>> > to get the #9981 patch out there. Tests seem happy for a while. Thanks for 
>> > chasing these blockers.
>> >
>> > Nicholas Knize, Ph.D., GISP
>> > Principal Engineer - Search  |  Amazon
>> > Apache Lucene PMC Member and Committer
>> > nkn...@apache.org
>> >
>> >
>> > On Sat, Aug 28, 2021 at 11:18 AM Michael McCandless 
>> >  wrote:
>> >>
>> >> Yeah +1!  Lucene's first "non floating point" compliant release in a long 
>> >> time?
>> >>
>> >> Mike
>> >>
>> >> On Thu, Aug 26, 2021 at 4:09 AM Adrien Grand  wrote:
>> >>>
>> >>> +1 to a 8.10 release and cutting a branch next week
>> >>>
>> >>> On Tue, Aug 24, 2021 at 8:02 PM Timothy Potter  
>> >>> wrote:
>> >>>>
>> >>>> Hi folks,
>> >>>>
>> >>>> Looks like we have a number of nice enhancements and bug fixes in
>> >>>> Lucene and Solr for 8.10.
>> >>>>
>> >>>> https://github.com/apache/lucene-solr/blob/branch_8x/lucene/CHANGES.txt
>> >>>> https://github.com/apache/lucene-solr/blob/branch_8x/solr/CHANGES.txt
>> >>>>
>> >>>> However, there are a few open blockers marked for Solr 8.10, see:
>> >>>> https://issues.apache.org/jira/browse/SOLR-15596?filter=12350839
>> >>>>
>> >>>> The blockers (SOLR-15596, SOLR-15412, SOLR-14593) are not assigned to
>> >>>> anyone. Is anyone looking at these? If not, do they need to block the
>> >>>> 8.10 release?
>> >>>>
>> >>>> I propose we should cut the release branch next week but that
>> >>>> obviously depends on our decision around these open blockers.
>> >>>>
>> >>>> Cheers,
>> >>>> Timothy Potter
>> >>>>
>> >>>> PS ~ I volunteer to be the Release Manager ;-)
>> >>>>
>> >>>> -
>> >>>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> >>>> For additional commands, e-mail: dev-h...@lucene.apache.org
>> >>>>
>> >>>
>> >>>
>> >>> --
>> >>> Adrien
>> >>
>> >> --
>> >> Mike McCandless
>> >>
>> >> http://blog.mikemccandless.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: 8.10 release soon?

[Timothy Potter]

Thanks for the feedback.

My plan right now is to cut the release branch for 8.10 on *Tuesday,
Sept. 7* (Monday is a US holiday).  Hopefully this gives enough time
to get the remaining issues addressed.

After the release branch is cut, there should be some discussion on
any new changes coming into that branch before RC1 comes out (I
usually give a day or two after creating the release branch before
creating RC1)

May I please ask for some help with the Lucene 8.10 release notes?
I'll do the notes for Solr. Please add the notes here:
https://cwiki.apache.org/confluence/display/LUCENE/ReleaseNote8_10

Cheers,
Tim

On Thu, Sep 2, 2021 at 11:15 AM Nicholas Knize  wrote:
>
> +1 to cutting the 8.10 branch and getting the release moving. Will be good to 
> get the #9981 patch out there. Tests seem happy for a while. Thanks for 
> chasing these blockers.
>
> Nicholas Knize, Ph.D., GISP
> Principal Engineer - Search  |  Amazon
> Apache Lucene PMC Member and Committer
> nkn...@apache.org
>
>
> On Sat, Aug 28, 2021 at 11:18 AM Michael McCandless 
>  wrote:
>>
>> Yeah +1!  Lucene's first "non floating point" compliant release in a long 
>> time?
>>
>> Mike
>>
>> On Thu, Aug 26, 2021 at 4:09 AM Adrien Grand  wrote:
>>>
>>> +1 to a 8.10 release and cutting a branch next week
>>>
>>> On Tue, Aug 24, 2021 at 8:02 PM Timothy Potter  wrote:
>>>>
>>>> Hi folks,
>>>>
>>>> Looks like we have a number of nice enhancements and bug fixes in
>>>> Lucene and Solr for 8.10.
>>>>
>>>> https://github.com/apache/lucene-solr/blob/branch_8x/lucene/CHANGES.txt
>>>> https://github.com/apache/lucene-solr/blob/branch_8x/solr/CHANGES.txt
>>>>
>>>> However, there are a few open blockers marked for Solr 8.10, see:
>>>> https://issues.apache.org/jira/browse/SOLR-15596?filter=12350839
>>>>
>>>> The blockers (SOLR-15596, SOLR-15412, SOLR-14593) are not assigned to
>>>> anyone. Is anyone looking at these? If not, do they need to block the
>>>> 8.10 release?
>>>>
>>>> I propose we should cut the release branch next week but that
>>>> obviously depends on our decision around these open blockers.
>>>>
>>>> Cheers,
>>>> Timothy Potter
>>>>
>>>> PS ~ I volunteer to be the Release Manager ;-)
>>>>
>>>> -
>>>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>>>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>>>
>>>
>>>
>>> --
>>> Adrien
>>
>> --
>> Mike McCandless
>>
>> http://blog.mikemccandless.com

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

8.10 release soon?

[Timothy Potter]

Hi folks,

Looks like we have a number of nice enhancements and bug fixes in
Lucene and Solr for 8.10.

https://github.com/apache/lucene-solr/blob/branch_8x/lucene/CHANGES.txt
https://github.com/apache/lucene-solr/blob/branch_8x/solr/CHANGES.txt

However, there are a few open blockers marked for Solr 8.10, see:
https://issues.apache.org/jira/browse/SOLR-15596?filter=12350839

The blockers (SOLR-15596, SOLR-15412, SOLR-14593) are not assigned to
anyone. Is anyone looking at these? If not, do they need to block the
8.10 release?

I propose we should cut the release branch next week but that
obviously depends on our decision around these open blockers.

Cheers,
Timothy Potter

PS ~ I volunteer to be the Release Manager ;-)

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

Re: [VOTE] Release Lucene/Solr 8.9.0 RC1

[Timothy Potter]

+1 (binding)

SUCCESS! [1:09:07.601567]

Also, fired up the bin/solr -e cloud example and ran through the Admin UI

Thanks Mayya!

On Tue, Jun 15, 2021 at 11:48 AM Uwe Schindler  wrote:
>
> Hi again, short update to my previous mail:
>
> New maven metadata artifacts work fine, I was able to build a Solr plugin of 
> a customer after adding 2 repos to its POM. It then downloaded the internet 
> and Solr and plugin built sucessfully (including tests using the solr test 
> framework, indirectly also testing lucene test framework):
>
> [INFO] 
> 
> [INFO] BUILD SUCCESS
> [INFO] 
> 
> [INFO] Total time:  02:27 min
> [INFO] Finished at: 2021-06-15T19:44:09+02:00
> [INFO] 
> 
>
>
> In case you want to try:
>
>   
> 
>   lucene
>   
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.9.0-RC1-rev05c8a6f0163fe4c330e93775e8e91f3ab66a3f80/lucene/maven/
> 
> 
>   solr
>   
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.9.0-RC1-rev05c8a6f0163fe4c330e93775e8e91f3ab66a3f80/solr/maven/
> 
>   
>
> You can also try this out, but be sure to remove the dowloaded artifacts from 
> your local repository, if we need to respin the release process!
>
> Uwe
>
> -
> Uwe Schindler
> Achterdiek 19, D-28357 Bremen
> https://www.thetaphi.de
> eMail: u...@thetaphi.de
>
> > -Original Message-
> > From: Uwe Schindler 
> > Sent: Tuesday, June 15, 2021 7:27 PM
> > To: dev@lucene.apache.org
> > Subject: RE: [VOTE] Release Lucene/Solr 8.9.0 RC1
> >
> > +1
> >
> > SUCCESS! [1:24:00.227990]
> >
> > Policeman Jenkins tested it for me: 
> > https://jenkins.thetaphi.de/job/Lucene-Solr-
> > Release-Tester/36/console
> > I had not much time to do my own checks of targz artifacts, so I trust the
> > technical workflow.
> >
> > I only checked the maven folders and verified that the new POM layout looks
> > fine, but I did not do a test build of a Solr plugin this time (I did this 
> > before
> > committing the change). The release artifacts are a bit complicated to use 
> > as
> > it's 2 repos.
> >
> > Uwe
> >
> > -
> > Uwe Schindler
> > Achterdiek 19, D-28357 Bremen
> > https://www.thetaphi.de
> > eMail: u...@thetaphi.de
> >
> > > -Original Message-
> > > From: Atri Sharma 
> > > Sent: Tuesday, June 15, 2021 5:00 PM
> > > To: Lucene Dev 
> > > Subject: Re: [VOTE] Release Lucene/Solr 8.9.0 RC1
> > >
> > > +1 SUCCESS! [1:32:12.04043]
> > >
> > > On Tue, Jun 15, 2021 at 8:27 PM Adrien Grand  wrote:
> > > >
> > > > +1 SUCCESS! [1:36:12.056443]
> > > >
> > > > On Tue, Jun 15, 2021 at 4:26 PM Mayya Sharipova
> > >  wrote:
> > > >>
> > > >> Thanks Robert for such detailed investigations.
> > > >>
> > > >> Lucene-Solr-SmokeRelease-8.9 also had 2 recent failures. Failures are 
> > > >> not
> > > reproducible on my local machine.
> > > >>
> > > >> build #13:  ant test  -Dtestcase=SolrCloudReportersTest -
> > > Dtests.method=testExplicitConfiguration -Dtests.seed=60FEAB39C2B47705 -
> > > Dtests.multiplier=2 -Dtests.locale=ro-RO 
> > > -Dtests.timezone=Africa/Brazzaville -
> > > Dtests.asserts=true -Dtests.file.encoding=UTF-8
> > > >> build# 12: ant test -Dtestcase=LeaderTragicEventTest -
> > > Dtests.method=testLeaderFailsOver -Dtests.seed=BB301A174F4BDB5 -
> > > Dtests.multiplier=2 -Dtests.locale=sr-Latn-RS 
> > > -Dtests.timezone=Africa/Bissau -
> > > Dtests.asserts=true -Dtests.file.encoding=ISO-8859-1
> > > >>
> > > >> On Sat, Jun 12, 2021 at 5:06 PM Robert Muir  wrote:
> > > >>>
> > > >>> OK I managed to finally get this smoketester to pass on my machine, so
> > > >>> for THIS release I will retract my -1 and change it to a +1.
> > > >>>
> > > >>> I have reset my system configuration back though, so we should really
> > > >>> fix these test problems for the future.
> > > >>>
> > > >>> SUCCESS! [1:08:26.448122]
> > > >>>
> > > >>> There were a few compounding issues, I will break out some issues a
> > > >>> bit later. I don't think they need to be blockers for THIS release,
> > > >>> but let's please fix them! I can help try to dig on each one, but here
> > > >>> are the biggest two problems:
> > > >>>
> > > >>> 1. some solr tests don't obey their sandbox and fail with
> > > >>> tests.workDir (if it is set in the user's build.properties). These
> > > >>> tests try to access wrong parts of the filesystem which can cause
> > > >>> tests to meddle with each other. obeying the test sandbox
> > > >>> (tests.workDir) is important, it is how I prevent these tests from
> > > >>> destroying my SSDs.
> > > >>>
> > > >>> 2. some solr HDFS tests will falsely fail if they "think" disk space
> > > >>> is low (even when it is not running out). They dump megabytes of
> > > >>> output, but this part is the key:
> > > >>>
> > > >>>[junit4]   2> 1000960 WARN  (IPC Server handler 3 

Re: [VOTE] Release Lucene/Solr 8.8.2 RC1

[Timothy Potter]

Looks good!

+1 (binding)

Ran the smoke tester + verified the ACLs on /security.json. Also ran
through a series of indexing / query load tests with the Solr
operator.

Cheers,
Tim

On Wed, Apr 7, 2021 at 9:22 AM Uwe Schindler  wrote:
>
> Hi,
>
>
>
> sorry I haven’t seen your message before (it was not sorted into my Lucene 
> mails).
>
>
>
> I committed a compile-failure fix into branch_8x and branch_8_8 a while ago, 
> which was marked as blocker (Lucene and Solr failed to compile with Java 17 
> because of some Javadoc options leading to failures). See more details here: 
> https://issues.apache.org/jira/browse/LUCENE-9912
>
>
>
> I would not stop the release now, so here’s my +/-0
>
>
>
> But if we respin, please include those 2 commits (disabling javadocs options 
> and fixing the javadocs). If not we have to change the FIX version numbers in 
> JIRA!
>
>
>
> Uwe
>
>
>
> -
>
> Uwe Schindler
>
> Achterdiek 19, D-28357 Bremen
>
> https://www.thetaphi.de
>
> eMail: u...@thetaphi.de
>
>
>
> From: Mike Drob 
> Sent: Wednesday, April 7, 2021 12:45 AM
> To: Solr/Lucene Dev ; Solr Dev 
> Subject: [VOTE] Release Lucene/Solr 8.8.2 RC1
>
>
>
> Please vote for release candidate 1 for Lucene/Solr 8.8.2
>
>
>
> The artifacts can be downloaded from:
>
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.8.2-RC1-reva92a05e195b775b30ca410bc0a26e8e79e7b3bfb
>
>
>
> You can run the smoke tester directly with this command:
>
>
>
> python3 -u dev-tools/scripts/smokeTestRelease.py \
>
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.8.2-RC1-reva92a05e195b775b30ca410bc0a26e8e79e7b3bfb
>
>
>
> The vote will be open until 2021-04-12 00:00 UTC. I will tally votes on 
> Monday morning.
>
>
>
> [ ] +1  approve
>
> [ ] +0  no opinion
>
> [ ] -1  disapprove (and reason why)
>
>
>
> Here is my +1

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

Re: [ANNOUNCE] Apache Solr 8.8.1 released

[Timothy Potter]

Awesome! Thank you David and Tobias ;-)

On Sat, Feb 27, 2021 at 12:21 PM David Smiley  wrote:
>
> The corresponding docker image has been released as well:
> https://hub.docker.com/_/solr
> (credit to Tobias Kässmann for helping)
>
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley
>
>
> On Tue, Feb 23, 2021 at 10:39 AM Timothy Potter 
> wrote:
>
> > The Lucene PMC is pleased to announce the release of Apache Solr 8.8.1.
> >
> >
> > Solr is the popular, blazing fast, open source NoSQL search platform from
> > the Apache Lucene project. Its major features include powerful full-text
> > search, hit highlighting, faceted search, dynamic clustering, database
> > integration, rich document handling, and geospatial search. Solr is highly
> > scalable, providing fault tolerant distributed search and indexing, and
> > powers the search and navigation features of many of the world's largest
> > internet sites.
> >
> >
> > Solr 8.8.1 is available for immediate download at:
> >
> >
> >   <https://lucene.apache.org/solr/downloads.html>
> >
> >
> > ### Solr 8.8.1 Release Highlights:
> >
> >
> > Fix for a SolrJ backwards compatibility issue when upgrading the server to
> > 8.8.0 without upgrading SolrJ to 8.8.0.
> >
> >
> > Please refer to the Upgrade Notes in the Solr Ref Guide for information on
> > upgrading from previous Solr versions:
> >
> >
> >   <https://lucene.apache.org/solr/guide/8_8/solr-upgrade-notes.html>
> >
> >
> > Please read CHANGES.txt for a full list of bugfixes:
> >
> >
> >   <https://lucene.apache.org/solr/8_8_1/changes/Changes.html>
> >
> >
> > Solr 8.8.1 also includes bugfixes in the corresponding Apache Lucene
> > release:
> >
> >
> >   <https://lucene.apache.org/core/8_8_1/changes/Changes.html>
> >
> >
> >
> > Note: The Apache Software Foundation uses an extensive mirroring network
> > for
> >
> > distributing releases. It is possible that the mirror you are using may not
> > have
> >
> > replicated the release yet. If that is the case, please try another mirror.
> >
> > This also applies to Maven access.
> >
> > 
> >

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

Next up ~ Docker image for 8.8.1

[Timothy Potter]

Hi folks,

The 8.8.1 release is out ... we need to get the Docker image up soon
too please. Let me know if you need any help from me on that front.

Thanks.
Tim

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

[ANNOUNCE] Apache Solr 8.8.1 released

[Timothy Potter]

The Lucene PMC is pleased to announce the release of Apache Solr 8.8.1.


Solr is the popular, blazing fast, open source NoSQL search platform from
the Apache Lucene project. Its major features include powerful full-text
search, hit highlighting, faceted search, dynamic clustering, database
integration, rich document handling, and geospatial search. Solr is highly
scalable, providing fault tolerant distributed search and indexing, and
powers the search and navigation features of many of the world's largest
internet sites.


Solr 8.8.1 is available for immediate download at:


  


### Solr 8.8.1 Release Highlights:


Fix for a SolrJ backwards compatibility issue when upgrading the server to
8.8.0 without upgrading SolrJ to 8.8.0.


Please refer to the Upgrade Notes in the Solr Ref Guide for information on
upgrading from previous Solr versions:


  


Please read CHANGES.txt for a full list of bugfixes:


  


Solr 8.8.1 also includes bugfixes in the corresponding Apache Lucene
release:


  



Note: The Apache Software Foundation uses an extensive mirroring network for

distributing releases. It is possible that the mirror you are using may not
have

replicated the release yet. If that is the case, please try another mirror.

This also applies to Maven access.

[ANNOUNCE] Apache Lucene 8.8.1 released

[Timothy Potter]

The Lucene PMC is pleased to announce the release of Apache Lucene 8.8.1.


Apache Lucene is a high-performance, full-featured text search engine
library written entirely in Java. It is a technology suitable for nearly
any application that requires full-text search, especially cross-platform.


This release contains numerous bug fixes, optimizations, and improvements,
some of which are highlighted below. The release is available for immediate
download at:


  


### Lucene 8.8.1 Release Highlights:


No changes from 8.8.0


Please read CHANGES.txt for a full list of changes:


  


Note: The Apache Software Foundation uses an extensive mirroring network for

distributing releases. It is possible that the mirror you are using may not
have

replicated the release yet. If that is the case, please try another mirror.

This also applies to Maven access.

[RESULT] [VOTE] Release Lucene/Solr 8.8.1 RC2

[Timothy Potter]

It's been >72h since the vote was initiated and the result is:

+1  8  (7 binding)
 0  0
-1  0

This vote has PASSED


Thanks to those who tested the RC2!

Cheers,
Tim

PS ~ I have a rather busy weekend with non-work stuff, so I'm not sure
I'll be able to resume the release process until Monday AM US time.
Stay tuned ...

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

Re: [VOTE] Release Lucene/Solr 8.8.1 RC2

[Timothy Potter]

And I continue to struggle with the python3 command:

python3 -u dev-tools/scripts/smokeTestRelease.py \
https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.8.1-RC2-rev64f3b496bfee762a9d2dbff40700f457f4464dfe

On Tue, Feb 16, 2021 at 7:41 PM Timothy Potter  wrote:
>
> Please vote for release candidate 2 for Lucene/Solr 8.8.1
>
> The artifacts can be downloaded from:
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.8.1-RC2-rev64f3b496bfee762a9d2dbff40700f457f4464dfe
>
> You can run the smoke tester directly with this command:
> python3 -u dev-tools/scripts/smokeTestRelease.py
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.8.1-RC2-rev64f3b496bfee762a9d2dbff40700f457f4464dfe
>
> The vote will be open for at least 72 hours i.e. until 2021-02-20 03:00 UTC.
>
> [ ] +1  approve
> [ ] +0  no opinion
> [ ] -1  disapprove (and reason why)
>
> Here is my +1 SUCCESS! [0:50:07.947952]
>
> Also, as with RC1, in addition to the smoke test, I built a Docker
> image from the RC locally and verified:
>
> a. A rolling upgrade of a 3-node 8.7.0 cluster to the 8.8.1 RC
> completes successfully w/o any NPEs or weirdness with leader election
> / recoveries.
> b. The base_url property is stored in replica state after the upgrade
> c. A basic client application built with SolrJ 8.7.0 can load cluster
> state info directly from ZK and query the 8.8.1 RC2 servers.
> d. Same client app built with SolrJ 8.8.0 works as well.
>
> As this bug-fix release is primarily needed to address a SolrJ
> back-compat break (SOLR-15145) and unfortunately our smoke tester
> framework does not test for backcompat of older SolrJ against the RC,
> I ask others to please test rolling upgrades of servers (ideally
> multi-node clusters) running pre-8.8.0 to this RC if possible. Also,
> please try client applications that are using an older SolrJ, esp.
> those that load cluster state directly from ZK.
>
> Best regards,
> Tim

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

[VOTE] Release Lucene/Solr 8.8.1 RC2

[Timothy Potter]

Please vote for release candidate 2 for Lucene/Solr 8.8.1

The artifacts can be downloaded from:
https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.8.1-RC2-rev64f3b496bfee762a9d2dbff40700f457f4464dfe

You can run the smoke tester directly with this command:
python3 -u dev-tools/scripts/smokeTestRelease.py
https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.8.1-RC2-rev64f3b496bfee762a9d2dbff40700f457f4464dfe

The vote will be open for at least 72 hours i.e. until 2021-02-20 03:00 UTC.

[ ] +1  approve
[ ] +0  no opinion
[ ] -1  disapprove (and reason why)

Here is my +1 SUCCESS! [0:50:07.947952]

Also, as with RC1, in addition to the smoke test, I built a Docker
image from the RC locally and verified:

a. A rolling upgrade of a 3-node 8.7.0 cluster to the 8.8.1 RC
completes successfully w/o any NPEs or weirdness with leader election
/ recoveries.
b. The base_url property is stored in replica state after the upgrade
c. A basic client application built with SolrJ 8.7.0 can load cluster
state info directly from ZK and query the 8.8.1 RC2 servers.
d. Same client app built with SolrJ 8.8.0 works as well.

As this bug-fix release is primarily needed to address a SolrJ
back-compat break (SOLR-15145) and unfortunately our smoke tester
framework does not test for backcompat of older SolrJ against the RC,
I ask others to please test rolling upgrades of servers (ideally
multi-node clusters) running pre-8.8.0 to this RC if possible. Also,
please try client applications that are using an older SolrJ, esp.
those that load cluster state directly from ZK.

Best regards,
Tim

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

Re: [VOTE] Release Lucene/Solr 8.8.1 RC1

[Timothy Potter]

I'm going to try to fix SOLR-15135 and then kick-off RC2 later today.

If you're in the middle of the RC1 smoke test, it's still valuable to let
it finish, otherwise, please hold off on testing RC1

Cheers,
Tim

On Tue, Feb 16, 2021 at 10:53 AM Timothy Potter 
wrote:

> Ha! I pulled in Ishan's fixes for 15138 and now AutoscalingHistoryHandlerTest
> behaves the same as in 8.7! Beasted 10 out of 10 passed, so
> no @BadApple'ing needed ;-)
>
> On Tue, Feb 16, 2021 at 10:29 AM Anshum Gupta 
> wrote:
>
>> Yes, doing a single 8.8.2 release that has all the fixes, especially as
>> we have the fix already is much better for the users.
>>
>> Thanks for your patience, Tim :)
>>
>> On Tue, Feb 16, 2021 at 9:05 AM Timothy Potter 
>> wrote:
>>
>>> @Ishan ~  Can you look at the question Mike raised about
>>> https://issues.apache.org/jira/browse/SOLR-15135 please?
>>>
>>> So the AutoscalingHistoryHandlerTest has a number of hard-coded wait
>>> times in it. While I can appreciate the need for waiting to see state
>>> changes occur, tests like this aren't great for CI and RC smoke tests given
>>> the variability of hardware. Case in point, I made this change:
>>>
>>> ```
>>>
>>> *diff --git
>>> a/solr/core/src/test/org/apache/solr/handler/admin/AutoscalingHistoryHandlerTest.java
>>> b/solr/core/src/test/org/apache/solr/handler/admin/AutoscalingHistoryHandlerTest.java*
>>>
>>> *index a9eea7f7ca5..3b2d39c3317 100644*
>>>
>>> *---
>>> a/solr/core/src/test/org/apache/solr/handler/admin/AutoscalingHistoryHandlerTest.java*
>>>
>>> *+++
>>> b/solr/core/src/test/org/apache/solr/handler/admin/AutoscalingHistoryHandlerTest.java*
>>>
>>> @@ -282,7 +282,7 @@ public class AutoscalingHistoryHandlerTest extends
>>> SolrCloudTestCase {
>>>
>>>  boolean await = actionFiredLatch.await(60, TimeUnit.SECONDS);
>>>
>>>  assertTrue("action did not execute", await);
>>>
>>>
>>>
>>> -await = listenerFiredLatch.await(60, TimeUnit.SECONDS);
>>>
>>> +await = listenerFiredLatch.await(120, TimeUnit.SECONDS);
>>>
>>>  assertTrue("listener did not execute", await);
>>>
>>>
>>>
>>>  waitForRecovery(COLL_NAME);
>>> ```
>>>
>>> And of course, beasting passes 5 out of 5; it fails pretty consistently
>>> on the first run w/o this change. So I vote we @BadApple this test for
>>> 8.8.1 and move forward with RC2 now that Ishan's changes are in. Moreover,
>>> since we removed auto-scaling from master, holding up a critical bug fix
>>> for a test that fails intermittently b/c of timing seems imprudent. I'm
>>> also biased in that I want to get the fix for 15145 out ASAP ;-)
>>>
>>> On Tue, Feb 16, 2021 at 9:08 AM Ishan Chattopadhyaya <
>>> ichattopadhy...@gmail.com> wrote:
>>>
>>>> Sounds good, Tim. I've ported the fix to the release branch. Just ran
>>>> the tests to make sure it works fine.
>>>> Thanks for the extra work you'll have to do (RC2) in order to save me
>>>> future work (8.8.2). Really owe you one!
>>>>
>>>> > Are there other fixes you're aware of that are slated for 8.8.2 @Ishan
>>>> Chattopadhyaya ?
>>>> I am not aware of anything else.
>>>>
>>>> On Tue, Feb 16, 2021 at 9:19 PM Timothy Potter 
>>>> wrote:
>>>>
>>>>> I'm beasting AutoscalingHistoryHandlerTest locally now, I haven't seen
>>>>> that one fail on my side yet.
>>>>>
>>>>> As far as respin 8.8.1 RC, it's not a problem for me and I prefer that
>>>>> to doing an 8.8.2 soon after 8.8.1 comes out. Are there other fixes you're
>>>>> aware of that are slated for 8.8.2 @Ishan Chattopadhyaya
>>>>> ? In other words, if the fix for 15138 is
>>>>> all that will be in 8.8.2, let's just include it in 8.8.1 and hopefully we
>>>>> won't need an 8.8.2 ;-)
>>>>>
>>>>> Tim
>>>>>
>>>>> On Tue, Feb 16, 2021 at 7:01 AM Michael Sokolov 
>>>>> wrote:
>>>>>
>>>>>> Hmm, I got a failure on
>>>>>>
>>>>>> org.apache.solr.handler.admin.AutoscalingHistoryHandlerTest.testHistory,
>>>>>> but it did not reproduce (tried twice). Would that possibly also be
>>>>>> addressed by tho

Re: [VOTE] Release Lucene/Solr 8.8.1 RC1

[Timothy Potter]

Ha! I pulled in Ishan's fixes for 15138 and now AutoscalingHistoryHandlerTest
behaves the same as in 8.7! Beasted 10 out of 10 passed, so
no @BadApple'ing needed ;-)

On Tue, Feb 16, 2021 at 10:29 AM Anshum Gupta 
wrote:

> Yes, doing a single 8.8.2 release that has all the fixes, especially as we
> have the fix already is much better for the users.
>
> Thanks for your patience, Tim :)
>
> On Tue, Feb 16, 2021 at 9:05 AM Timothy Potter 
> wrote:
>
>> @Ishan ~  Can you look at the question Mike raised about
>> https://issues.apache.org/jira/browse/SOLR-15135 please?
>>
>> So the AutoscalingHistoryHandlerTest has a number of hard-coded wait
>> times in it. While I can appreciate the need for waiting to see state
>> changes occur, tests like this aren't great for CI and RC smoke tests given
>> the variability of hardware. Case in point, I made this change:
>>
>> ```
>>
>> *diff --git
>> a/solr/core/src/test/org/apache/solr/handler/admin/AutoscalingHistoryHandlerTest.java
>> b/solr/core/src/test/org/apache/solr/handler/admin/AutoscalingHistoryHandlerTest.java*
>>
>> *index a9eea7f7ca5..3b2d39c3317 100644*
>>
>> *---
>> a/solr/core/src/test/org/apache/solr/handler/admin/AutoscalingHistoryHandlerTest.java*
>>
>> *+++
>> b/solr/core/src/test/org/apache/solr/handler/admin/AutoscalingHistoryHandlerTest.java*
>>
>> @@ -282,7 +282,7 @@ public class AutoscalingHistoryHandlerTest extends
>> SolrCloudTestCase {
>>
>>  boolean await = actionFiredLatch.await(60, TimeUnit.SECONDS);
>>
>>  assertTrue("action did not execute", await);
>>
>>
>>
>> -await = listenerFiredLatch.await(60, TimeUnit.SECONDS);
>>
>> +await = listenerFiredLatch.await(120, TimeUnit.SECONDS);
>>
>>  assertTrue("listener did not execute", await);
>>
>>
>>
>>  waitForRecovery(COLL_NAME);
>> ```
>>
>> And of course, beasting passes 5 out of 5; it fails pretty consistently
>> on the first run w/o this change. So I vote we @BadApple this test for
>> 8.8.1 and move forward with RC2 now that Ishan's changes are in. Moreover,
>> since we removed auto-scaling from master, holding up a critical bug fix
>> for a test that fails intermittently b/c of timing seems imprudent. I'm
>> also biased in that I want to get the fix for 15145 out ASAP ;-)
>>
>> On Tue, Feb 16, 2021 at 9:08 AM Ishan Chattopadhyaya <
>> ichattopadhy...@gmail.com> wrote:
>>
>>> Sounds good, Tim. I've ported the fix to the release branch. Just ran
>>> the tests to make sure it works fine.
>>> Thanks for the extra work you'll have to do (RC2) in order to save me
>>> future work (8.8.2). Really owe you one!
>>>
>>> > Are there other fixes you're aware of that are slated for 8.8.2 @Ishan
>>> Chattopadhyaya ?
>>> I am not aware of anything else.
>>>
>>> On Tue, Feb 16, 2021 at 9:19 PM Timothy Potter 
>>> wrote:
>>>
>>>> I'm beasting AutoscalingHistoryHandlerTest locally now, I haven't seen
>>>> that one fail on my side yet.
>>>>
>>>> As far as respin 8.8.1 RC, it's not a problem for me and I prefer that
>>>> to doing an 8.8.2 soon after 8.8.1 comes out. Are there other fixes you're
>>>> aware of that are slated for 8.8.2 @Ishan Chattopadhyaya
>>>> ? In other words, if the fix for 15138 is
>>>> all that will be in 8.8.2, let's just include it in 8.8.1 and hopefully we
>>>> won't need an 8.8.2 ;-)
>>>>
>>>> Tim
>>>>
>>>> On Tue, Feb 16, 2021 at 7:01 AM Michael Sokolov 
>>>> wrote:
>>>>
>>>>> Hmm, I got a failure on
>>>>>
>>>>> org.apache.solr.handler.admin.AutoscalingHistoryHandlerTest.testHistory,
>>>>> but it did not reproduce (tried twice). Would that possibly also be
>>>>> addressed by those fixes?
>>>>>
>>>>> On Tue, Feb 16, 2021 at 7:38 AM Ishan Chattopadhyaya
>>>>>  wrote:
>>>>> >
>>>>> > > The failure seems to be because of a timeout during collection
>>>>> > > creation
>>>>> >
>>>>> > Thanks for digging in. Seems like that is the exact class of fix
>>>>> that we did for SOLR-15138 and are planning for 8.8.2. Shall we backport
>>>>> that fix to the release branch now (for RC2 or 8.8.2)?
>>>>> >
>>>>> > > My h/w is really fast

Re: [VOTE] Release Lucene/Solr 8.8.1 RC1

[Timothy Potter]

@Ishan ~  Can you look at the question Mike raised about
https://issues.apache.org/jira/browse/SOLR-15135 please?

So the AutoscalingHistoryHandlerTest has a number of hard-coded wait times
in it. While I can appreciate the need for waiting to see state changes
occur, tests like this aren't great for CI and RC smoke tests given the
variability of hardware. Case in point, I made this change:

```

*diff --git
a/solr/core/src/test/org/apache/solr/handler/admin/AutoscalingHistoryHandlerTest.java
b/solr/core/src/test/org/apache/solr/handler/admin/AutoscalingHistoryHandlerTest.java*

*index a9eea7f7ca5..3b2d39c3317 100644*

*---
a/solr/core/src/test/org/apache/solr/handler/admin/AutoscalingHistoryHandlerTest.java*

*+++
b/solr/core/src/test/org/apache/solr/handler/admin/AutoscalingHistoryHandlerTest.java*

@@ -282,7 +282,7 @@ public class AutoscalingHistoryHandlerTest extends
SolrCloudTestCase {

 boolean await = actionFiredLatch.await(60, TimeUnit.SECONDS);

 assertTrue("action did not execute", await);



-await = listenerFiredLatch.await(60, TimeUnit.SECONDS);

+await = listenerFiredLatch.await(120, TimeUnit.SECONDS);

 assertTrue("listener did not execute", await);



 waitForRecovery(COLL_NAME);
```

And of course, beasting passes 5 out of 5; it fails pretty consistently on
the first run w/o this change. So I vote we @BadApple this test for 8.8.1
and move forward with RC2 now that Ishan's changes are in. Moreover, since
we removed auto-scaling from master, holding up a critical bug fix for a
test that fails intermittently b/c of timing seems imprudent. I'm also
biased in that I want to get the fix for 15145 out ASAP ;-)

On Tue, Feb 16, 2021 at 9:08 AM Ishan Chattopadhyaya <
ichattopadhy...@gmail.com> wrote:

> Sounds good, Tim. I've ported the fix to the release branch. Just ran the
> tests to make sure it works fine.
> Thanks for the extra work you'll have to do (RC2) in order to save me
> future work (8.8.2). Really owe you one!
>
> > Are there other fixes you're aware of that are slated for 8.8.2 @Ishan
> Chattopadhyaya ?
> I am not aware of anything else.
>
> On Tue, Feb 16, 2021 at 9:19 PM Timothy Potter 
> wrote:
>
>> I'm beasting AutoscalingHistoryHandlerTest locally now, I haven't seen
>> that one fail on my side yet.
>>
>> As far as respin 8.8.1 RC, it's not a problem for me and I prefer that to
>> doing an 8.8.2 soon after 8.8.1 comes out. Are there other fixes you're
>> aware of that are slated for 8.8.2 @Ishan Chattopadhyaya
>> ? In other words, if the fix for 15138 is all
>> that will be in 8.8.2, let's just include it in 8.8.1 and hopefully we
>> won't need an 8.8.2 ;-)
>>
>> Tim
>>
>> On Tue, Feb 16, 2021 at 7:01 AM Michael Sokolov 
>> wrote:
>>
>>> Hmm, I got a failure on
>>> org.apache.solr.handler.admin.AutoscalingHistoryHandlerTest.testHistory,
>>> but it did not reproduce (tried twice). Would that possibly also be
>>> addressed by those fixes?
>>>
>>> On Tue, Feb 16, 2021 at 7:38 AM Ishan Chattopadhyaya
>>>  wrote:
>>> >
>>> > > The failure seems to be because of a timeout during collection
>>> > > creation
>>> >
>>> > Thanks for digging in. Seems like that is the exact class of fix that
>>> we did for SOLR-15138 and are planning for 8.8.2. Shall we backport that
>>> fix to the release branch now (for RC2 or 8.8.2)?
>>> >
>>> > > My h/w is really fast and beefy and may be that's why it doesn't get
>>> reproduced.
>>> > Same here, Ryzen 9 5950X (fastest mainstream CPU out there).
>>> >
>>> > On Tue, Feb 16, 2021 at 5:36 PM Michael McCandless <
>>> luc...@mikemccandless.com> wrote:
>>> >>
>>> >> Curious, the smoke tester passed for me on the first try:
>>> >>
>>> >> SUCCESS! [0:44:29.979512]
>>> >>
>>> >>
>>> >> Mike McCandless
>>> >>
>>> >> http://blog.mikemccandless.com
>>> >>
>>> >>
>>> >> On Sun, Feb 14, 2021 at 11:26 AM Timothy Potter <
>>> thelabd...@apache.org> wrote:
>>> >>>
>>> >>> Please vote for release candidate 1 for Lucene/Solr 8.8.1
>>> >>>
>>> >>>
>>> >>> The artifacts can be downloaded from:
>>> >>>
>>> >>>
>>> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.8.1-RC1-rev6a50a0315ac7e4979abb0b530857c7795bb3b928
>>> >>>
>>> >>>
>>> >>> You can run the smoke tester directly wi

Re: [VOTE] Release Lucene/Solr 8.8.1 RC1

[Timothy Potter]

I'm beasting AutoscalingHistoryHandlerTest locally now, I haven't seen that
one fail on my side yet.

As far as respin 8.8.1 RC, it's not a problem for me and I prefer that to
doing an 8.8.2 soon after 8.8.1 comes out. Are there other fixes you're
aware of that are slated for 8.8.2 @Ishan Chattopadhyaya
? In other words, if the fix for 15138 is all
that will be in 8.8.2, let's just include it in 8.8.1 and hopefully we
won't need an 8.8.2 ;-)

Tim

On Tue, Feb 16, 2021 at 7:01 AM Michael Sokolov  wrote:

> Hmm, I got a failure on
> org.apache.solr.handler.admin.AutoscalingHistoryHandlerTest.testHistory,
> but it did not reproduce (tried twice). Would that possibly also be
> addressed by those fixes?
>
> On Tue, Feb 16, 2021 at 7:38 AM Ishan Chattopadhyaya
>  wrote:
> >
> > > The failure seems to be because of a timeout during collection
> > > creation
> >
> > Thanks for digging in. Seems like that is the exact class of fix that we
> did for SOLR-15138 and are planning for 8.8.2. Shall we backport that fix
> to the release branch now (for RC2 or 8.8.2)?
> >
> > > My h/w is really fast and beefy and may be that's why it doesn't get
> reproduced.
> > Same here, Ryzen 9 5950X (fastest mainstream CPU out there).
> >
> > On Tue, Feb 16, 2021 at 5:36 PM Michael McCandless <
> luc...@mikemccandless.com> wrote:
> >>
> >> Curious, the smoke tester passed for me on the first try:
> >>
> >> SUCCESS! [0:44:29.979512]
> >>
> >>
> >> Mike McCandless
> >>
> >> http://blog.mikemccandless.com
> >>
> >>
> >> On Sun, Feb 14, 2021 at 11:26 AM Timothy Potter 
> wrote:
> >>>
> >>> Please vote for release candidate 1 for Lucene/Solr 8.8.1
> >>>
> >>>
> >>> The artifacts can be downloaded from:
> >>>
> >>>
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.8.1-RC1-rev6a50a0315ac7e4979abb0b530857c7795bb3b928
> >>>
> >>>
> >>> You can run the smoke tester directly with this command:
> >>>
> >>>
> >>> python3 -u dev-tools/scripts/smokeTestRelease.py \
> >>>
> >>>
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.8.1-RC1-rev6a50a0315ac7e4979abb0b530857c7795bb3b928
> >>>
> >>>
> >>> The vote will be open for at least 72 hours i.e. until 2021-02-17
> 17:00 UTC.
> >>>
> >>>
> >>> Here is my +1 ~ SUCCESS! [0:50:06.728441]
> >>>
> >>>
> >>> In addition to the smoke test, I built a Docker image from
> solr-8.8.1.tgz locally and verified:
> >>>
> >>>
> >>> a. A rolling upgrade of a 3-node 8.7.0 cluster to the 8.8.1 RC
> completes successfully w/o any NPEs or weirdness with leader election /
> recoveries.
> >>>
> >>>
> >>> b. The base_url property is stored in replica state after the upgrade
> >>>
> >>>
> >>> c. A basic client application built with SolrJ 8.7.0 can load cluster
> state info directly from ZK and query the 8.8.1 RC1 servers.
> >>>
> >>>
> >>> d. Same client app built with SolrJ 8.8.0 works as well.
> >>>
> >>>
> >>> As this bug-fix release is primarily needed to address a SolrJ
> back-compat break (SOLR-15145) and unfortunately our smoke tester framework
> does not test for backcompat of older SolrJ against the RC, I ask others to
> please test rolling upgrades of servers (ideally multi-node clusters)
> running pre-8.8.0 to this RC if possible. Also, please try client
> applications that are using an older SolrJ, esp. those that load cluster
> state directly from ZK.
> >>>
> >>>
> >>> Best regards,
> >>>
> >>> Tim
> >>>
> >>>
> >>>
> >>>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

Re: [VOTE] Release Lucene/Solr 8.8.1 RC1

[Timothy Potter]

Looks like an extra space got added on the end of the python3 command, try
this one:

python3 -u dev-tools/scripts/smokeTestRelease.py
https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.8.1-RC1-rev6a50a0315ac7e4979abb0b530857c7795bb3b928




On Sun, Feb 14, 2021 at 9:26 AM Timothy Potter 
wrote:

> Please vote for release candidate 1 for Lucene/Solr 8.8.1
>
>
> The artifacts can be downloaded from:
>
>
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.8.1-RC1-rev6a50a0315ac7e4979abb0b530857c7795bb3b928
>
>
> You can run the smoke tester directly with this command:
>
>
> python3 -u dev-tools/scripts/smokeTestRelease.py \
>
>
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.8.1-RC1-rev6a50a0315ac7e4979abb0b530857c7795bb3b928
>
>
> The vote will be open for at least 72 hours i.e. until 2021-02-17 17:00
> UTC.
>
>
> Here is my +1 ~ SUCCESS! [0:50:06.728441]
>
>
> In addition to the smoke test, I built a Docker image from solr-8.8.1.tgz
> locally and verified:
>
>
> a. A rolling upgrade of a 3-node 8.7.0 cluster to the 8.8.1 RC completes
> successfully w/o any NPEs or weirdness with leader election / recoveries.
>
>
> b. The base_url property is stored in replica state after the upgrade
>
>
> c. A basic client application built with SolrJ 8.7.0 can load cluster
> state info directly from ZK and query the 8.8.1 RC1 servers.
>
>
> d. Same client app built with SolrJ 8.8.0 works as well.
>
>
> As this bug-fix release is primarily needed to address a SolrJ back-compat
> break (SOLR-15145) and unfortunately our smoke tester framework does not
> test for backcompat of older SolrJ against the RC, I ask others to please
> test rolling upgrades of servers (ideally multi-node clusters) running 
> pre-8.8.0
> to this RC if possible. Also, please try client applications that are using
> an older SolrJ, esp. those that load cluster state directly from ZK.
>
>
> Best regards,
>
> Tim
>
>
>
>
>

[VOTE] Release Lucene/Solr 8.8.1 RC1

[Timothy Potter]

Please vote for release candidate 1 for Lucene/Solr 8.8.1


The artifacts can be downloaded from:

https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.8.1-RC1-rev6a50a0315ac7e4979abb0b530857c7795bb3b928


You can run the smoke tester directly with this command:


python3 -u dev-tools/scripts/smokeTestRelease.py \

https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.8.1-RC1-rev6a50a0315ac7e4979abb0b530857c7795bb3b928


The vote will be open for at least 72 hours i.e. until 2021-02-17 17:00 UTC.


Here is my +1 ~ SUCCESS! [0:50:06.728441]


In addition to the smoke test, I built a Docker image from solr-8.8.1.tgz
locally and verified:


a. A rolling upgrade of a 3-node 8.7.0 cluster to the 8.8.1 RC completes
successfully w/o any NPEs or weirdness with leader election / recoveries.


b. The base_url property is stored in replica state after the upgrade


c. A basic client application built with SolrJ 8.7.0 can load cluster state
info directly from ZK and query the 8.8.1 RC1 servers.


d. Same client app built with SolrJ 8.8.0 works as well.


As this bug-fix release is primarily needed to address a SolrJ back-compat
break (SOLR-15145) and unfortunately our smoke tester framework does not
test for backcompat of older SolrJ against the RC, I ask others to please
test rolling upgrades of servers (ideally multi-node clusters) running
pre-8.8.0
to this RC if possible. Also, please try client applications that are using
an older SolrJ, esp. those that load cluster state directly from ZK.


Best regards,

Tim

Re: 8.8.1 release soon

[Timothy Potter]

Hi David,

I found another issue related to this base_url issue and leader election,
so I need to respin RC1 anyway. Please go ahead and merge your fix for
LUCENE-9762.

Thanks.
Tim

On Sat, Feb 13, 2021 at 11:10 AM Timothy Potter 
wrote:

> I'm already well into building the RC this morning, so am not going to
> respin for this given how flaky the RC building process seems to be, so
> commit to branch_8x and if we need an RC2, then you can commit to branch_8_8
>
> Tim
>
> On Sat, Feb 13, 2021 at 10:24 AM David Smiley  wrote:
>
>> There's a bug I just fixed:
>> https://issues.apache.org/jira/browse/LUCENE-9762  Kinda rare scenario
>> but a bug nonetheless.  It's unclear to where I should commit this to.
>>  8.8.1 would be nice.
>>
>> ~ David Smiley
>> Apache Lucene/Solr Search Developer
>> http://www.linkedin.com/in/davidwsmiley
>>
>>
>> On Wed, Feb 10, 2021 at 1:11 PM Anshum Gupta 
>> wrote:
>>
>>> Thanks for taking care of this, Tim.
>>>
>>> I've added a note to the 'downloads' page so folks who head there know
>>> about this issue and that a release with the fix is in the works. (thanks
>>> for reviewing that too :) )
>>>
>>> -Anshum
>>>
>>> On Wed, Feb 10, 2021 at 7:37 AM Timothy Potter 
>>> wrote:
>>>
>>>> I was a tad bit ambitious with backporting SOLR-12182 to 8.8.0 and it
>>>> seems we have no automated SolrJ back-compat tests in our RC vetting
>>>> process, so unfortunately older SolrJ clients don't work with Solr 8.8
>>>> server, see SOLR-15145.
>>>>
>>>> I'd like to release 8.8.1 ASAP to address this problem and will be the
>>>> RM.
>>>>
>>>> Let me know if you have any other issues you think need to go into
>>>> 8.8.1, otherwise I'd like to build an RC tomorrow AM US time. It looks like
>>>> there are already a number of updates going in for 8.9 so let's keep the
>>>> updates for 8.8.1 to a minimum please.
>>>>
>>>> Cheers,
>>>> Tim
>>>>
>>>
>>>
>>> --
>>> Anshum Gupta
>>>
>>

Re: 8.8.1 release soon

[Timothy Potter]

I'm already well into building the RC this morning, so am not going to
respin for this given how flaky the RC building process seems to be, so
commit to branch_8x and if we need an RC2, then you can commit to branch_8_8

Tim

On Sat, Feb 13, 2021 at 10:24 AM David Smiley  wrote:

> There's a bug I just fixed:
> https://issues.apache.org/jira/browse/LUCENE-9762  Kinda rare scenario
> but a bug nonetheless.  It's unclear to where I should commit this to.
>  8.8.1 would be nice.
>
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley
>
>
> On Wed, Feb 10, 2021 at 1:11 PM Anshum Gupta 
> wrote:
>
>> Thanks for taking care of this, Tim.
>>
>> I've added a note to the 'downloads' page so folks who head there know
>> about this issue and that a release with the fix is in the works. (thanks
>> for reviewing that too :) )
>>
>> -Anshum
>>
>> On Wed, Feb 10, 2021 at 7:37 AM Timothy Potter 
>> wrote:
>>
>>> I was a tad bit ambitious with backporting SOLR-12182 to 8.8.0 and it
>>> seems we have no automated SolrJ back-compat tests in our RC vetting
>>> process, so unfortunately older SolrJ clients don't work with Solr 8.8
>>> server, see SOLR-15145.
>>>
>>> I'd like to release 8.8.1 ASAP to address this problem and will be the
>>> RM.
>>>
>>> Let me know if you have any other issues you think need to go into
>>> 8.8.1, otherwise I'd like to build an RC tomorrow AM US time. It looks like
>>> there are already a number of updates going in for 8.9 so let's keep the
>>> updates for 8.8.1 to a minimum please.
>>>
>>> Cheers,
>>> Tim
>>>
>>
>>
>> --
>> Anshum Gupta
>>
>

Bugfix release Lucene/Solr 8.8.1

[Timothy Potter]

NOTICE:


I am now preparing for a bugfix release from branch branch_8_8


Please observe the normal rules for committing to this branch:


* Before committing to the branch, reply to this thread and argue

  why the fix needs backporting and how long it will take.


* All issues accepted for backporting should be marked with 8.8.1

  in JIRA, and issues that should delay the release must be marked as
Blocker


* All patches that are intended for the branch should first be committed

  to the unstable branch, merged into the stable branch, and then into

  the current release branch.


* Only Jira issues with Fix version 8.8.1 and priority "Blocker" will delay

  a release candidate build.





Cheers,


Your friendly RM (in this case Tim P.)

Re: 8.8.1 release soon

[Timothy Potter]

Hi Ishan,

Please let me know how SOLR-15138 is looking on Friday and we can make a
decision then. My hope is for 8.8.1 sooner than later, but a couple more
days seems fine too.

Cheers,
Tim

On Wed, Feb 10, 2021 at 8:55 AM Ishan Chattopadhyaya <
ichattopadhy...@gmail.com> wrote:

> I'd like for us to include SOLR-15138 please, but the fix is still under
> review and development. Please let us know if it should be possible for us
> to wait until that one is done (hopefully quickly), otherwise we can
> release it later (if you want to proceed with the release before this is
> ready). Thanks for volunteering!
>
> On Wed, 10 Feb, 2021, 9:07 pm Timothy Potter, 
> wrote:
>
>> I was a tad bit ambitious with backporting SOLR-12182 to 8.8.0 and it
>> seems we have no automated SolrJ back-compat tests in our RC vetting
>> process, so unfortunately older SolrJ clients don't work with Solr 8.8
>> server, see SOLR-15145.
>>
>> I'd like to release 8.8.1 ASAP to address this problem and will be the RM.
>>
>> Let me know if you have any other issues you think need to go into 8.8.1,
>> otherwise I'd like to build an RC tomorrow AM US time. It looks like there
>> are already a number of updates going in for 8.9 so let's keep the updates
>> for 8.8.1 to a minimum please.
>>
>> Cheers,
>> Tim
>>
>

8.8.1 release soon

[Timothy Potter]

I was a tad bit ambitious with backporting SOLR-12182 to 8.8.0 and it seems
we have no automated SolrJ back-compat tests in our RC vetting process, so
unfortunately older SolrJ clients don't work with Solr 8.8 server, see
SOLR-15145.

I'd like to release 8.8.1 ASAP to address this problem and will be the RM.

Let me know if you have any other issues you think need to go into 8.8.1,
otherwise I'd like to build an RC tomorrow AM US time. It looks like there
are already a number of updates going in for 8.9 so let's keep the updates
for 8.8.1 to a minimum please.

Cheers,
Tim

Re: [VOTE] Release Lucene/Solr 8.8.0 RC2

[Timothy Potter]

Thanks Noble!

+1 SUCCESS! [1:24:28.212370] (my internet is super slow today)

Re-ran all the Solr operator tests and verified the Cloud graph UI renders
correctly now.

On Mon, Jan 25, 2021 at 3:22 AM Noble Paul  wrote:

> Please vote for release candidate 2 for Lucene/Solr 8.8.0
>
> The artifacts can be downloaded from:
>
>
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.8.0-RC2-revb10659f0fc18b58b90929cfdadde94544d202c4a/
>
> python3 -u dev-tools/scripts/smokeTestRelease.py \
>
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.8.0-RC2-revb10659f0fc18b58b90929cfdadde94544d202c4a/
>
>
>
> The vote will be open for at least 72 hours
>
> [ ] +1  approve
> [ ] +0  no opinion
> [ ] -1  disapprove (and reason why)
>
> Here is my +1
> --
> -
> Noble Paul
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

Re: [VOTE] Release Lucene/Solr 8.8.0 RC1

[Timothy Potter]

Ah yeah, that was my bad ... missed some code in the backport to 8x. Fix is
in but needs a re-spin :-( Thanks for reporting / verifying Anshum & Mike

Cheers,
Tim

On Thu, Jan 21, 2021 at 3:42 PM Mike Drob  wrote:

> -1
>
> I have been able to reproduce the regression that Anshum found, and would
> like to change my vote accordingly.
>
> On Thu, Jan 21, 2021 at 4:31 PM Anshum Gupta 
> wrote:
>
>> https://issues.apache.org/jira/browse/SOLR-15097
>>
>>
>>
>> On Thu, Jan 21, 2021 at 2:28 PM Anshum Gupta 
>> wrote:
>>
>>> While testing the artifacts some more, I realized that the cluster graph
>>> doesn't show up on the admin UI any more.
>>>
>>> I started the cluster with -e cloud -noprompt, and the getting started
>>> collection was created successfully. The clusterstate, as well as the admin
>>> UI confirm that.
>>>
>>> I also tried creating a collection using the admin API, which was
>>> successful, but the graph didn't reflect that either.
>>>
>>> I've tested this using both Safari and Firefox, and it's clearly not a
>>> browser issue.
>>>
>>> Considering that the users rely on the graph, I think we might need to
>>> fix and respin this.
>>>
>>>
>>> On Tue, Jan 19, 2021 at 8:51 AM Ishan Chattopadhyaya <
>>> ichattopadhy...@gmail.com> wrote:
>>>
 Please vote for release candidate 1 for Lucene/Solr 8.8.0

 The artifacts can be downloaded from:

 https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.8.0-RC1-rev737cb9c49b08f6e3964c1e8a80132da3c764e027

 You can run the smoke tester directly with this command:

 python3 -u dev-tools/scripts/smokeTestRelease.py \

 https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.8.0-RC1-rev737cb9c49b08f6e3964c1e8a80132da3c764e027

 The vote will be open for at least 72 hours i.e. until 2021-01-22 17:00
 UTC.

 [ ] +1  approve
 [ ] +0  no opinion
 [ ] -1  disapprove (and reason why)

 Here is my +1
 

>>>
>>>
>>> --
>>> Anshum Gupta
>>>
>>
>>
>> --
>> Anshum Gupta
>>
>

Re: [VOTE] Release Lucene/Solr 8.8.0 RC1

[Timothy Potter]

+1 (binding)

SUCCESS! [1:07:15.796578]


Also built a *local* Docker image from the RC and tested various features
with the Solr operator on K8s, such as the updates to the Prom exporter &
Grafana dashboard for query performance.


Looks good!

On Tue, Jan 19, 2021 at 12:06 PM Houston Putman 
wrote:

> +1
>
> SUCCESS! [1:01:28.552891]
>
> On Tue, Jan 19, 2021 at 1:53 PM Cassandra Targett 
> wrote:
>
>> I’ve put up the DRAFT version of the Ref Guide for 8.8:
>> https://lucene.apache.org/solr/guide/8_8/.
>>
>> I also created the Jenkins job for building the 8.8 guide which pushes to
>> the Nightlies server in case we have edits between now and release (
>> https://nightlies.apache.org/Lucene/Solr-reference-guide-8.8/).
>>
>> Note branch_8_8 does not (yet) include the new Math Expressions guide
>> being worked on in SOLR-13105. Still hoping that will make it, but thought
>> I’d get this out sooner rather than later just in case.
>> On Jan 19, 2021, 10:51 AM -0600, Ishan Chattopadhyaya <
>> ichattopadhy...@gmail.com>, wrote:
>>
>> Please vote for release candidate 1 for Lucene/Solr 8.8.0
>>
>> The artifacts can be downloaded from:
>>
>> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.8.0-RC1-rev737cb9c49b08f6e3964c1e8a80132da3c764e027
>>
>> You can run the smoke tester directly with this command:
>>
>> python3 -u dev-tools/scripts/smokeTestRelease.py \
>>
>> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.8.0-RC1-rev737cb9c49b08f6e3964c1e8a80132da3c764e027
>>
>> The vote will be open for at least 72 hours i.e. until 2021-01-22 17:00
>> UTC.
>>
>> [ ] +1  approve
>> [ ] +0  no opinion
>> [ ] -1  disapprove (and reason why)
>>
>> Here is my +1
>> 
>>
>>

Re: Solr Docker discussion

[Timothy Potter]

I'm curious about how tags will work when updating the base image for a
released image? The image for a tag should be immutable (IMHO), and I think
people would be surprised if 8.8.0 suddenly changed even if it was for a
good reason such as fixing a CVE in the base image. But based on what Kevin
said, perhaps there's already precedence for this with the official images?

On Fri, Jan 15, 2021 at 1:51 PM Houston Putman 
wrote:

> Thanks for bringing up this issue Kevin.
>
> Periodically re-building docker images is certainly a feature we could
> support, and probably should to automatically keep up with security fixes.
> We could even automate it pretty easily in Jenkins.
>
> We could also build in support in the gradle commands to instead of
> building a TGZ from source, download and verify the "official" TGZ, to
> build the image with. That way release images are always built with the
> same exact binaries. The Dockerfile wouldn't need to change at all between
> local and release, it still merely expects a TGZ to be passed in the
> context; gradle can determine if it needs to be built from scratch or
> downloaded.
>
> This still likely wouldn't be good enough to make the image an "official
> docker image" but it gets us to essentially the same end-state image. The
> only difference is the downloading and verification are happening in gradle
> instead of the Dockerfile.
>
> - Houston
>
> On Fri, Jan 15, 2021 at 2:05 PM Kevin Risden  wrote:
>
>> Currently the solr-docker-image, and a majority of "Docker Official
>>> Images", the officially released Solr binaries are downloaded from mirrors
>>> and validated within the Dockerfiles. This makes it easy to ensure to users
>>> that the 9.0 solr docker image contains the 9.0 solr release. This process
>>> doesn't fit very well with local builds, because there is nowhere to
>>> download local builds from, and validation isn't required.
>>>
>>> *The current opinion in the community is to abandon the "Docker Official
>>> Images" style process of downloading and validating official binaries, and
>>> instead having the release manager use the local-build image creation with
>>> the final release source.* This should result in the same docker image
>>> in the end, however there is no trust built into the docker image itself.
>>> Instead we are likely going to document a way for users to verify the
>>> docker-image contents themselves.
>>>
>>
>> Before we abandon the official process of downloading/validating official
>> binaries, I think there is a good reason to keep the ability to download an
>> "official" Apache Solr release and use it in the "official" Solr
>> convenience Docker image.
>>
>> Docker images are static point in time copies of an OS and all supporting
>> packages (like Java) when built. Periodically Docker images should be
>> rebuilt to pick up the latest security and bug enhancements in the base
>> image. Just like any OS should run `apt upgrade` or `yum update`
>> periodically to ensure it is up to date.
>>
>> My proposal is to periodically rebuild the "official" Solr convenience
>> Docker image based on the "official" Solr release to ensure we keep the
>> Docker images up to date. The idea being that we have a list of "supported"
>> versions of Solr (ie: 8.5, 8.6, 8.7) and periodically (ie: daily, weekly)
>> the Docker images are rebuilt. Once a new release is made (ie: 8.8) it gets
>> added to this rebuilding matrix. This ensures that the "official" Solr
>> convenience Docker image is reasonably up to date with regards to the base
>> image security updates.
>>
>> My understanding (from a few years ago) is that the Docker official
>> images are rebuilt when the base image is updated. This was automatic from
>> what I understand. If we move away from the "Docker official image" way of
>> doing things, we should still ensure that we can provide high quality
>> secure Docker images to the community.
>>
>> We should not need a new Apache Solr release (ie: 8.7.1, 8.8) to update
>> the Docker image to pick up the latest base image changes.
>>
>> It is important to be able to build and test locally with a Docker image
>> that matches what an "official" Docker image is. This should still be a
>> goal, but we should be able to rebuild the Solr docker image without
>> rebuilding all of Solr.
>>
>> PS - I chatted a bit with Houston on Slack about this topic and hopefully
>> captured all the context correctly.
>>
>> Kevin Risden
>>
>>
>> On Fri, Jan 15, 2021 at 12:45 PM Houston Putman 
>> wrote:
>>
>>> There's a few decisions that need to be ironed out around the Solr
>>> docker image before 9.0 is released. This is because the community has
>>> decided that Solr should start releasing it's own docker images starting
>>> with 9.0.
>>>
>>> Below is the current state of the ongoing discussions for the Solr
>>> Docker image. Please feel free to correct me or fill in any information I
>>> may be missing.
>>>
>>> Where does this image live?
>>>
>>> There are two 

Re: 8.8 Release

[Timothy Potter]

Fix is in branch_8x and master now, sorry for the delay ;-)

Cheers,
Tim

On Mon, Jan 11, 2021 at 10:50 AM Ishan Chattopadhyaya <
ichattopadhy...@gmail.com> wrote:

> Thanks Tim!
>
> On Mon, 11 Jan, 2021, 11:00 pm Timothy Potter, 
> wrote:
>
>> 15036 will be in later today, so you can plan to cut this evening US time
>> or tomorrow.
>>
>> Cheers,
>> Tim
>>
>> On Mon, Jan 11, 2021 at 9:54 AM Ishan Chattopadhyaya <
>> ichattopadhy...@gmail.com> wrote:
>>
>>> I think all the issues mentioned above are in the branch, except
>>> SOLR-15036. Tim, I'll cut a branch once that is in, latest by Wednesday AM
>>> (USA time).
>>> Thanks,
>>> Ishan
>>>
>>> On Thu, Jan 7, 2021 at 5:07 AM Timothy Potter 
>>> wrote:
>>>
>>>> Thanks for following up on this Ishan ... I intend to get SOLR-15059
>>>> and -15036 into 8.8 as well. I should have a proper PR up for SOLR-15036 by
>>>> Friday sometime, which seems to align with other's timeframes
>>>>
>>>> Cheers,
>>>> Tim
>>>>
>>>> On Wed, Jan 6, 2021 at 6:54 AM David Smiley  wrote:
>>>>
>>>>> Happy New Year!
>>>>> I would much prefer that ensure 8.8 includes SOLR-14923 (a bad nested
>>>>> docs performance issue)
>>>>>
>>>>> ~ David Smiley
>>>>> Apache Lucene/Solr Search Developer
>>>>> http://www.linkedin.com/in/davidwsmiley
>>>>>
>>>>>
>>>>> On Wed, Jan 6, 2021 at 6:59 AM Ishan Chattopadhyaya <
>>>>> ichattopadhy...@gmail.com> wrote:
>>>>>
>>>>>> Happy New Year!
>>>>>>
>>>>>> I was supposed to start the process tomorrow, but I think we're not
>>>>>> ready yet? I see SOLR-15052 still under review with intention of 
>>>>>> inclusion
>>>>>> into 8.8.
>>>>>> Would it be reasonable to cut the release branch end of this week and
>>>>>> start the RC process around 13th January?
>>>>>> If there are any issues someone would want me to wait on, please let
>>>>>> me know.
>>>>>>
>>>>>> Thanks,
>>>>>> Ishan
>>>>>>
>>>>>> On Fri, Dec 18, 2020 at 6:10 AM Ishan Chattopadhyaya <
>>>>>> ichattopadhy...@gmail.com> wrote:
>>>>>>
>>>>>>> Sure, Houston. I'll wait another week. Have a good new year and
>>>>>>> merry Christmas!
>>>>>>>
>>>>>>> On Fri, 18 Dec, 2020, 5:58 am Timothy Potter, 
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Great point Houston! +1 on waiting until a week into January
>>>>>>>>
>>>>>>>> On Thu, Dec 17, 2020 at 4:46 PM Houston Putman <
>>>>>>>> houstonput...@gmail.com> wrote:
>>>>>>>>
>>>>>>>>> Thanks for volunteering Ishan.
>>>>>>>>>
>>>>>>>>> I think it might be a good idea to wait to cut and release 8.8 at
>>>>>>>>> least a week into January. Many people are going to be away during the
>>>>>>>>> holiday season, and particularly the last week of the year. Pushing 
>>>>>>>>> into
>>>>>>>>> January just gives more people a chance to look at the release and be
>>>>>>>>> involved.
>>>>>>>>>
>>>>>>>>> - Houston
>>>>>>>>>
>>>>>>>>> On Fri, Dec 11, 2020 at 3:26 PM Noble Paul 
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> Thanks Ishan for volunteering
>>>>>>>>>>
>>>>>>>>>> On Fri, Dec 11, 2020 at 5:07 AM Christine Poerschke (BLOOMBERG/
>>>>>>>>>> LONDON)  wrote:
>>>>>>>>>> >
>>>>>>>>>> > With a view towards including it in the release, I'd appreciate
>>>>>>>>>> code review input on
>>>>>>>>>> >
>>>>>>>>>> > https://github.com/apache/lucene-solr/pull/1992 for
>>>>>>>>>> >
>>>>>>>>>> > 

Re: 8.8 Release

[Timothy Potter]

15036 will be in later today, so you can plan to cut this evening US time
or tomorrow.

Cheers,
Tim

On Mon, Jan 11, 2021 at 9:54 AM Ishan Chattopadhyaya <
ichattopadhy...@gmail.com> wrote:

> I think all the issues mentioned above are in the branch, except
> SOLR-15036. Tim, I'll cut a branch once that is in, latest by Wednesday AM
> (USA time).
> Thanks,
> Ishan
>
> On Thu, Jan 7, 2021 at 5:07 AM Timothy Potter 
> wrote:
>
>> Thanks for following up on this Ishan ... I intend to get SOLR-15059 and
>> -15036 into 8.8 as well. I should have a proper PR up for SOLR-15036 by
>> Friday sometime, which seems to align with other's timeframes
>>
>> Cheers,
>> Tim
>>
>> On Wed, Jan 6, 2021 at 6:54 AM David Smiley  wrote:
>>
>>> Happy New Year!
>>> I would much prefer that ensure 8.8 includes SOLR-14923 (a bad nested
>>> docs performance issue)
>>>
>>> ~ David Smiley
>>> Apache Lucene/Solr Search Developer
>>> http://www.linkedin.com/in/davidwsmiley
>>>
>>>
>>> On Wed, Jan 6, 2021 at 6:59 AM Ishan Chattopadhyaya <
>>> ichattopadhy...@gmail.com> wrote:
>>>
>>>> Happy New Year!
>>>>
>>>> I was supposed to start the process tomorrow, but I think we're not
>>>> ready yet? I see SOLR-15052 still under review with intention of inclusion
>>>> into 8.8.
>>>> Would it be reasonable to cut the release branch end of this week and
>>>> start the RC process around 13th January?
>>>> If there are any issues someone would want me to wait on, please let me
>>>> know.
>>>>
>>>> Thanks,
>>>> Ishan
>>>>
>>>> On Fri, Dec 18, 2020 at 6:10 AM Ishan Chattopadhyaya <
>>>> ichattopadhy...@gmail.com> wrote:
>>>>
>>>>> Sure, Houston. I'll wait another week. Have a good new year and merry
>>>>> Christmas!
>>>>>
>>>>> On Fri, 18 Dec, 2020, 5:58 am Timothy Potter, 
>>>>> wrote:
>>>>>
>>>>>> Great point Houston! +1 on waiting until a week into January
>>>>>>
>>>>>> On Thu, Dec 17, 2020 at 4:46 PM Houston Putman <
>>>>>> houstonput...@gmail.com> wrote:
>>>>>>
>>>>>>> Thanks for volunteering Ishan.
>>>>>>>
>>>>>>> I think it might be a good idea to wait to cut and release 8.8 at
>>>>>>> least a week into January. Many people are going to be away during the
>>>>>>> holiday season, and particularly the last week of the year. Pushing into
>>>>>>> January just gives more people a chance to look at the release and be
>>>>>>> involved.
>>>>>>>
>>>>>>> - Houston
>>>>>>>
>>>>>>> On Fri, Dec 11, 2020 at 3:26 PM Noble Paul 
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Thanks Ishan for volunteering
>>>>>>>>
>>>>>>>> On Fri, Dec 11, 2020 at 5:07 AM Christine Poerschke (BLOOMBERG/
>>>>>>>> LONDON)  wrote:
>>>>>>>> >
>>>>>>>> > With a view towards including it in the release, I'd appreciate
>>>>>>>> code review input on
>>>>>>>> >
>>>>>>>> > https://github.com/apache/lucene-solr/pull/1992 for
>>>>>>>> >
>>>>>>>> > https://issues.apache.org/jira/browse/SOLR-14939 (JSON facets:
>>>>>>>> range faceting to support cache=false parameter)
>>>>>>>> >
>>>>>>>> > if anyone has some time next week perhaps?
>>>>>>>> >
>>>>>>>> > Thanks in advance!
>>>>>>>> >
>>>>>>>> > Christine
>>>>>>>> >
>>>>>>>> > From: dev@lucene.apache.org At: 12/10/20 18:01:58
>>>>>>>> > To: dev@lucene.apache.org
>>>>>>>> > Subject: Re: 8.8 Release
>>>>>>>> >
>>>>>>>> > +1
>>>>>>>> >
>>>>>>>> > Joel Bernstein
>>>>>>>> > http://joelsolr.blogspot.com/
>>>>>>>> >
>>>>>>>> >
>>>>>>>> > On Thu, Dec 10, 2020 at 11:23 AM David Smiley 
>>>>>>>> wrote:
>>>>>>>> >>
>>>>>>>> >> Thanks for volunteering!
>>>>>>>> >>
>>>>>>>> >> On Thu, Dec 10, 2020 at 11:11 AM Ishan Chattopadhyaya <
>>>>>>>> ichattopadhy...@gmail.com> wrote:
>>>>>>>> >>>
>>>>>>>> >>> Hi Devs,
>>>>>>>> >>> There are lots of changes accumulated and some underway. I wish
>>>>>>>> to volunteer for a 8.8 release, if there are no objections. I'm 
>>>>>>>> planning to
>>>>>>>> build the RC in three weeks, i.e. 31 December (and cut the branch 
>>>>>>>> about 3-4
>>>>>>>> days before that). Please let me know if someone has any concerns.
>>>>>>>> >>> Thanks and regards,
>>>>>>>> >>> Ishan
>>>>>>>> >>>
>>>>>>>> >> --
>>>>>>>> >> Sent from Gmail Mobile
>>>>>>>> >
>>>>>>>> >
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> -
>>>>>>>> Noble Paul
>>>>>>>>
>>>>>>>>
>>>>>>>> -
>>>>>>>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>>>>>>>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>>>>>>>
>>>>>>>>

Re: Failing gradle precommits

[Timothy Potter]

Same for my PR too ... OOMs about 14 minutes in ...

On Fri, Jan 8, 2021 at 9:45 AM Houston Putman 
wrote:

> Weirdly enough, Github PR precommit actions have started to OOM. Not sure
> if it's a github thing or something that changed on our end...
>
> On Fri, Jan 8, 2021 at 11:37 AM Joel Bernstein  wrote:
>
>> It turned out to be this while I merged branches:
>>
>> warning: inexact rename detection was skipped due to too many files.
>>
>> warning: you may want to set your merge.renamelimit variable to at least
>> 1639 and retry the command.
>>
>> Joel Bernstein
>> http://joelsolr.blogspot.com/
>>
>>
>> On Fri, Jan 8, 2021 at 11:16 AM Joel Bernstein 
>> wrote:
>>
>>> Thanks Eric, I'll do a fresh clone, something must be out of wack with
>>> my local repo.
>>>
>>>
>>> Joel Bernstein
>>> http://joelsolr.blogspot.com/
>>>
>>>
>>> On Fri, Jan 8, 2021 at 10:55 AM Eric Pugh <
>>> ep...@opensourceconnections.com> wrote:
>>>
 It ran for me just fine.   I *think* you may not be up to date, as
 dataimporthandler/ is no longer in master!


 On Jan 8, 2021, at 10:08 AM, Joel Bernstein  wrote:

 I'm getting failing gradle precommits in master:

 *> Task :solr:contrib:validateSourcePatterns* FAILED
 tabs instead spaces:
 /Users/joelbernstein/committer/lucene-solr/solr/contrib/dataimporthandler/build/test-results/test/TEST-org.apache.solr.handler.dataimport.TestDocBuilder.xml
 tabs instead spaces:
 /Users/joelbernstein/committer/lucene-solr/solr/contrib/dataimporthandler/build/test-results/test/TEST-org.apache.solr.handler.dataimport.TestSolrEntityProcessorEndToEnd.xml
 tabs instead spaces:
 /Users/joelbernstein/committer/lucene-solr/solr/contrib/dataimporthandler/build/test-results/test/TEST-org.apache.solr.handler.dataimport.TestErrorHandling.xml
 tabs instead spaces:
 /Users/joelbernstein/committer/lucene-solr/solr/contrib/dataimporthandler/build/test-results/test/TEST-org.apache.solr.handler.dataimport.TestScriptTransformer.xml
 tabs instead spaces:
 /Users/joelbernstein/committer/lucene-solr/solr/contrib/dataimporthandler/build/test-results/test/TEST-org.apache.solr.handler.dataimport.TestSqlEntityProcessor.xml
 tabs instead spaces:
 /Users/joelbernstein/committer/lucene-solr/solr/contrib/dataimporthandler/build/test-results/test/TEST-org.apache.solr.handler.dataimport.TestDocBuilder2.xml
 tabs instead spaces:
 /Users/joelbernstein/committer/lucene-solr/solr/contrib/dataimporthandler/build/test-results/test/TEST-org.apache.solr.handler.dataimport.TestZKPropertiesWriter.xml
 tabs instead spaces:
 /Users/joelbernstein/committer/lucene-solr/solr/contrib/dataimporthandler-extras/build/test-results/test/TEST-org.apache.solr.handler.dataimport.TestTikaEntityProcessor.xml

 FAILURE: Build failed with an exception.

 * Where:
 Script
 '/Users/joelbernstein/committer/lucene-solr/gradle/validation/validate-source-patterns.gradle'
 line: 324

 * What went wrong:
 Execution failed for task ':solr:contrib:validateSourcePatterns'.
 > Found 8 violations in source files (tabs instead spaces).


 Are others seeing this as well? I'm not seeing Jenkins emails about
 this.


 Joel Bernstein
 http://joelsolr.blogspot.com/


 ___
 *Eric Pugh **| *Founder & CEO | OpenSource Connections, LLC | 434.466.1467
 | http://www.opensourceconnections.com | My Free/Busy
 
 Co-Author: Apache Solr Enterprise Search Server, 3rd Ed
 
 This e-mail and all contents, including attachments, is considered to
 be Company Confidential unless explicitly stated otherwise, regardless
 of whether attachments are marked as such.

Re: Failing test on branch_8x: org.apache.solr.rest.schema.TestBulkSchemaAPI.testCopyFieldWithReplace

[Timothy potter]

Awesome! Thanks for fixing that quickly ... and thank you Hossman for spotting 
the discrepancy between Ishan’s result as i was scratching my head on what was 
wrong with my env, I guess I just assume people sync with upstream before 
commenting on test failures ;-)

> On Jan 7, 2021, at 11:44 AM, Munendra S N  wrote:
> 
> 
> Test failure is fixed now 
> https://github.com/apache/lucene-solr/commit/514c4b1e491c1c93b7b928731437dcbe932237f9
> 
> Thanks,
> Munendra S N
> 
> 
> 
>> On Fri, Jan 8, 2021 at 12:00 AM Munendra S N  wrote:
>> I'm looking into this
>> 
>> Regards,
>> Munendra S N
>> 
>> 
>> 
>>> On Thu, Jan 7, 2021 at 11:54 PM Chris Hostetter  
>>> wrote:
>>> 
>>> : WHen I try your exact repro line (along with the method name), I get:
>>> : BUILD FAILED
>>> : /home/ishan/code/lucene-solr/lucene/common-build.xml:1616: Not even a
>>> : single test was executed (a typo in the filter pattern maybe?).
>>> 
>>> your repo is stale Ishan -- it's a test that was committed today...
>>> 
>>> https://issues.apache.org/jira/browse/SOLR-14950
>>> 
>>> 
>>> : On Thu, Jan 7, 2021 at 11:09 PM Timothy Potter 
>>> : wrote:
>>> : 
>>> : > This test seems to fail consistently for me on 8x:
>>> : >
>>> : >
>>> : > org.apache.solr.rest.schema.TestBulkSchemaAPI.testCopyFieldWithReplace
>>> : >
>>> : >
>>> : > NOTE: reproduce with: ant test  -Dtestcase=TestBulkSchemaAPI
>>> : > -Dtests.method=testCopyFieldWithReplace -Dtests.seed=7657D4FA16A76DC8
>>> : > -Dtests.slow=true -Dtests.badapples=true -Dtests.locale=es-UY
>>> : > -Dtests.timezone=America/Resolute -Dtests.asserts=true
>>> : > -Dtests.file.encoding=UTF-8
>>> : >
>>> : > java.lang.AssertionError: {
>>> : >   "responseHeader":{
>>> : > "status":400,
>>> : > "QTime":6},
>>> : >   "error":{
>>> : > "metadata":[
>>> : >   "error-class","org.apache.solr.api.ApiBag$ExceptionWithErrObject",
>>> : >
>>> : > "root-error-class","org.apache.solr.api.ApiBag$ExceptionWithErrObject"],
>>> : > "details":[{
>>> : > "add-field-type":{
>>> : >   "name":"myNewTextField",
>>> : >   "class":"solr.TextField",
>>> : >   "analyzer":{
>>> : > "charFilters":[{
>>> : > "name":"patternReplace",
>>> : > "replacement":"$1$1",
>>> : > "pattern":"([a-zA-Z])1+"}],
>>> : > "tokenizer":{"name":"whitespace"},
>>> : > "filters":[{"name":"asciiFolding"}]}},
>>> : > "errorMessages":["Every charFilter must define a class
>>> : > property!\n"]}],
>>> : > "msg":"error processing commands",
>>> : > "code":400}}
>>> : >  expected null, but was:<{metadata=[error-class,
>>> : > org.apache.solr.api.ApiBag$ExceptionWithErrObject, root-error-class,
>>> : > org.apache.solr.api.ApiBag$ExceptionWithErrObject],
>>> : > details=[{add-field-type={name=myNewTextField, class=solr.TextField,
>>> : > analyzer={charFilters=[{name=patternReplace, replacement=$1$1,
>>> : > pattern=([a-zA-Z])\\1+}], tokenizer={name=whitespace},
>>> : > filters=[{name=asciiFolding}]}}, errorMessages=[Every charFilter must
>>> : > define a class property!
>>> : > ]}], msg=error processing commands, code=400}>
>>> : >
>>> : > at 
>>> __randomizedtesting.SeedInfo.seed([7657D4FA16A76DC8:B096864C3F5D3F33]:0)
>>> : > at org.junit.Assert.fail(Assert.java:89)
>>> : > at org.junit.Assert.failNotNull(Assert.java:756)
>>> : > at org.junit.Assert.assertNull(Assert.java:738)
>>> : > at
>>> : > 
>>> org.apache.solr.rest.schema.TestBulkSchemaAPI.testCopyFieldWithReplace(TestBulkSchemaAPI.java:734)
>>> : > 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)
>>> : >
>>> : 
>>> 
>>> -Hoss
>>> http://www.lucidworks.com/
>>> 
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>> 

Failing test on branch_8x: org.apache.solr.rest.schema.TestBulkSchemaAPI.testCopyFieldWithReplace

[Timothy Potter]

This test seems to fail consistently for me on 8x:


org.apache.solr.rest.schema.TestBulkSchemaAPI.testCopyFieldWithReplace


NOTE: reproduce with: ant test  -Dtestcase=TestBulkSchemaAPI
-Dtests.method=testCopyFieldWithReplace -Dtests.seed=7657D4FA16A76DC8
-Dtests.slow=true -Dtests.badapples=true -Dtests.locale=es-UY
-Dtests.timezone=America/Resolute -Dtests.asserts=true
-Dtests.file.encoding=UTF-8

java.lang.AssertionError: {
  "responseHeader":{
"status":400,
"QTime":6},
  "error":{
"metadata":[
  "error-class","org.apache.solr.api.ApiBag$ExceptionWithErrObject",

"root-error-class","org.apache.solr.api.ApiBag$ExceptionWithErrObject"],
"details":[{
"add-field-type":{
  "name":"myNewTextField",
  "class":"solr.TextField",
  "analyzer":{
"charFilters":[{
"name":"patternReplace",
"replacement":"$1$1",
"pattern":"([a-zA-Z])1+"}],
"tokenizer":{"name":"whitespace"},
"filters":[{"name":"asciiFolding"}]}},
"errorMessages":["Every charFilter must define a class
property!\n"]}],
"msg":"error processing commands",
"code":400}}
 expected null, but was:<{metadata=[error-class,
org.apache.solr.api.ApiBag$ExceptionWithErrObject, root-error-class,
org.apache.solr.api.ApiBag$ExceptionWithErrObject],
details=[{add-field-type={name=myNewTextField, class=solr.TextField,
analyzer={charFilters=[{name=patternReplace, replacement=$1$1,
pattern=([a-zA-Z])\\1+}], tokenizer={name=whitespace},
filters=[{name=asciiFolding}]}}, errorMessages=[Every charFilter must
define a class property!
]}], msg=error processing commands, code=400}>

at __randomizedtesting.SeedInfo.seed([7657D4FA16A76DC8:B096864C3F5D3F33]:0)
at org.junit.Assert.fail(Assert.java:89)
at org.junit.Assert.failNotNull(Assert.java:756)
at org.junit.Assert.assertNull(Assert.java:738)
at
org.apache.solr.rest.schema.TestBulkSchemaAPI.testCopyFieldWithReplace(TestBulkSchemaAPI.java:734)
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)

Re: 8.8 Release

[Timothy Potter]

Thanks for following up on this Ishan ... I intend to get SOLR-15059 and
-15036 into 8.8 as well. I should have a proper PR up for SOLR-15036 by
Friday sometime, which seems to align with other's timeframes

Cheers,
Tim

On Wed, Jan 6, 2021 at 6:54 AM David Smiley  wrote:

> Happy New Year!
> I would much prefer that ensure 8.8 includes SOLR-14923 (a bad nested docs
> performance issue)
>
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley
>
>
> On Wed, Jan 6, 2021 at 6:59 AM Ishan Chattopadhyaya <
> ichattopadhy...@gmail.com> wrote:
>
>> Happy New Year!
>>
>> I was supposed to start the process tomorrow, but I think we're not ready
>> yet? I see SOLR-15052 still under review with intention of inclusion into
>> 8.8.
>> Would it be reasonable to cut the release branch end of this week and
>> start the RC process around 13th January?
>> If there are any issues someone would want me to wait on, please let me
>> know.
>>
>> Thanks,
>> Ishan
>>
>> On Fri, Dec 18, 2020 at 6:10 AM Ishan Chattopadhyaya <
>> ichattopadhy...@gmail.com> wrote:
>>
>>> Sure, Houston. I'll wait another week. Have a good new year and merry
>>> Christmas!
>>>
>>> On Fri, 18 Dec, 2020, 5:58 am Timothy Potter, 
>>> wrote:
>>>
>>>> Great point Houston! +1 on waiting until a week into January
>>>>
>>>> On Thu, Dec 17, 2020 at 4:46 PM Houston Putman 
>>>> wrote:
>>>>
>>>>> Thanks for volunteering Ishan.
>>>>>
>>>>> I think it might be a good idea to wait to cut and release 8.8 at
>>>>> least a week into January. Many people are going to be away during the
>>>>> holiday season, and particularly the last week of the year. Pushing into
>>>>> January just gives more people a chance to look at the release and be
>>>>> involved.
>>>>>
>>>>> - Houston
>>>>>
>>>>> On Fri, Dec 11, 2020 at 3:26 PM Noble Paul 
>>>>> wrote:
>>>>>
>>>>>> Thanks Ishan for volunteering
>>>>>>
>>>>>> On Fri, Dec 11, 2020 at 5:07 AM Christine Poerschke (BLOOMBERG/
>>>>>> LONDON)  wrote:
>>>>>> >
>>>>>> > With a view towards including it in the release, I'd appreciate
>>>>>> code review input on
>>>>>> >
>>>>>> > https://github.com/apache/lucene-solr/pull/1992 for
>>>>>> >
>>>>>> > https://issues.apache.org/jira/browse/SOLR-14939 (JSON facets:
>>>>>> range faceting to support cache=false parameter)
>>>>>> >
>>>>>> > if anyone has some time next week perhaps?
>>>>>> >
>>>>>> > Thanks in advance!
>>>>>> >
>>>>>> > Christine
>>>>>> >
>>>>>> > From: dev@lucene.apache.org At: 12/10/20 18:01:58
>>>>>> > To: dev@lucene.apache.org
>>>>>> > Subject: Re: 8.8 Release
>>>>>> >
>>>>>> > +1
>>>>>> >
>>>>>> > Joel Bernstein
>>>>>> > http://joelsolr.blogspot.com/
>>>>>> >
>>>>>> >
>>>>>> > On Thu, Dec 10, 2020 at 11:23 AM David Smiley 
>>>>>> wrote:
>>>>>> >>
>>>>>> >> Thanks for volunteering!
>>>>>> >>
>>>>>> >> On Thu, Dec 10, 2020 at 11:11 AM Ishan Chattopadhyaya <
>>>>>> ichattopadhy...@gmail.com> wrote:
>>>>>> >>>
>>>>>> >>> Hi Devs,
>>>>>> >>> There are lots of changes accumulated and some underway. I wish
>>>>>> to volunteer for a 8.8 release, if there are no objections. I'm planning 
>>>>>> to
>>>>>> build the RC in three weeks, i.e. 31 December (and cut the branch about 
>>>>>> 3-4
>>>>>> days before that). Please let me know if someone has any concerns.
>>>>>> >>> Thanks and regards,
>>>>>> >>> Ishan
>>>>>> >>>
>>>>>> >> --
>>>>>> >> Sent from Gmail Mobile
>>>>>> >
>>>>>> >
>>>>>>
>>>>>>
>>>>>> --
>>>>>> -
>>>>>> Noble Paul
>>>>>>
>>>>>> -
>>>>>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>>>>>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>>>>>
>>>>>>

Re: 9.0 release

[Timothy Potter]

Hear! Hear! Definitely agree it's time to start planning around 9. Thanks
for initiating the discussion Mike. Will follow-up after the new year with
some specific thoughts around planning.

Cheers,
Tim

On Mon, Dec 28, 2020 at 11:17 AM Michael Sokolov  wrote:

> Hi everyone, as we head into a new year full of optimism, is it time
> to start discussing the next major release? We released 8.0 on Jun 18,
> 2019, over 18 months ago. Since then we've switched to a gradle-based
> build. We have added vector-valued fields and an HNSW neighbor search
> algorithm for them.  At the same time Solr has been getting a major
> overhaul which should justify a release, I think? IIRC there was talk
> of making 9.0 be the first release of Solr as its own TLP. Is it time
> to start planning for that now?
>
> -Mike
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

Re: 8.8 Release

[Timothy Potter]

Great point Houston! +1 on waiting until a week into January

On Thu, Dec 17, 2020 at 4:46 PM Houston Putman 
wrote:

> Thanks for volunteering Ishan.
>
> I think it might be a good idea to wait to cut and release 8.8 at least a
> week into January. Many people are going to be away during the holiday
> season, and particularly the last week of the year. Pushing into January
> just gives more people a chance to look at the release and be involved.
>
> - Houston
>
> On Fri, Dec 11, 2020 at 3:26 PM Noble Paul  wrote:
>
>> Thanks Ishan for volunteering
>>
>> On Fri, Dec 11, 2020 at 5:07 AM Christine Poerschke (BLOOMBERG/
>> LONDON)  wrote:
>> >
>> > With a view towards including it in the release, I'd appreciate code
>> review input on
>> >
>> > https://github.com/apache/lucene-solr/pull/1992 for
>> >
>> > https://issues.apache.org/jira/browse/SOLR-14939 (JSON facets: range
>> faceting to support cache=false parameter)
>> >
>> > if anyone has some time next week perhaps?
>> >
>> > Thanks in advance!
>> >
>> > Christine
>> >
>> > From: dev@lucene.apache.org At: 12/10/20 18:01:58
>> > To: dev@lucene.apache.org
>> > Subject: Re: 8.8 Release
>> >
>> > +1
>> >
>> > Joel Bernstein
>> > http://joelsolr.blogspot.com/
>> >
>> >
>> > On Thu, Dec 10, 2020 at 11:23 AM David Smiley 
>> wrote:
>> >>
>> >> Thanks for volunteering!
>> >>
>> >> On Thu, Dec 10, 2020 at 11:11 AM Ishan Chattopadhyaya <
>> ichattopadhy...@gmail.com> wrote:
>> >>>
>> >>> Hi Devs,
>> >>> There are lots of changes accumulated and some underway. I wish to
>> volunteer for a 8.8 release, if there are no objections. I'm planning to
>> build the RC in three weeks, i.e. 31 December (and cut the branch about 3-4
>> days before that). Please let me know if someone has any concerns.
>> >>> Thanks and regards,
>> >>> Ishan
>> >>>
>> >> --
>> >> Sent from Gmail Mobile
>> >
>> >
>>
>>
>> --
>> -
>> Noble Paul
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>>

Re: [IMPORTANT] Automatic code reformatting (LUCENE-9564)

[Timothy Potter]

Sounds great Dawid! And sorely needed in this project, thanks for taking
this on. I'll do as much as I can on the Solr side ;-)

Cheers,
Tim

On Thu, Dec 17, 2020 at 4:31 AM Dawid Weiss  wrote:

> Hey everyone,
>
> Sorry it took me a while but I wanted to get back to LUCENE-9564 and
> applying an automated (and non-configurable) code formatter. This will
> cause some disruption to all existing branches and patches so I'd like
> to make the process as simple as possible by doing the following:
>
> 1) adding spotless (formatter infrastructure) to gradle build on
> master. This literally changes nothing as initially it wouldn't be
> including any sources.
>
> 2) progressively go package-by-package and project-by-project and
> reformat code, then commit it back to master. Splitting into smaller
> work pieces is simpler and perhaps others may help in to review if the
> formatter didn't screw up anything (I'll start!).
>
> 3) IF YOU HAVE AN OPEN PATCH or branch and the master is reformatted,
> don't despair. It's actually pretty easy to recover -- all you'd need
> to do would be to cherry pick the initial spotless commit from (1),
> then take the up-to-date content of spotless.gradle and just run this
> on your branch:
>
> ./gradlew tidy
>
> This should reformat the same packages and the same code as on master.
> If nothing has changed, the diff between your branch and master should
> be empty. If something *did* change, the reformatted code should still
> cleanly show just the lines you've changed.
>
> Commit the changes to your branch and you should be fine.
>
> Does this sound like a plan? I'd like to start with the initial few
> packages from the core and a few other projects so that folks can see
> what the process looks like - then I'd really like a helping hand with
> the rest. I'm only concerned with Lucene at the moment.
>
> Dawid
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

Re: Problems creating collections on branch_8x due to SSL errors

[Timothy Potter]

just merged a fix, re-pull, see:
https://issues.apache.org/jira/browse/SOLR-15046 for details

On Mon, Dec 14, 2020 at 9:42 AM Joel Bernstein  wrote:

> I did a pull this morning and checked out branch_8x and then did the
> following:
>
> ant server
> bin/solr start -c
> bin/solr create -c test -s 1 -d _default
>
> I get the following error in the logs. Jason Gerlowski confirmed he is
> seeing it as well. Anyone know the cause of this? If not I'll create a
> ticket.
>
> 2020-12-14 16:33:15.463 INFO  
> (OverseerStateUpdate-72065849883426816-10.0.0.238:8983_solr-n_00)
> [   ] o.a.s.c.o.SliceMutator createReplica() {
>
>   "operation":"ADDREPLICA",
>
>   "collection":"test",
>
>   "shard":"shard1",
>
>   "core":"test_shard1_replica_n1",
>
>   "state":"down",
>
>   "node_name":"10.0.0.238:8983_solr",
>
>   "type":"NRT",
>
>   "waitForFinalState":"false"}
>
> 2020-12-14 16:33:15.736 ERROR
> (OverseerThreadFactory-18-thread-1-processing-n:10.0.0.238:8983_solr) [   ]
> o.a.s.c.a.c.OverseerCollectionMessageHandler Error from shard:
> https://10.0.0.238:8983/solr =>
> org.apache.solr.client.solrj.SolrServerException: IOException occurred when
> talking to server at: https://10.0.0.238:8983/solr
>
> at
> org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:695)
>
> org.apache.solr.client.solrj.SolrServerException: IOException occurred
> when talking to server at: https://10.0.0.238:8983/solr
>
> at
> org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:695)
> ~[?:?]
>
> at
> org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:266)
> ~[?:?]
>
> at
> org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:248)
> ~[?:?]
>
> at
> org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1290) ~[?:?]
>
> at
> org.apache.solr.handler.component.HttpShardHandlerFactory$1.request(HttpShardHandlerFactory.java:169)
> ~[?:?]
>
> at
> org.apache.solr.handler.component.ShardRequestor.call(ShardRequestor.java:130)
> ~[?:?]
>
> at
> org.apache.solr.handler.component.ShardRequestor.call(ShardRequestor.java:41)
> ~[?:?]
>
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> ~[?:1.8.0_271]
>
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> ~[?:1.8.0_271]
>
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> ~[?:1.8.0_271]
>
> at
> com.codahale.metrics.InstrumentedExecutorService$InstrumentedRunnable.run(InstrumentedExecutorService.java:180)
> ~[metrics-core-4.1.5.jar:4.1.5]
>
> at
> org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:218)
> ~[?:?]
>
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> ~[?:1.8.0_271]
>
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> ~[?:1.8.0_271]
>
> at java.lang.Thread.run(Thread.java:748) [?:1.8.0_271]
>
> Caused by: javax.net.ssl.SSLException: Unsupported or unrecognized SSL
> message
>
> at
> sun.security.ssl.SSLSocketInputRecord.handleUnknownRecord(SSLSocketInputRecord.java:448)
> ~[?:1.8.0_271]
>
> at
> sun.security.ssl.SSLSocketInputRecord.decode(SSLSocketInputRecord.java:174)
> ~[?:1.8.0_271]
>
> at sun.security.ssl.SSLTransport.decode(SSLTransport.java:110)
> ~[?:1.8.0_271]
>
> at sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1279)
> ~[?:1.8.0_271]
>
> at
> sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1188)
> ~[?:1.8.0_271]
>
> at
> sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:401)
> ~[?:1.8.0_271]
>
> at
> sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:373)
> ~[?:1.8.0_271]
>
> at
> org.apache.http.conn.ssl.SSLConnectionSocketFactory.createLayeredSocket(SSLConnectionSocketFactory.java:436)
> ~[?:?]
>
> at
> org.apache.http.conn.ssl.SSLConnectionSocketFactory.connectSocket(SSLConnectionSocketFactory.java:384)
> ~[?:?]
>
> at
> org.apache.http.impl.conn.DefaultHttpClientConnectionOperator.connect(DefaultHttpClientConnectionOperator.java:142)
> ~[?:?]
>
> at
> org.apache.http.impl.conn.PoolingHttpClientConnectionManager.connect(PoolingHttpClientConnectionManager.java:376)
> ~[?:?]
>
> at
> org.apache.http.impl.execchain.MainClientExec.establishRoute(MainClientExec.java:393)
> ~[?:?]
>
> at
> org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:236)
> ~[?:?]
>
> at
> org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:186)
> ~[?:?]
>
> at
> org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:89) ~[?:?]
>
> at
> org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:110)
> ~[?:?]
>
> at
> 

Re: Welcome Houston Putman to the PMC

[Timothy Potter]

Welcome Houston!

On Tue, Dec 1, 2020 at 2:43 PM Tomás Fernández Löbbe 
wrote:

> Welcome Houston!!
>
> On Tue, Dec 1, 2020 at 1:28 PM Anshum Gupta 
> wrote:
>
>> Congratulations and welcome, Houston!
>>
>> On Tue, Dec 1, 2020 at 1:19 PM Mike Drob  wrote:
>>
>>> I am pleased to announce that Houston Putman has accepted the PMC's
>>> invitation to join.
>>>
>>> Congratulations and welcome, Houston!
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>>
>>>
>>
>> --
>> Anshum Gupta
>>
>

Re: restlet dependencies

[Timothy Potter]

Ok, good enough for me, thanks for feedback David and Noble, proceeding
with the cherry-picks to 8x

Tim

On Tue, Oct 6, 2020 at 8:25 PM David Smiley  wrote:

> No strong opinion from me.  I think the back-compat concern is minor.
>
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley
>
>
> On Tue, Oct 6, 2020 at 5:42 PM Noble Paul  wrote:
>
>> I think we should call that out in the changes.txt and make the changes
>> right away.
>>
>> On Wed, Oct 7, 2020, 8:20 AM Timothy Potter  wrote:
>>
>>> Just want to close the loop on this restlet issue. I've removed the
>>> restlet dependency in master (e879a52291ef7dcd0514e7419d811b6ff800bcce) but
>>> have not backported that to 8.x yet.
>>>
>>> I'm hesitant to backport because I had to change public function
>>> signatures on ManagedResource, e.g.
>>> https://github.com/apache/lucene-solr/commit/e879a52291ef7dcd0514e7419d811b6ff800bcce#diff-faaf5cd2bfe038f81ca4c0cb1986b42dR355
>>> ...
>>>
>>> So technically, this could break upgrades for environments with
>>> extensions to those classes; practically speaking, I think the risk of that
>>> is low, but not sure it is worth it? From what I understand, the restlet
>>> maven issue was mostly affecting master / gradle builds and the ant/ivy
>>> builds in 8.x weren't affected as much?
>>>
>>> It's an easy back-port from master to 8.x if that's what we want to do,
>>> but wanted to raise awareness that it will break public function signatures
>>> on classes that may have extensions in the wild ;-)
>>>
>>> ~ Tim
>>>
>>> On Thu, Oct 1, 2020 at 8:36 AM Timothy Potter 
>>> wrote:
>>>
>>>> Awesome guys, thanks for the pointers ... am cooking up a PR (for
>>>> master) for this today
>>>>
>>>> On Thu, Oct 1, 2020 at 2:22 AM Noble Paul  wrote:
>>>>
>>>>> The annotation (
>>>>> https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/api/EndPoint.java
>>>>> )
>>>>> supports wild cards and templated paths
>>>>>
>>>>> On Thu, Oct 1, 2020 at 5:28 PM Ishan Chattopadhyaya
>>>>>  wrote:
>>>>> >
>>>>> > > But when I suggested porting the code that uses restlet to JAX-RS
>>>>> / Jersey, Ishan said
>>>>> > > that wasn't necessary and is already supported with some
>>>>> Annotations ... I have no idea
>>>>> > > what that means and need more info about what is already in place.
>>>>> >
>>>>> > I was mainly referring to the @Endpoint annotations. It is available
>>>>> for V2 APIs today (and I think it should be fine to use for anything we
>>>>> build now onwards, including managed resources V2).
>>>>> > It is possible to make it work with V1, but that will require some
>>>>> work.
>>>>> >
>>>>> > On Thu, Oct 1, 2020 at 12:50 PM Ishan Chattopadhyaya <
>>>>> ichattopadhy...@gmail.com> wrote:
>>>>> >>
>>>>> >> @Tim
>>>>> >>
>>>>> >> Please check ClusterAPI or ZookeeperReadAPI etc.
>>>>> >> Recently used it in Yasa:
>>>>> https://github.com/yasa-org/yasa/blob/master/yasa-solr-plugin/src/main/java/io/github/kezhenxu94/YasaHandler.java
>>>>> >>
>>>>> >> On Thu, Oct 1, 2020 at 10:46 AM Noble Paul 
>>>>> wrote:
>>>>> >>>
>>>>> >>> @Tim Potter
>>>>> >>>
>>>>> >>> I tried several times to get rid of the restlet dependency & keep
>>>>> the
>>>>> >>> functionality as is. I failed miserably. I'm not saying this to
>>>>> >>> discourage anyone who wants to give a try. Just letting you know
>>>>> that
>>>>> >>> it is not as easy as it may sound
>>>>> >>>
>>>>> >>> On Thu, Oct 1, 2020 at 2:42 AM Houston Putman <
>>>>> houstonput...@gmail.com> wrote:
>>>>> >>> >
>>>>> >>> > +1 to Tomas' proposal. Created SOLR-14907 to track the effort.
>>>>> >>> >
>>>>> >>> >  - Houston
>>>>> >>> >
>>>>> >>> > On We

Re: restlet dependencies

[Timothy Potter]

Just want to close the loop on this restlet issue. I've removed the restlet
dependency in master (e879a52291ef7dcd0514e7419d811b6ff800bcce) but have
not backported that to 8.x yet.

I'm hesitant to backport because I had to change public function signatures
on ManagedResource, e.g.
https://github.com/apache/lucene-solr/commit/e879a52291ef7dcd0514e7419d811b6ff800bcce#diff-faaf5cd2bfe038f81ca4c0cb1986b42dR355
...

So technically, this could break upgrades for environments with extensions
to those classes; practically speaking, I think the risk of that is low,
but not sure it is worth it? From what I understand, the restlet maven
issue was mostly affecting master / gradle builds and the ant/ivy builds in
8.x weren't affected as much?

It's an easy back-port from master to 8.x if that's what we want to do, but
wanted to raise awareness that it will break public function signatures on
classes that may have extensions in the wild ;-)

~ Tim

On Thu, Oct 1, 2020 at 8:36 AM Timothy Potter  wrote:

> Awesome guys, thanks for the pointers ... am cooking up a PR (for master)
> for this today
>
> On Thu, Oct 1, 2020 at 2:22 AM Noble Paul  wrote:
>
>> The annotation (
>> https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/api/EndPoint.java
>> )
>> supports wild cards and templated paths
>>
>> On Thu, Oct 1, 2020 at 5:28 PM Ishan Chattopadhyaya
>>  wrote:
>> >
>> > > But when I suggested porting the code that uses restlet to JAX-RS /
>> Jersey, Ishan said
>> > > that wasn't necessary and is already supported with some Annotations
>> ... I have no idea
>> > > what that means and need more info about what is already in place.
>> >
>> > I was mainly referring to the @Endpoint annotations. It is available
>> for V2 APIs today (and I think it should be fine to use for anything we
>> build now onwards, including managed resources V2).
>> > It is possible to make it work with V1, but that will require some work.
>> >
>> > On Thu, Oct 1, 2020 at 12:50 PM Ishan Chattopadhyaya <
>> ichattopadhy...@gmail.com> wrote:
>> >>
>> >> @Tim
>> >>
>> >> Please check ClusterAPI or ZookeeperReadAPI etc.
>> >> Recently used it in Yasa:
>> https://github.com/yasa-org/yasa/blob/master/yasa-solr-plugin/src/main/java/io/github/kezhenxu94/YasaHandler.java
>> >>
>> >> On Thu, Oct 1, 2020 at 10:46 AM Noble Paul 
>> wrote:
>> >>>
>> >>> @Tim Potter
>> >>>
>> >>> I tried several times to get rid of the restlet dependency & keep the
>> >>> functionality as is. I failed miserably. I'm not saying this to
>> >>> discourage anyone who wants to give a try. Just letting you know that
>> >>> it is not as easy as it may sound
>> >>>
>> >>> On Thu, Oct 1, 2020 at 2:42 AM Houston Putman <
>> houstonput...@gmail.com> wrote:
>> >>> >
>> >>> > +1 to Tomas' proposal. Created SOLR-14907 to track the effort.
>> >>> >
>> >>> >  - Houston
>> >>> >
>> >>> > On Wed, Sep 30, 2020 at 12:26 PM Tomás Fernández Löbbe <
>> tomasflo...@gmail.com> wrote:
>> >>> >>
>> >>> >> > Let's support the single file upload feature
>> >>> >> +1, but let this behave exactly as a zip file with a single file
>> in it (regarding trusted/untrusted). We just need to change the configset
>> handler to be able to handle non-zip files, and have a way to "locate" that
>> file inside the configset (in case it needs to go somewhere other than the
>> root).
>> >>> >>
>> >>> >> On Wed, Sep 30, 2020 at 8:45 AM Eric Pugh <
>> ep...@opensourceconnections.com> wrote:
>> >>> >>>
>> >>> >>> I think that me in “violent agreement” with you.   Let’s
>> understand the Annotations approach that we have, or pick something that is
>> commonly used like JAX-RS / Jersey.
>> >>> >>>
>> >>> >>>
>> >>> >>>
>> >>> >>> On Sep 30, 2020, at 11:41 AM, Timothy Potter <
>> thelabd...@gmail.com> wrote:
>> >>> >>>
>> >>> >>> I'm sorry, I don't understand what you mean by "make it a single
>> pattern (the annotations?)" Eric?
>> >>> >>>
>> >>> >>> To me, the pattern is well established in the Java world: JAX-RS
>> (with Jersey a

Re: restlet dependencies

[Timothy Potter]

Awesome guys, thanks for the pointers ... am cooking up a PR (for master)
for this today

On Thu, Oct 1, 2020 at 2:22 AM Noble Paul  wrote:

> The annotation (
> https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/api/EndPoint.java
> )
> supports wild cards and templated paths
>
> On Thu, Oct 1, 2020 at 5:28 PM Ishan Chattopadhyaya
>  wrote:
> >
> > > But when I suggested porting the code that uses restlet to JAX-RS /
> Jersey, Ishan said
> > > that wasn't necessary and is already supported with some Annotations
> ... I have no idea
> > > what that means and need more info about what is already in place.
> >
> > I was mainly referring to the @Endpoint annotations. It is available for
> V2 APIs today (and I think it should be fine to use for anything we build
> now onwards, including managed resources V2).
> > It is possible to make it work with V1, but that will require some work.
> >
> > On Thu, Oct 1, 2020 at 12:50 PM Ishan Chattopadhyaya <
> ichattopadhy...@gmail.com> wrote:
> >>
> >> @Tim
> >>
> >> Please check ClusterAPI or ZookeeperReadAPI etc.
> >> Recently used it in Yasa:
> https://github.com/yasa-org/yasa/blob/master/yasa-solr-plugin/src/main/java/io/github/kezhenxu94/YasaHandler.java
> >>
> >> On Thu, Oct 1, 2020 at 10:46 AM Noble Paul 
> wrote:
> >>>
> >>> @Tim Potter
> >>>
> >>> I tried several times to get rid of the restlet dependency & keep the
> >>> functionality as is. I failed miserably. I'm not saying this to
> >>> discourage anyone who wants to give a try. Just letting you know that
> >>> it is not as easy as it may sound
> >>>
> >>> On Thu, Oct 1, 2020 at 2:42 AM Houston Putman 
> wrote:
> >>> >
> >>> > +1 to Tomas' proposal. Created SOLR-14907 to track the effort.
> >>> >
> >>> >  - Houston
> >>> >
> >>> > On Wed, Sep 30, 2020 at 12:26 PM Tomás Fernández Löbbe <
> tomasflo...@gmail.com> wrote:
> >>> >>
> >>> >> > Let's support the single file upload feature
> >>> >> +1, but let this behave exactly as a zip file with a single file in
> it (regarding trusted/untrusted). We just need to change the configset
> handler to be able to handle non-zip files, and have a way to "locate" that
> file inside the configset (in case it needs to go somewhere other than the
> root).
> >>> >>
> >>> >> On Wed, Sep 30, 2020 at 8:45 AM Eric Pugh <
> ep...@opensourceconnections.com> wrote:
> >>> >>>
> >>> >>> I think that me in “violent agreement” with you.   Let’s
> understand the Annotations approach that we have, or pick something that is
> commonly used like JAX-RS / Jersey.
> >>> >>>
> >>> >>>
> >>> >>>
> >>> >>> On Sep 30, 2020, at 11:41 AM, Timothy Potter 
> wrote:
> >>> >>>
> >>> >>> I'm sorry, I don't understand what you mean by "make it a single
> pattern (the annotations?)" Eric?
> >>> >>>
> >>> >>> To me, the pattern is well established in the Java world: JAX-RS
> (with Jersey as the underlying impl. which has nice integration with
> Jetty). But when I suggested porting the code that uses restlet to JAX-RS /
> Jersey, Ishan said that wasn't necessary and is already supported with some
> Annotations ... I have no idea what that means and need more info about
> what is already in place. Short of that, replacing restlet with JAX-RS /
> Jersey looks like a trivial amount of work to me (and I'm happy to take it
> on).
> >>> >>>
> >>> >>> Tim
> >>> >>>
> >>> >>> On Wed, Sep 30, 2020 at 9:36 AM Eric Pugh <
> ep...@opensourceconnections.com> wrote:
> >>> >>>>
> >>> >>>> The use case of “I want to update something via a API” is I think
> pretty common, and it would be nice to make it a single pattern (the
> annotations?) with lots of examples/developer docs for the next person.
> >>> >>>>
> >>> >>>>
> >>> >>>>
> >>> >>>> On Sep 30, 2020, at 11:04 AM, Timothy Potter <
> thelabd...@gmail.com> wrote:
> >>> >>>>
> >>> >>>> I started looking into removing Managed Resources in master and
> wanted to mention t

Re: restlet dependencies

[Timothy Potter]

I'm sorry, I don't understand what you mean by "make it a single pattern
(the annotations?)" Eric?

To me, the pattern is well established in the Java world: JAX-RS (with
Jersey as the underlying impl. which has nice integration with Jetty). But
when I suggested porting the code that uses restlet to JAX-RS / Jersey,
Ishan said that wasn't necessary and is already supported with some
Annotations ... I have no idea what that means and need more info about
what is already in place. Short of that, replacing restlet with JAX-RS /
Jersey looks like a trivial amount of work to me (and I'm happy to take it
on).

Tim

On Wed, Sep 30, 2020 at 9:36 AM Eric Pugh 
wrote:

> The use case of “I want to update something via a API” is I think pretty
> common, and it would be nice to make it a single pattern (the annotations?)
> with lots of examples/developer docs for the next person.
>
>
>
> On Sep 30, 2020, at 11:04 AM, Timothy Potter  wrote:
>
> I started looking into removing Managed Resources in master and wanted to
> mention that the LTR contrib also relies on this framework
> (ManagedModelStore and ManagedFeatureStore, see:
> https://lucene.apache.org/solr/guide/8_6/learning-to-rank.html#uploading-a-model).
> I only mention this b/c it's been said several times in this thread that
> nobody uses this feature and it's only for editing config/schema like
> synonyms. Afaik, LTR is a broadly used feature of Solr so now I'm not so
> bullish on removing the ability to manage dynamic resources using a REST
> like API. I agree that changing resources like the synonym set could be
> replaced with configSet updates but I don't see how to replace the RESTful
> model / feature store API w/o something like Managed Resources?
>
> From where I sit, I think we should just remove the use of restlet in the
> implementation but keep the API for Solr 9 (master).
>
> @Ishan ~ you mentioned there is a way to get REST API like behavior w/o
> using JAX-RS / Jersey ... something about annotations? Can you point me to
> some example code of how that is done please?
>
> Cheers,
> Tim
>
> On Wed, Sep 30, 2020 at 8:29 AM David Smiley  wrote:
>
>> These resources are fundamentally a part of the configSet and can (in
>> general) affect query results and thus flushing caches (via a reload) is
>> appropriate.
>>
>> ~ David Smiley
>> Apache Lucene/Solr Search Developer
>> http://www.linkedin.com/in/davidwsmiley
>>
>>
>> On Wed, Sep 30, 2020 at 9:06 AM Noble Paul  wrote:
>>
>>> Well, I believe we should have a mechanism to upload a single file to
>>> a configset.
>>>
>>> >  A single file configset upload would require the user to reload the
>>> collection, so it isn't better than managed resources.
>>>
>>> This is not true
>>>
>>> Only config/schema file changes result in core reload.
>>>
>>> On Wed, Sep 30, 2020 at 10:23 PM David Smiley 
>>> wrote:
>>> >
>>> > Definitely don't remove in 8.x!
>>> >
>>> > >  A single file configset upload would require the user to reload the
>>> collection, so it isn't better than managed resources.
>>> >
>>> > Do you view that as a substantial point in favor of
>>> managed-resources?  I view that as a trivial matter, and one I prefer to
>>> automagic and potentially premature reload if there are additional edits to
>>> be done (e.g. query-elevation or other word lists).
>>> >
>>> > ~ David Smiley
>>> > Apache Lucene/Solr Search Developer
>>> > http://www.linkedin.com/in/davidwsmiley
>>> >
>>> >
>>> > On Wed, Sep 30, 2020 at 5:46 AM Ishan Chattopadhyaya <
>>> ichattopadhy...@gmail.com> wrote:
>>> >>
>>> >> > * Nobody knows how it works. It's unsupported
>>> >> It is supported and documented:
>>> https://lucene.apache.org/solr/guide/8_6/managed-resources.html
>>> >>
>>> >> > * RESTlet dependency
>>> >> > * Cannot be secured using standard permissions
>>> >> > * It's extremely complex for the functionality it offers.
>>> >>
>>> >> I agree. Whatever alternative we build should address these, before
>>> we consider removing managed resources.
>>> >>
>>> >> On Wed, Sep 30, 2020 at 2:52 PM Ishan Chattopadhyaya <
>>> ichattopadhy...@gmail.com> wrote:
>>> >>>
>>> >>> The managed resources is the only reasonable way to upload synonyms
>>> on the fly for users today. A single file configset upl

Re: restlet dependencies

[Timothy Potter]

I started looking into removing Managed Resources in master and wanted to
mention that the LTR contrib also relies on this framework
(ManagedModelStore and ManagedFeatureStore, see:
https://lucene.apache.org/solr/guide/8_6/learning-to-rank.html#uploading-a-model).
I only mention this b/c it's been said several times in this thread that
nobody uses this feature and it's only for editing config/schema like
synonyms. Afaik, LTR is a broadly used feature of Solr so now I'm not so
bullish on removing the ability to manage dynamic resources using a REST
like API. I agree that changing resources like the synonym set could be
replaced with configSet updates but I don't see how to replace the RESTful
model / feature store API w/o something like Managed Resources?

>From where I sit, I think we should just remove the use of restlet in the
implementation but keep the API for Solr 9 (master).

@Ishan ~ you mentioned there is a way to get REST API like behavior w/o
using JAX-RS / Jersey ... something about annotations? Can you point me to
some example code of how that is done please?

Cheers,
Tim

On Wed, Sep 30, 2020 at 8:29 AM David Smiley  wrote:

> These resources are fundamentally a part of the configSet and can (in
> general) affect query results and thus flushing caches (via a reload) is
> appropriate.
>
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley
>
>
> On Wed, Sep 30, 2020 at 9:06 AM Noble Paul  wrote:
>
>> Well, I believe we should have a mechanism to upload a single file to
>> a configset.
>>
>> >  A single file configset upload would require the user to reload the
>> collection, so it isn't better than managed resources.
>>
>> This is not true
>>
>> Only config/schema file changes result in core reload.
>>
>> On Wed, Sep 30, 2020 at 10:23 PM David Smiley  wrote:
>> >
>> > Definitely don't remove in 8.x!
>> >
>> > >  A single file configset upload would require the user to reload the
>> collection, so it isn't better than managed resources.
>> >
>> > Do you view that as a substantial point in favor of managed-resources?
>> I view that as a trivial matter, and one I prefer to automagic and
>> potentially premature reload if there are additional edits to be done (e.g.
>> query-elevation or other word lists).
>> >
>> > ~ David Smiley
>> > Apache Lucene/Solr Search Developer
>> > http://www.linkedin.com/in/davidwsmiley
>> >
>> >
>> > On Wed, Sep 30, 2020 at 5:46 AM Ishan Chattopadhyaya <
>> ichattopadhy...@gmail.com> wrote:
>> >>
>> >> > * Nobody knows how it works. It's unsupported
>> >> It is supported and documented:
>> https://lucene.apache.org/solr/guide/8_6/managed-resources.html
>> >>
>> >> > * RESTlet dependency
>> >> > * Cannot be secured using standard permissions
>> >> > * It's extremely complex for the functionality it offers.
>> >>
>> >> I agree. Whatever alternative we build should address these, before we
>> consider removing managed resources.
>> >>
>> >> On Wed, Sep 30, 2020 at 2:52 PM Ishan Chattopadhyaya <
>> ichattopadhy...@gmail.com> wrote:
>> >>>
>> >>> The managed resources is the only reasonable way to upload synonyms
>> on the fly for users today. A single file configset upload would require
>> the user to reload the collection, so it isn't better than managed
>> resources. I would not recommend we remove the functionality without first
>> building a suitable alternative. I agree that the feature isn't built using
>> proper framework or proper APIs, but it is a feature that works well.
>> >>>
>> >>> Usually, I support throwing features out even without existence of an
>> alternative, but I do that for non essential features. In my mind, ability
>> to manage synonyms elegantly is an essential feature for a search engine.
>> >>>
>> >>> On Wed, 30 Sep, 2020, 2:44 pm Uwe Schindler,  wrote:
>> 
>>  Please don't do this.
>> 
>>  In short: remove restlet stuff from master. Pull requests on master
>> are executed with Gradle on GitHub hardware.
>> 
>>  Ivy stuff in 8.x is built in more or less persistent servers and
>> there is no issue.
>> 
>>  What's the problem?
>> 
>>  Uwe
>> 
>>  Am September 30, 2020 8:59:06 AM UTC schrieb Ishan Chattopadhyaya <
>> ichattopadhy...@gmail.com>:
>> >
>> > Can we discuss this with ASF and get an exception for this?
>> >
>> > On Wed, 30 Sep, 2020, 11:57 am Dawid Weiss, 
>> wrote:
>> >>
>> >> We can't have or redistribute binaries in ASL sources - that's my
>> understanding.
>> >>
>> >> Dawid
>> >>
>> >> On Tue, Sep 29, 2020 at 10:02 PM Ishan Chattopadhyaya
>> >>  wrote:
>> >> >
>> >> > Can we pull in the jar inside our codebase?
>> >> >
>> >> > On Wed, 30 Sep, 2020, 1:19 am Dawid Weiss, <
>> dawid.we...@gmail.com> wrote:
>> >> >>
>> >> >>
>> >> >> We can upgrade if it doesn't break anything... which I can't
>> guarantee. ;)
>> >> >>
>> >> >> Dawid
>> >>
>> >>
>> 

Re: restlet dependencies

[Timothy Potter]

ote:
>>>>>>
>>>>>> > Hmmm; seems the configSet API doesn't have an API to update a
>>>>>> single file!  I wonder if uploading a configSet to the same name
>>>>>> effectively overwrites newly updated files but does not delete the 
>>>>>> existing
>>>>>> files?
>>>>>> I've been working on this recently. As of 8.7, the UPLOAD command
>>>>>> supports overwriting (before, an UPLOAD on an existing configset name 
>>>>>> would
>>>>>> fail with BAD_REQUEST) and you can choose to cleanup or not the extra 
>>>>>> files
>>>>>> with the "cleanup" parameter.
>>>>>> You could upload a single file if you say
>>>>>> overwrite=true=false, but it would still need to be in a zip file
>>>>>> (and needs to be located in the right path of the zip, for example, a
>>>>>> synonyms file may be in lang/synonyms_foo.txt or something)
>>>>>>
>>>>>> On Wed, Sep 23, 2020 at 8:10 PM David Smiley 
>>>>>> wrote:
>>>>>>
>>>>>>> +1 to deprecate managed resources in lieu of easier to maintain (and
>>>>>>> more flexible) file based GET/PUT into the configset.
>>>>>>>
>>>>>>> > I don't know if 9 is too soon from a deprecation stand point
>>>>>>>
>>>>>>> IMO it's never too soon as long as there is a deprecated release.
>>>>>>> Users take their time upgrading to major versions.
>>>>>>>
>>>>>>> > How much harder are the use-cases currently covered by managed
>>>>>>> resources, if that module was removed?
>>>>>>>
>>>>>>> I believe in practice, users synchronize one-way from their DB to
>>>>>>> Solr if they have dynamic resources like this.  This is true where I 
>>>>>>> work.
>>>>>>> Otherwise, they would probably be using Solr as the source of truth, 
>>>>>>> which
>>>>>>> doesn't seem architecturally-sound for most apps IMO.  Those users
>>>>>>> (hopefully few) would have to spend some time re-engineering the 
>>>>>>> approach.
>>>>>>> Given one-way sync, the transition here is pretty easy:  serialize the
>>>>>>> client-managed data to the right Solr format (stopwords vs synonyms vs 
>>>>>>> ...)
>>>>>>> and then a file upload to Solr/ZK and then telling Solr which 
>>>>>>> collections
>>>>>>> to "reload".
>>>>>>>
>>>>>>> Hmmm; seems the configSet API doesn't have an API to update a single
>>>>>>> file!  I wonder if uploading a configSet to the same name effectively
>>>>>>> overwrites newly updated files but does not delete the existing files?
>>>>>>>
>>>>>>> ~ David Smiley
>>>>>>> Apache Lucene/Solr Search Developer
>>>>>>> http://www.linkedin.com/in/davidwsmiley
>>>>>>>
>>>>>>>
>>>>>>> On Wed, Sep 23, 2020 at 10:28 AM Timothy Potter <
>>>>>>> thelabd...@gmail.com> wrote:
>>>>>>>
>>>>>>>> I agree we should deprecate the managed resources feature, it was
>>>>>>>> the first thing I was asked to build by LW nearly 7 years ago, before 
>>>>>>>> I was
>>>>>>>> a committer. Restlet was already in place and I built on top of that, 
>>>>>>>> not
>>>>>>>> sure who introduced it originally (nor do I care). Clearly from the 
>>>>>>>> vantage
>>>>>>>> point of looking back, JAX-RS and Jersey won the day with REST in Java 
>>>>>>>> but
>>>>>>>> that simply wasn't the case back then. What's important is how we move
>>>>>>>> forward vs. bestowing judgement backed by wisdom of hindsight on 
>>>>>>>> decisions
>>>>>>>> made many years ago.
>>>>>>>>
>>>>>>>> In the short term, does Apache have an Artifactory (or similar)
>>>>>>>> where we can host the Restlet dependencies for Github to pull

Re: restlet dependencies

[Timothy Potter]

Even better! I still favor removing it in 9 but if not, this sounds like a
good approach

On Wed, Sep 23, 2020 at 8:54 AM Ishan Chattopadhyaya <
ichattopadhy...@gmail.com> wrote:

> We don't need Jersey either. It is already possible for Solr to accept
> arbitrarily nested paths for endpoints (using annotations) without using
> Restlet or Jersey.
>
> On Wed, 23 Sep, 2020, 8:16 pm Alexandre Rafalovitch, 
> wrote:
>
>> How much harder are the use-cases currently covered by managed
>> resources, if that module was removed?
>>
>> For standalone instances, it is nearly as easy to edit the file and
>> reload the schema. And it will probably be more version-control
>> friendly than the files currently saved by the module.
>> What about for SolrCloud?
>>
>> My feeling is that this module did not catch on, I don't think anybody
>> ever implemented additional managed resources, though I remember
>> seeing Jiras. So, unless there are super-special use cases, I am +1 on
>> deprecating it ASAP for 8.7 and removing it in 9. It will fit with the
>> overall theme of getting slimmer and more consistent.
>>
>> Regards,
>>Alex.
>> P.s. Also, I think the question on SolrUsers about this had limited
>> response and mentioned a security issue.
>>
>>
>> On Wed, 23 Sep 2020 at 10:28, Timothy Potter 
>> wrote:
>> >
>> > I agree we should deprecate the managed resources feature, it was the
>> first thing I was asked to build by LW nearly 7 years ago, before I was a
>> committer. Restlet was already in place and I built on top of that, not
>> sure who introduced it originally (nor do I care). Clearly from the vantage
>> point of looking back, JAX-RS and Jersey won the day with REST in Java but
>> that simply wasn't the case back then. What's important is how we move
>> forward vs. bestowing judgement backed by wisdom of hindsight on decisions
>> made many years ago.
>> >
>> > In the short term, does Apache have an Artifactory (or similar) where
>> we can host the Restlet dependencies for Github to pull them from? If not,
>> then we can port the code that's using Restlet over to using JAX-RS /
>> Jersey. Personally I'd prefer we remove Managed Resources support from 9
>> instead of porting the Restlet code but I don't know if 9 is too soon from
>> a deprecation stand point?
>> >
>> > Tim
>> >
>> >
>> > On Mon, Sep 21, 2020 at 11:33 PM Noble Paul 
>> wrote:
>> >>
>> >> We should deprecate that feature and remove restlet dependency
>> altogether
>> >>
>> >> On Mon, Sep 21, 2020 at 10:20 PM Joel Bernstein 
>> wrote:
>> >> >
>> >> > Restlet again!!!
>> >> >
>> >> >
>> >> >
>> >> > Joel Bernstein
>> >> > http://joelsolr.blogspot.com/
>> >> >
>> >> >
>> >> > On Mon, Sep 21, 2020 at 7:18 AM Eric Pugh <
>> ep...@opensourceconnections.com> wrote:
>> >> >>
>> >> >> Do we have a community blessed alternative to restlet already?
>> >> >>
>> >> >> On Sep 20, 2020, at 9:40 AM, Noble Paul 
>> wrote:
>> >> >>
>> >> >> Haha.
>> >> >>
>> >> >> In fact schema APIs don't use restlet. Only the managed resources
>> use it
>> >> >>
>> >> >> On Sat, Sep 19, 2020, 3:35 PM Ishan Chattopadhyaya <
>> ichattopadhy...@gmail.com> wrote:
>> >> >>>
>> >> >>> If I were talend, I'd immediately start publishing to maven
>> central. If I were the developer who built the schema APIs, I would never
>> have used restlet to begin with.
>> >> >>>
>> >> >>> On Sat, 19 Sep, 2020, 1:13 am Uwe Schindler, 
>> wrote:
>> >> >>>>
>> >> >>>> I was thinking the same. Because GitHub does not cache the
>> downloaded artifacts like our jenkins servers.
>> >> >>>>
>> >> >>>> It seems to run it in a new VM or container every time, so it
>> downloads all artifacts. If I were Talend, I'd also block this.
>> >> >>>>
>> >> >>>> Uwe
>> >> >>>>
>> >> >>>> Am September 18, 2020 7:32:47 PM UTC schrieb Dawid Weiss <
>> dawid.we...@gmail.com>:
>> >> >>>>>
>> >> >>>>> I don't think it's

Re: restlet dependencies

[Timothy Potter]

I agree we should deprecate the managed resources feature, it was the first
thing I was asked to build by LW nearly 7 years ago, before I was a
committer. Restlet was already in place and I built on top of that, not
sure who introduced it originally (nor do I care). Clearly from the vantage
point of looking back, JAX-RS and Jersey won the day with REST in Java but
that simply wasn't the case back then. What's important is how we move
forward vs. bestowing judgement backed by wisdom of hindsight on decisions
made many years ago.

In the short term, does Apache have an Artifactory (or similar) where we
can host the Restlet dependencies for Github to pull them from? If not,
then we can port the code that's using Restlet over to using JAX-RS /
Jersey. Personally I'd prefer we remove Managed Resources support from 9
instead of porting the Restlet code but I don't know if 9 is too soon from
a deprecation stand point?

Tim


On Mon, Sep 21, 2020 at 11:33 PM Noble Paul  wrote:

> We should deprecate that feature and remove restlet dependency altogether
>
> On Mon, Sep 21, 2020 at 10:20 PM Joel Bernstein 
> wrote:
> >
> > Restlet again!!!
> >
> >
> >
> > Joel Bernstein
> > http://joelsolr.blogspot.com/
> >
> >
> > On Mon, Sep 21, 2020 at 7:18 AM Eric Pugh <
> ep...@opensourceconnections.com> wrote:
> >>
> >> Do we have a community blessed alternative to restlet already?
> >>
> >> On Sep 20, 2020, at 9:40 AM, Noble Paul  wrote:
> >>
> >> Haha.
> >>
> >> In fact schema APIs don't use restlet. Only the managed resources use it
> >>
> >> On Sat, Sep 19, 2020, 3:35 PM Ishan Chattopadhyaya <
> ichattopadhy...@gmail.com> wrote:
> >>>
> >>> If I were talend, I'd immediately start publishing to maven central.
> If I were the developer who built the schema APIs, I would never have used
> restlet to begin with.
> >>>
> >>> On Sat, 19 Sep, 2020, 1:13 am Uwe Schindler,  wrote:
> 
>  I was thinking the same. Because GitHub does not cache the downloaded
> artifacts like our jenkins servers.
> 
>  It seems to run it in a new VM or container every time, so it
> downloads all artifacts. If I were Talend, I'd also block this.
> 
>  Uwe
> 
>  Am September 18, 2020 7:32:47 PM UTC schrieb Dawid Weiss <
> dawid.we...@gmail.com>:
> >
> > I don't think it's http/https - I believe restlet repository simply
> > bans github servers because of excessive traffic? These URLs work for
> > me locally...
> >
> > Dawid
> >
> > On Fri, Sep 18, 2020 at 6:35 PM Christine Poerschke (BLOOMBERG/
> > LONDON)  wrote:
> >>
> >>
> >>  This sounds vaguely familiar. "http works, https does not work"
> and https://issues.apache.org/jira/browse/SOLR-13756 possibly related?
> >>
> >>  From: dev@lucene.apache.org At: 09/18/20 10:01:29
> >>  To: dev@lucene.apache.org
> >>  Subject: Re: restlet dependencies
> >>
> >>  I don't think it is, sadly.
> >>  https://repo1.maven.org/maven2/org/restlet
> >>
> >>  The link you provided (mvnrepository) aggregates from several maven
> >>  repositories.
> >>
> >>
> >>  D.
> >>
> >>  On Fri, Sep 18, 2020 at 10:46 AM Ishan Chattopadhyaya
> >>   wrote:
> >>>
> >>>
> >>>  Sorry, afk, but I heard (*hearsay*) that restlet is also on maven
> central
> >>
> >> these days. Can we confirm and switch to that? Sorry, if that's not
> the case.
> >>>
> >>>
> >>>  On Fri, 18 Sep, 2020, 1:15 pm Dawid Weiss, 
> wrote:
> 
> 
>   Just FYI: can't get PR builds on github to work recently because
> of this:
> 
> > Could not resolve all files for configuration
> >>
> >> ':solr:core:compileClasspath'.
> 
>   350 > Could not download org.restlet.ext.servlet-2.4.3.jar
>   (org.restlet.jee:org.restlet.ext.servlet:2.4.3)
>   351 > Could not get resource
> 
> >> '
> https://maven.restlet.com/org/restlet/jee/org.restlet.ext.servlet/2.4.3/org.res
> >> tlet.ext.servlet-2.4.3.jar'.
> 
>   352 > Could not GET
> 
> >> '
> https://maven.restlet.com/org/restlet/jee/org.restlet.ext.servlet/2.4.3/org.res
> >> tlet.ext.servlet-2.4.3.jar'.
> 
>   353 > Connection reset
>   354 > Could not download org.restlet-2.4.3.jar
>   (org.restlet.jee:org.restlet:2.4.3)
>   355 > Could not get resource
> 
> >> '
> https://maven.restlet.com/org/restlet/jee/org.restlet/2.4.3/org.restlet-2.4.3.j
> >> ar'.
> 
>   356 > Could not GET
> 
> >> '
> https://maven.restlet.talend.com/org/restlet/jee/org.restlet/2.4.3/org.restlet-
> >> 2.4.3.jar'.
> 
>   357 > Connection reset
> 
>   D.
>  
>   To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>   For additional commands, e-mail: dev-h...@lucene.apache.org
> 

Re: Migrate Solr helm chart into apache/lucene-solr repo

[Timothy Potter]

Agree with Jan ... the solr-operator is the way we should recommend
deploying Solr in Kubernetes vs. using Helm.

On Fri, Sep 4, 2020 at 5:45 AM Jan Høydahl  wrote:

> Yea, ComDev is probably a place to discuss whether ASF wants to host some
> helm repo.
>
> We are discussing how to incubate solr-operator into ASF, and since
> operators are a superior way to manage a complex stateful k8s application,
> I’m not sure what benefit there would be for the project to also maintain a
> Helm chart?
>
> So +1 for 3rd party github repo, managed by those who rely on it already,
> and perhaps mentioned in Solr RefGuide or Website. If none of the existing
> Solr-helm users are willing to step up and maintain the chart, then I
> cannot see how it would thive any better inside this project.
>
> Jan
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

Re: [VOTE] Release Lucene/Solr 8.6.2 RC1

[Timothy Potter]

+1  (binding)

SUCCESS! [1:07:47.265949]

On Thu, Aug 27, 2020 at 7:11 AM Michael Sokolov  wrote:

> SUCCESS! [0:56:28.589654]
>
> +1
>
> On Wed, Aug 26, 2020 at 12:41 PM Nhat Nguyen
>  wrote:
> >
> > +1
> >
> > SUCCESS! [0:52:44.607871]
> >
> > On Wed, Aug 26, 2020 at 12:12 PM Tomoko Uchida <
> tomoko.uchida.1...@gmail.com> wrote:
> >>
> >> +1 (non-binding)
> >> SUCCESS! [0:51:55.207272]
> >>
> >>
> >> 2020年8月26日(水) 22:42 Ignacio Vera :
> >>>
> >>> Please vote for release candidate 1 for Lucene/Solr 8.6.2
> >>>
> >>>
> >>> The artifacts can be downloaded from:
> >>>
> >>>
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.6.2-RC1-rev016993b65e393b58246d54e8ddda9f56a453eb0e
> >>>
> >>>
> >>> You can run the smoke tester directly with this command:
> >>>
> >>>
> >>> python3 -u dev-tools/scripts/smokeTestRelease.py \
> >>>
> >>>
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.6.2-RC1-rev016993b65e393b58246d54e8ddda9f56a453eb0e
> >>>
> >>>
> >>> The vote will be open for at least 72 hours i.e. until 2020-08-29
> 15:00 UTC.
> >>>
> >>>
> >>> [ ] +1  approve
> >>>
> >>> [ ] +0  no opinion
> >>>
> >>> [ ] -1  disapprove (and reason why)
> >>>
> >>>
> >>> Here is my +1
> >>>
> >>>
> >>> SUCCESS! [1:14:00.656250]
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

Re: [VOTE] Release Lucene/Solr 8.6.1 RC2

[Timothy Potter]

Thanks Houston.

SUCCESS! [1:34:35.219332]

+1

On Mon, Aug 10, 2020 at 1:02 PM Houston Putman 
wrote:

> Please vote for release candidate 2 for Lucene/Solr 8.6.1
>
> The artifacts can be downloaded from:
>
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.6.1-RC2-rev6e11a1c3f0599f1c918bc69c4f51928d23160e99
>
> You can run the smoke tester directly with this command:
>
> python3 -u dev-tools/scripts/smokeTestRelease.py \
>
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.6.1-RC2-rev6e11a1c3f0599f1c918bc69c4f51928d23160e99
>
> The vote will be open for at least 72 hours i.e. until 2020-08-13 20:00
> UTC.
>
> [ ] +1  approve
> [ ] +0  no opinion
> [ ] -1  disapprove (and reason why)
>
> Here is my +1
>

Re: Welcome Mike Drob to the PMC

[Timothy Potter]

Welcome Mike :-)

On Fri, Jul 24, 2020 at 2:56 PM Erick Erickson 
wrote:

> Welcome Mike!
>
> > On Jul 24, 2020, at 4:12 PM, Ilan Ginzburg  wrote:
> >
> > Congratulations Mike, happy to hear that!
> >
> > Ilan
> >
> > On Fri, Jul 24, 2020 at 9:56 PM Anshum Gupta 
> wrote:
> > I am pleased to announce that Mike Drob has accepted the PMC's
> invitation to join.
> >
> > Congratulations and welcome, Mike!
> >
> > --
> > Anshum Gupta
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

[jira] [Created] (SOLR-12657) Facet streaming expression doesn't support min / max correctly for date fields.

[Timothy Potter (JIRA)]

Timothy Potter created SOLR-12657:
-

 Summary: Facet streaming expression doesn't support min / max 
correctly for date fields.
 Key: SOLR-12657
 URL: https://issues.apache.org/jira/browse/SOLR-12657
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
  Components: streaming expressions
Affects Versions: 7.4
Reporter: Timothy Potter
Assignee: Timothy Potter
 Fix For: 7.4.1


Using this streaming expression to compute a min / max timestamp for each 
movie_id in my ratings collection (movielens),

{code}

facet(ratings,
 q="movie_id:[* TO *]",
 buckets="movie_id",
 bucketSizeLimit=1254,
 bucketSorts="movie_id asc", count(*),
 min(rating_timestamp),
 max(rating_timestamp)
)

{code}

I get the following errors:

{code}

2018-08-10T17:48:58,293 - INFO [qtp726950788-385:solr.core.SolrCore@2544] - 
\{collection=c:ratings, core=x:ratings_shard1_replica_n1, 
node_name=n:192.168.1.6:8983_solr, replica=r:core_node2, shard=s:shard1} - 
[ratings_shard1_replica_n1] webapp=/solr path=/stream 
params=\{expr=facet(ratings,%0a++q%3D"movie_id:[*+TO+*]",%0a++buckets%3D"movie_id",%0a++bucketSizeLimit%3D1254,%0a++bucketSorts%3D"movie_id+asc",+count(*),%0a++min(rating_timestamp),%0a++max(rating_timestamp)%0a)&_=1533923249300}
 status=0 QTime=0
2018-08-10T17:48:58,313 - INFO [qtp726950788-17:solr.core.SolrCore@2544] - 
\{collection=c:ratings, core=x:ratings_shard1_replica_n1, 
node_name=n:192.168.1.6:8983_solr, replica=r:core_node2, shard=s:shard1} - 
[ratings_shard1_replica_n1] webapp=/solr path=/select 
params=\{q=movie_id:[*+TO+*]={"movie_id":{"type":"terms","field":"movie_id","limit":1254,"sort":{"index":"asc"},"facet":\{"facet_0":"min(rating_timestamp)","facet_1":"max(rating_timestamp)"}}}&_stateVer_=ratings:4=1254=0=javabin=2}
 hits=10 status=0 QTime=17
2018-08-10T17:48:58,316 - ERROR 
[qtp726950788-385:solr.common.SolrException@148] - \{collection=c:ratings, 
core=x:ratings_shard1_replica_n1, node_name=n:192.168.1.6:8983_solr, 
replica=r:core_node2, shard=s:shard1} - java.io.IOException: 
java.lang.ClassCastException: java.util.Date cannot be cast to java.lang.Number
 at 
org.apache.solr.client.solrj.io.stream.FacetStream.open(FacetStream.java:346)
 at 
org.apache.solr.client.solrj.io.stream.ExceptionStream.open(ExceptionStream.java:54)
 at 
org.apache.solr.handler.StreamHandler$TimerStream.open(StreamHandler.java:397)
 at 
org.apache.solr.client.solrj.io.stream.TupleStream.writeMap(TupleStream.java:83)
 at org.apache.solr.response.JSONWriter.writeMap(JSONResponseWriter.java:539)
 at 
org.apache.solr.response.TextResponseWriter.writeVal(TextResponseWriter.java:181)
 at 
org.apache.solr.response.JSONWriter.writeNamedListAsMapWithDups(JSONResponseWriter.java:209)
 at 
org.apache.solr.response.JSONWriter.writeNamedList(JSONResponseWriter.java:325)
 at 
org.apache.solr.response.JSONWriter.writeResponse(JSONResponseWriter.java:120)
 at 
org.apache.solr.response.JSONResponseWriter.write(JSONResponseWriter.java:71)
 at 
org.apache.solr.response.QueryResponseWriterUtil.writeQueryResponse(QueryResponseWriterUtil.java:65)
 at org.apache.solr.servlet.HttpSolrCall.writeResponse(HttpSolrCall.java:787)
 at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:524)
 at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:377)
 at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:323)
 at 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1668)
 at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:581)
 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:1160)
 at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:511)
 at 
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
 at 
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1092)
 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)

[jira] [Commented] (SOLR-12523) Confusing error reporting if backup attempted on non-shared FS

[Timothy Potter (JIRA)]

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

Timothy Potter commented on SOLR-12523:
---

When I'm working on a cloud platform like EC2 or Google cloud, I don't want to 
deal with NFS when I have cloud storage like S3. I haven't had much luck in the 
past with using the Hdfs directory factory with S3 (I'll checkout SOLR-9952), 
so I figured I would just create the backup using Solr and then move the files 
out to cloud storage using tools optimized for S3. In the past, I think using 
an S3 destination for backup worked OK, but RESTORE took forever (all the check 
summing / sanity checking per file serially vs. concurrently) and given backup 
is usually part of a disaster recovery strategy, I don't want RESTORE taking 
hours to restore my index. If I pull that down from cloud storage to the local 
disks using some tool that's optimized for reading in bulk from S3 
(multi-threaded) and then restore from local, it's much faster. So for me, 
separating the concerns of creating the snapshot for each shard (Solr's job) 
and moving big files out to cloud storage (Solr needs to do much better in this 
regard or punt) is what I'm looking for.

> Confusing error reporting if backup attempted on non-shared FS
> --
>
> Key: SOLR-12523
> URL: https://issues.apache.org/jira/browse/SOLR-12523
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Backup/Restore
>Affects Versions: 7.3.1
>    Reporter: Timothy Potter
>Assignee: Jan Høydahl
>Priority: Minor
> Fix For: master (8.0), 7.5
>
> Attachments: SOLR-12523.patch
>
>
> So I have a large collection with 4 shards across 2 nodes. When I try to back 
> it up with:
> {code}
> curl 
> "http://localhost:8984/solr/admin/collections?action=BACKUP=sigs=foo_signals=5=backups;
> {code}
> I either get:
> {code}
> "5170256188349065":{
>     "responseHeader":{
>       "status":0,
>       "QTime":0},
>     "STATUS":"failed",
>     "Response":"Failed to backup core=foo_signals_shard1_replica_n2 because 
> org.apache.solr.common.SolrException: Directory to contain snapshots doesn't 
> exist: file:///vol1/cloud84/backups/sigs"},
>   "5170256187999044":{
>     "responseHeader":{
>       "status":0,
>       "QTime":0},
>     "STATUS":"failed",
>     "Response":"Failed to backup core=foo_signals_shard3_replica_n10 because 
> org.apache.solr.common.SolrException: Directory to contain snapshots doesn't 
> exist: file:///vol1/cloud84/backups/sigs"},
> {code}
> or if I create the directory, then I get:
> {code}
> {
>   "responseHeader":{
>     "status":0,
>     "QTime":2},
>   "Operation backup caused 
> exception:":"org.apache.solr.common.SolrException:org.apache.solr.common.SolrException:
>  The backup directory already exists: file:///vol1/cloud84/backups/sigs/",
>   "exception":{
>     "msg":"The backup directory already exists: 
> file:///vol1/cloud84/backups/sigs/",
>     "rspCode":400},
>   "status":{
>     "state":"failed",
>     "msg":"found [2] in failed tasks"}}
> {code}
> I'm thinking this has to do with having 2 cores from the same collection on 
> the same node but I can't get a collection with 1 shard on each node to work 
> either:
> {code}
> "ec2-52-90-245-38.compute-1.amazonaws.com:8984_solr":"org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException:Error
>  from server at http://ec2-52-90-245-38.compute-1.amazonaws.com:8984/solr: 
> Failed to backup core=system_jobs_history_shard2_replica_n6 because 
> org.apache.solr.common.SolrException: Directory to contain snapshots doesn't 
> exist: file:///vol1/cloud84/backups/ugh1"}
> {code}
> What's weird is that replica (system_jobs_history_shard2_replica_n6) is not 
> even on the ec2-52-90-245-38.compute-1.amazonaws.com node! It lives on a 
> different node.



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

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

[jira] [Commented] (SOLR-12523) Collection backup fails whether the location + name directory exists or not exists.

[Timothy Potter (JIRA)]

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

Timothy Potter commented on SOLR-12523:
---

Good ideas! I'll try to get the S3AFileSystem working again ... I forget what 
all the issues are with that besides 9958, then we can iterate from there.

> Collection backup fails whether the location + name directory exists or not 
> exists.
> ---
>
> Key: SOLR-12523
> URL: https://issues.apache.org/jira/browse/SOLR-12523
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Backup/Restore
>Affects Versions: 7.3.1
>Reporter: Timothy Potter
>Priority: Minor
>
> So I have a large collection with 4 shards across 2 nodes. When I try to back 
> it up with:
> {code}
> curl 
> "http://localhost:8984/solr/admin/collections?action=BACKUP=sigs=foo_signals=5=backups;
> {code}
> I either get:
> {code}
> "5170256188349065":{
>     "responseHeader":{
>       "status":0,
>       "QTime":0},
>     "STATUS":"failed",
>     "Response":"Failed to backup core=foo_signals_shard1_replica_n2 because 
> org.apache.solr.common.SolrException: Directory to contain snapshots doesn't 
> exist: file:///vol1/cloud84/backups/sigs"},
>   "5170256187999044":{
>     "responseHeader":{
>       "status":0,
>       "QTime":0},
>     "STATUS":"failed",
>     "Response":"Failed to backup core=foo_signals_shard3_replica_n10 because 
> org.apache.solr.common.SolrException: Directory to contain snapshots doesn't 
> exist: file:///vol1/cloud84/backups/sigs"},
> {code}
> or if I create the directory, then I get:
> {code}
> {
>   "responseHeader":{
>     "status":0,
>     "QTime":2},
>   "Operation backup caused 
> exception:":"org.apache.solr.common.SolrException:org.apache.solr.common.SolrException:
>  The backup directory already exists: file:///vol1/cloud84/backups/sigs/",
>   "exception":{
>     "msg":"The backup directory already exists: 
> file:///vol1/cloud84/backups/sigs/",
>     "rspCode":400},
>   "status":{
>     "state":"failed",
>     "msg":"found [2] in failed tasks"}}
> {code}
> I'm thinking this has to do with having 2 cores from the same collection on 
> the same node but I can't get a collection with 1 shard on each node to work 
> either:
> {code}
> "ec2-52-90-245-38.compute-1.amazonaws.com:8984_solr":"org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException:Error
>  from server at http://ec2-52-90-245-38.compute-1.amazonaws.com:8984/solr: 
> Failed to backup core=system_jobs_history_shard2_replica_n6 because 
> org.apache.solr.common.SolrException: Directory to contain snapshots doesn't 
> exist: file:///vol1/cloud84/backups/ugh1"}
> {code}
> What's weird is that replica (system_jobs_history_shard2_replica_n6) is not 
> even on the ec2-52-90-245-38.compute-1.amazonaws.com node! It lives on a 
> different node.



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

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

[jira] [Updated] (SOLR-12523) Collection backup fails whether the location + name directory exists or not exists.

[Timothy Potter (JIRA)]

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

Timothy Potter updated SOLR-12523:
--
Priority: Minor  (was: Major)

> Collection backup fails whether the location + name directory exists or not 
> exists.
> ---
>
> Key: SOLR-12523
> URL: https://issues.apache.org/jira/browse/SOLR-12523
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Backup/Restore
>Affects Versions: 7.3.1
>Reporter: Timothy Potter
>Priority: Minor
>
> So I have a large collection with 4 shards across 2 nodes. When I try to back 
> it up with:
> {code}
> curl 
> "http://localhost:8984/solr/admin/collections?action=BACKUP=sigs=foo_signals=5=backups;
> {code}
> I either get:
> {code}
> "5170256188349065":{
>     "responseHeader":{
>       "status":0,
>       "QTime":0},
>     "STATUS":"failed",
>     "Response":"Failed to backup core=foo_signals_shard1_replica_n2 because 
> org.apache.solr.common.SolrException: Directory to contain snapshots doesn't 
> exist: file:///vol1/cloud84/backups/sigs"},
>   "5170256187999044":{
>     "responseHeader":{
>       "status":0,
>       "QTime":0},
>     "STATUS":"failed",
>     "Response":"Failed to backup core=foo_signals_shard3_replica_n10 because 
> org.apache.solr.common.SolrException: Directory to contain snapshots doesn't 
> exist: file:///vol1/cloud84/backups/sigs"},
> {code}
> or if I create the directory, then I get:
> {code}
> {
>   "responseHeader":{
>     "status":0,
>     "QTime":2},
>   "Operation backup caused 
> exception:":"org.apache.solr.common.SolrException:org.apache.solr.common.SolrException:
>  The backup directory already exists: file:///vol1/cloud84/backups/sigs/",
>   "exception":{
>     "msg":"The backup directory already exists: 
> file:///vol1/cloud84/backups/sigs/",
>     "rspCode":400},
>   "status":{
>     "state":"failed",
>     "msg":"found [2] in failed tasks"}}
> {code}
> I'm thinking this has to do with having 2 cores from the same collection on 
> the same node but I can't get a collection with 1 shard on each node to work 
> either:
> {code}
> "ec2-52-90-245-38.compute-1.amazonaws.com:8984_solr":"org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException:Error
>  from server at http://ec2-52-90-245-38.compute-1.amazonaws.com:8984/solr: 
> Failed to backup core=system_jobs_history_shard2_replica_n6 because 
> org.apache.solr.common.SolrException: Directory to contain snapshots doesn't 
> exist: file:///vol1/cloud84/backups/ugh1"}
> {code}
> What's weird is that replica (system_jobs_history_shard2_replica_n6) is not 
> even on the ec2-52-90-245-38.compute-1.amazonaws.com node! It lives on a 
> different node.



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

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

[jira] [Comment Edited] (SOLR-12523) Collection backup fails whether the location + name directory exists or not exists.

[Timothy Potter (JIRA)]

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

Timothy Potter edited comment on SOLR-12523 at 6/27/18 9:33 PM:


why does it need a shared filesystem? that's very uncloud like ... I'd use S3 
but it's too slow to move these files one-by-one to S3 and SOLR-9958 prevents 
that from working correctly anyway ... but I've moved on and am just using 
BACKUPCORE and then using a bulk copy solution to move the files to cloud 
storage

 


was (Author: thelabdude):
why does it need a shared filesystem? that's very uncloud like ... I'd use S3 
but it's too slow to move these files one-by-one to S3 and SOLR-9958 prevents 
that from working correctly anyway

 

> Collection backup fails whether the location + name directory exists or not 
> exists.
> ---
>
> Key: SOLR-12523
> URL: https://issues.apache.org/jira/browse/SOLR-12523
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Backup/Restore
>Affects Versions: 7.3.1
>Reporter: Timothy Potter
>Priority: Major
>
> So I have a large collection with 4 shards across 2 nodes. When I try to back 
> it up with:
> {code}
> curl 
> "http://localhost:8984/solr/admin/collections?action=BACKUP=sigs=foo_signals=5=backups;
> {code}
> I either get:
> {code}
> "5170256188349065":{
>     "responseHeader":{
>       "status":0,
>       "QTime":0},
>     "STATUS":"failed",
>     "Response":"Failed to backup core=foo_signals_shard1_replica_n2 because 
> org.apache.solr.common.SolrException: Directory to contain snapshots doesn't 
> exist: file:///vol1/cloud84/backups/sigs"},
>   "5170256187999044":{
>     "responseHeader":{
>       "status":0,
>       "QTime":0},
>     "STATUS":"failed",
>     "Response":"Failed to backup core=foo_signals_shard3_replica_n10 because 
> org.apache.solr.common.SolrException: Directory to contain snapshots doesn't 
> exist: file:///vol1/cloud84/backups/sigs"},
> {code}
> or if I create the directory, then I get:
> {code}
> {
>   "responseHeader":{
>     "status":0,
>     "QTime":2},
>   "Operation backup caused 
> exception:":"org.apache.solr.common.SolrException:org.apache.solr.common.SolrException:
>  The backup directory already exists: file:///vol1/cloud84/backups/sigs/",
>   "exception":{
>     "msg":"The backup directory already exists: 
> file:///vol1/cloud84/backups/sigs/",
>     "rspCode":400},
>   "status":{
>     "state":"failed",
>     "msg":"found [2] in failed tasks"}}
> {code}
> I'm thinking this has to do with having 2 cores from the same collection on 
> the same node but I can't get a collection with 1 shard on each node to work 
> either:
> {code}
> "ec2-52-90-245-38.compute-1.amazonaws.com:8984_solr":"org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException:Error
>  from server at http://ec2-52-90-245-38.compute-1.amazonaws.com:8984/solr: 
> Failed to backup core=system_jobs_history_shard2_replica_n6 because 
> org.apache.solr.common.SolrException: Directory to contain snapshots doesn't 
> exist: file:///vol1/cloud84/backups/ugh1"}
> {code}
> What's weird is that replica (system_jobs_history_shard2_replica_n6) is not 
> even on the ec2-52-90-245-38.compute-1.amazonaws.com node! It lives on a 
> different node.



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

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

[jira] [Commented] (SOLR-12523) Collection backup fails whether the location + name directory exists or not exists.

[Timothy Potter (JIRA)]

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

Timothy Potter commented on SOLR-12523:
---

why does it need a shared filesystem? that's very uncloud like ... I'd use S3 
but it's too slow to move these files one-by-one to S3 and SOLR-9958 prevents 
that from working correctly anyway

 

> Collection backup fails whether the location + name directory exists or not 
> exists.
> ---
>
> Key: SOLR-12523
> URL: https://issues.apache.org/jira/browse/SOLR-12523
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Backup/Restore
>Affects Versions: 7.3.1
>Reporter: Timothy Potter
>Priority: Major
>
> So I have a large collection with 4 shards across 2 nodes. When I try to back 
> it up with:
> {code}
> curl 
> "http://localhost:8984/solr/admin/collections?action=BACKUP=sigs=foo_signals=5=backups;
> {code}
> I either get:
> {code}
> "5170256188349065":{
>     "responseHeader":{
>       "status":0,
>       "QTime":0},
>     "STATUS":"failed",
>     "Response":"Failed to backup core=foo_signals_shard1_replica_n2 because 
> org.apache.solr.common.SolrException: Directory to contain snapshots doesn't 
> exist: file:///vol1/cloud84/backups/sigs"},
>   "5170256187999044":{
>     "responseHeader":{
>       "status":0,
>       "QTime":0},
>     "STATUS":"failed",
>     "Response":"Failed to backup core=foo_signals_shard3_replica_n10 because 
> org.apache.solr.common.SolrException: Directory to contain snapshots doesn't 
> exist: file:///vol1/cloud84/backups/sigs"},
> {code}
> or if I create the directory, then I get:
> {code}
> {
>   "responseHeader":{
>     "status":0,
>     "QTime":2},
>   "Operation backup caused 
> exception:":"org.apache.solr.common.SolrException:org.apache.solr.common.SolrException:
>  The backup directory already exists: file:///vol1/cloud84/backups/sigs/",
>   "exception":{
>     "msg":"The backup directory already exists: 
> file:///vol1/cloud84/backups/sigs/",
>     "rspCode":400},
>   "status":{
>     "state":"failed",
>     "msg":"found [2] in failed tasks"}}
> {code}
> I'm thinking this has to do with having 2 cores from the same collection on 
> the same node but I can't get a collection with 1 shard on each node to work 
> either:
> {code}
> "ec2-52-90-245-38.compute-1.amazonaws.com:8984_solr":"org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException:Error
>  from server at http://ec2-52-90-245-38.compute-1.amazonaws.com:8984/solr: 
> Failed to backup core=system_jobs_history_shard2_replica_n6 because 
> org.apache.solr.common.SolrException: Directory to contain snapshots doesn't 
> exist: file:///vol1/cloud84/backups/ugh1"}
> {code}
> What's weird is that replica (system_jobs_history_shard2_replica_n6) is not 
> even on the ec2-52-90-245-38.compute-1.amazonaws.com node! It lives on a 
> different node.



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

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

[jira] [Commented] (SOLR-12523) Collection backup fails whether the location + name directory exists or not exists.

[Timothy Potter (JIRA)]

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

Timothy Potter commented on SOLR-12523:
---

so sounds like Solr is expecting a shared location across nodes here?

{code}

SnapShooter snapShooter = new SnapShooter(repository, core, locationUri, name, 
commitName);
// validateCreateSnapshot will create parent dirs instead of throw; that choice 
is dubious.
// But we want to throw. One reason is that
// this dir really should, in fact must, already exist here if triggered via a 
collection backup on a shared
// file system. Otherwise, perhaps the FS location isn't shared -- we want an 
error.
if (!snapShooter.getBackupRepository().exists(snapShooter.getLocation())) {
 throw new SolrException(SolrException.ErrorCode.BAD_REQUEST,
 "Directory to contain snapshots doesn't exist: " + snapShooter.getLocation());
}
snapShooter.validateCreateSnapshot();
snapShooter.createSnapshot();

{code}

> Collection backup fails whether the location + name directory exists or not 
> exists.
> ---
>
> Key: SOLR-12523
> URL: https://issues.apache.org/jira/browse/SOLR-12523
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Backup/Restore
>Affects Versions: 7.3.1
>Reporter: Timothy Potter
>Priority: Major
>
> So I have a large collection with 4 shards across 2 nodes. When I try to back 
> it up with:
> {code}
> curl 
> "http://localhost:8984/solr/admin/collections?action=BACKUP=sigs=foo_signals=5=backups;
> {code}
> I either get:
> {code}
> "5170256188349065":{
>     "responseHeader":{
>       "status":0,
>       "QTime":0},
>     "STATUS":"failed",
>     "Response":"Failed to backup core=foo_signals_shard1_replica_n2 because 
> org.apache.solr.common.SolrException: Directory to contain snapshots doesn't 
> exist: file:///vol1/cloud84/backups/sigs"},
>   "5170256187999044":{
>     "responseHeader":{
>       "status":0,
>       "QTime":0},
>     "STATUS":"failed",
>     "Response":"Failed to backup core=foo_signals_shard3_replica_n10 because 
> org.apache.solr.common.SolrException: Directory to contain snapshots doesn't 
> exist: file:///vol1/cloud84/backups/sigs"},
> {code}
> or if I create the directory, then I get:
> {code}
> {
>   "responseHeader":{
>     "status":0,
>     "QTime":2},
>   "Operation backup caused 
> exception:":"org.apache.solr.common.SolrException:org.apache.solr.common.SolrException:
>  The backup directory already exists: file:///vol1/cloud84/backups/sigs/",
>   "exception":{
>     "msg":"The backup directory already exists: 
> file:///vol1/cloud84/backups/sigs/",
>     "rspCode":400},
>   "status":{
>     "state":"failed",
>     "msg":"found [2] in failed tasks"}}
> {code}
> I'm thinking this has to do with having 2 cores from the same collection on 
> the same node but I can't get a collection with 1 shard on each node to work 
> either:
> {code}
> "ec2-52-90-245-38.compute-1.amazonaws.com:8984_solr":"org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException:Error
>  from server at http://ec2-52-90-245-38.compute-1.amazonaws.com:8984/solr: 
> Failed to backup core=system_jobs_history_shard2_replica_n6 because 
> org.apache.solr.common.SolrException: Directory to contain snapshots doesn't 
> exist: file:///vol1/cloud84/backups/ugh1"}
> {code}
> What's weird is that replica (system_jobs_history_shard2_replica_n6) is not 
> even on the ec2-52-90-245-38.compute-1.amazonaws.com node! It lives on a 
> different node.



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

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

[jira] [Commented] (SOLR-12523) Collection backup fails whether the location + name directory exists or not exists.

[Timothy Potter (JIRA)]

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

Timothy Potter commented on SOLR-12523:
---

some logs:

{code}

2018-06-27 20:36:49.739 INFO  (qtp853119666-19) [   ] 
o.a.s.h.a.CollectionsHandler Invoked Collection Action :backup with params 
name=tim1=BACKUP=/vol1/backups=foo_signals and 
sendToOCPQueue=true

 

2018-06-27 20:36:49.751 ERROR (qtp853119666-18) [   ] 
o.a.s.h.RequestHandlerBase org.apache.solr.common.SolrException: Failed to 
backup core=foo_signals_shard2_replica_n4 because 
org.apache.solr.common.SolrException: Directory to contain snapshots doesn't 
exist: file:///vol1/backups/tim1

 

2018-06-27 20:36:49.751 INFO  (qtp853119666-18) [   ] o.a.s.s.HttpSolrCall 
[admin] webapp=null path=/admin/cores 
params=\{core=foo_signals_shard2_replica_n4=/admin/cores=shard2=BACKUPCORE=file:///vol1/backups/tim1=javabin=2}
 status=500 QTime=1

 

2018-06-27 20:36:49.752 ERROR (qtp853119666-18) [   ] o.a.s.s.HttpSolrCall 
null:org.apache.solr.common.SolrException: Failed to backup 
core=foo_signals_shard2_replica_n4 because 
org.apache.solr.common.SolrException: Directory to contain snapshots doesn't 
exist: file:///vol1/backups/tim1

 

2018-06-27 20:36:49.754 ERROR (qtp853119666-23) [   ] 
o.a.s.h.RequestHandlerBase org.apache.solr.common.SolrException: Failed to 
backup core=foo_signals_shard3_replica_n10 because 
org.apache.solr.common.SolrException: Directory to contain snapshots doesn't 
exist: file:///vol1/backups/tim1

 

2018-06-27 20:36:49.754 INFO  (qtp853119666-23) [   ] o.a.s.s.HttpSolrCall 
[admin] webapp=null path=/admin/cores 
params=\{core=foo_signals_shard3_replica_n10=/admin/cores=shard3=BACKUPCORE=file:///vol1/backups/tim1=javabin=2}
 status=500 QTime=0

 

2018-06-27 20:36:49.754 ERROR (qtp853119666-23) [   ] o.a.s.s.HttpSolrCall 
null:org.apache.solr.common.SolrException: Failed to backup 
core=foo_signals_shard3_replica_n10 because 
org.apache.solr.common.SolrException: Directory to contain snapshots doesn't 
exist: file:///vol1/backups/tim1

 

2018-06-27 20:36:49.781 INFO  (qtp853119666-19) [   ] o.a.s.s.HttpSolrCall 
[admin] webapp=null path=/admin/collections 
params=\{name=tim1=BACKUP=/vol1/backups=foo_signals} 
status=500 QTime=42

{code}

> Collection backup fails whether the location + name directory exists or not 
> exists.
> ---
>
> Key: SOLR-12523
> URL: https://issues.apache.org/jira/browse/SOLR-12523
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Backup/Restore
>Affects Versions: 7.3.1
>Reporter: Timothy Potter
>Priority: Major
>
> So I have a large collection with 4 shards across 2 nodes. When I try to back 
> it up with:
> {code}
> curl 
> "http://localhost:8984/solr/admin/collections?action=BACKUP=sigs=foo_signals=5=backups;
> {code}
> I either get:
> {code}
> "5170256188349065":{
>     "responseHeader":{
>       "status":0,
>       "QTime":0},
>     "STATUS":"failed",
>     "Response":"Failed to backup core=foo_signals_shard1_replica_n2 because 
> org.apache.solr.common.SolrException: Directory to contain snapshots doesn't 
> exist: file:///vol1/cloud84/backups/sigs"},
>   "5170256187999044":{
>     "responseHeader":{
>       "status":0,
>       "QTime":0},
>     "STATUS":"failed",
>     "Response":"Failed to backup core=foo_signals_shard3_replica_n10 because 
> org.apache.solr.common.SolrException: Directory to contain snapshots doesn't 
> exist: file:///vol1/cloud84/backups/sigs"},
> {code}
> or if I create the directory, then I get:
> {code}
> {
>   "responseHeader":{
>     "status":0,
>     "QTime":2},
>   "Operation backup caused 
> exception:":"org.apache.solr.common.SolrException:org.apache.solr.common.SolrException:
>  The backup directory already exists: file:///vol1/cloud84/backups/sigs/",
>   "exception":{
>     "msg":"The backup directory already exists: 
> file:///vol1/cloud84/backups/sigs/",
>     "rspCode":400},
>   "status":{
>     "state":"failed",
>     "msg":"found [2] in failed tasks"}}
> {code}
> I'm thinking this has to do with having 2 cores from the same collection on 
> the same node but I can't get a collection with 1 shard on each node to work 
> either:
> {code

[jira] [Created] (SOLR-12523) Collection backup fails whether the location + name directory exists or not exists.

[Timothy Potter (JIRA)]

Timothy Potter created SOLR-12523:
-

 Summary: Collection backup fails whether the location + name 
directory exists or not exists.
 Key: SOLR-12523
 URL: https://issues.apache.org/jira/browse/SOLR-12523
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
  Components: Backup/Restore
Affects Versions: 7.3.1
Reporter: Timothy Potter


So I have a large collection with 4 shards across 2 nodes. When I try to back 
it up with:

{code}

curl 
"http://localhost:8984/solr/admin/collections?action=BACKUP=sigs=foo_signals=5=backups;

{code}

I either get:

{code}

"5170256188349065":{

    "responseHeader":{

      "status":0,

      "QTime":0},

    "STATUS":"failed",

    "Response":"Failed to backup core=foo_signals_shard1_replica_n2 because 
org.apache.solr.common.SolrException: Directory to contain snapshots doesn't 
exist: file:///vol1/cloud84/backups/sigs"},

  "5170256187999044":{

    "responseHeader":{

      "status":0,

      "QTime":0},

    "STATUS":"failed",

    "Response":"Failed to backup core=foo_signals_shard3_replica_n10 because 
org.apache.solr.common.SolrException: Directory to contain snapshots doesn't 
exist: file:///vol1/cloud84/backups/sigs"},

{code}

or if I create the directory, then I get:

{code}

{

  "responseHeader":{

    "status":0,

    "QTime":2},

  "Operation backup caused 
exception:":"org.apache.solr.common.SolrException:org.apache.solr.common.SolrException:
 The backup directory already exists: file:///vol1/cloud84/backups/sigs/",

  "exception":{

    "msg":"The backup directory already exists: 
file:///vol1/cloud84/backups/sigs/",

    "rspCode":400},

  "status":{

    "state":"failed",

    "msg":"found [2] in failed tasks"}}

{code}

I'm thinking this has to do with having 2 cores from the same collection on the 
same node but I can't get a collection with 1 shard on each node to work either:

{code}

"ec2-52-90-245-38.compute-1.amazonaws.com:8984_solr":"org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException:Error
 from server at http://ec2-52-90-245-38.compute-1.amazonaws.com:8984/solr: 
Failed to backup core=system_jobs_history_shard2_replica_n6 because 
org.apache.solr.common.SolrException: Directory to contain snapshots doesn't 
exist: file:///vol1/cloud84/backups/ugh1"}

{code}

What's weird is that replica (system_jobs_history_shard2_replica_n6) is not 
even on the ec2-52-90-245-38.compute-1.amazonaws.com node! It lives on a 
different node.



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

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

[jira] [Commented] (SOLR-11556) Backup/Restore with multiple BackupRepository objects defined results in the wrong repo being used.

[Timothy Potter (JIRA)]

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

Timothy Potter commented on SOLR-11556:
---

Fix is easy enough, but why not just copy all incoming params into the Map in 
the CollectionsHandler? I don't get the selective copying being done here.

> Backup/Restore with multiple BackupRepository objects defined results in the 
> wrong repo being used.
> ---
>
> Key: SOLR-11556
> URL: https://issues.apache.org/jira/browse/SOLR-11556
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Backup/Restore
>Affects Versions: 6.3
>Reporter: Timothy Potter
>Assignee: Timothy Potter
> Attachments: SOLR-11556.patch
>
>
> I defined two repos for backup/restore, one local and one remote on GCS, e.g.
> {code}
> 
>  class="org.apache.solr.core.backup.repository.HdfsBackupRepository" 
> default="false">
>  ...
> 
>  class="org.apache.solr.core.backup.repository.LocalFileSystemRepository" 
> default="false">
>   /tmp/solr-backups
> 
>  
> {code}
> Since the CollectionHandler does not pass the "repository" param along, once 
> the BackupCmd gets the ZkNodeProps, it selects the wrong repo! 
> The error I'm seeing is:
> {code}
> 2017-10-26 17:07:27.326 ERROR 
> (OverseerThreadFactory-19-thread-1-processing-n:host:8983_solr) [   ] 
> o.a.s.c.OverseerCollectionMessageHandler Collection: product operation: 
> backup failed:java.nio.file.FileSystemNotFoundException: Provider "gs" not 
> installed
> at java.nio.file.Paths.get(Paths.java:147)
> at 
> org.apache.solr.core.backup.repository.LocalFileSystemRepository.resolve(LocalFileSystemRepository.java:82)
> at org.apache.solr.cloud.BackupCmd.call(BackupCmd.java:99)
> at 
> org.apache.solr.cloud.OverseerCollectionMessageHandler.processMessage(OverseerCollectionMessageHandler.java:224)
> at 
> org.apache.solr.cloud.OverseerTaskProcessor$Runner.run(OverseerTaskProcessor.java:463)
> at 
> org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:229)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:748)
> {code}
> Notice the Local backup repo is being selected in the BackupCmd even though I 
> passed repository=hdfs in my backup command, e.g.
> {code}
> curl 
> "http://localhost:8983/solr/admin/collections?action=BACKUP=foo=foo=gs://tjp-solr-test/backups=hdfs;
> {code} 
> I think the fix here is to include the repository param, see patch. I'll fix 
> for the next 7.x release and those on 6 can just apply the patch here.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (SOLR-11556) Backup/Restore with multiple BackupRepository objects defined results in the wrong repo being used.

[Timothy Potter (JIRA)]

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

Timothy Potter updated SOLR-11556:
--
Attachment: SOLR-11556.patch

patch -p1 -i SOLR-11556.patch

> Backup/Restore with multiple BackupRepository objects defined results in the 
> wrong repo being used.
> ---
>
> Key: SOLR-11556
> URL: https://issues.apache.org/jira/browse/SOLR-11556
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Backup/Restore
>Affects Versions: 6.3
>Reporter: Timothy Potter
>Assignee: Timothy Potter
> Attachments: SOLR-11556.patch
>
>
> I defined two repos for backup/restore, one local and one remote on GCS, e.g.
> {code}
> 
>  class="org.apache.solr.core.backup.repository.HdfsBackupRepository" 
> default="false">
>  ...
> 
>  class="org.apache.solr.core.backup.repository.LocalFileSystemRepository" 
> default="false">
>   /tmp/solr-backups
> 
>  
> {code}
> Since the CollectionHandler does not pass the "repository" param along, once 
> the BackupCmd gets the ZkNodeProps, it selects the wrong repo! 
> The error I'm seeing is:
> {code}
> 2017-10-26 17:07:27.326 ERROR 
> (OverseerThreadFactory-19-thread-1-processing-n:host:8983_solr) [   ] 
> o.a.s.c.OverseerCollectionMessageHandler Collection: product operation: 
> backup failed:java.nio.file.FileSystemNotFoundException: Provider "gs" not 
> installed
> at java.nio.file.Paths.get(Paths.java:147)
> at 
> org.apache.solr.core.backup.repository.LocalFileSystemRepository.resolve(LocalFileSystemRepository.java:82)
> at org.apache.solr.cloud.BackupCmd.call(BackupCmd.java:99)
> at 
> org.apache.solr.cloud.OverseerCollectionMessageHandler.processMessage(OverseerCollectionMessageHandler.java:224)
> at 
> org.apache.solr.cloud.OverseerTaskProcessor$Runner.run(OverseerTaskProcessor.java:463)
> at 
> org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:229)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:748)
> {code}
> Notice the Local backup repo is being selected in the BackupCmd even though I 
> passed repository=hdfs in my backup command, e.g.
> {code}
> curl 
> "http://localhost:8983/solr/admin/collections?action=BACKUP=foo=foo=gs://tjp-solr-test/backups=hdfs;
> {code} 
> I think the fix here is to include the repository param, see patch. I'll fix 
> for the next 7.x release and those on 6 can just apply the patch here.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Assigned] (SOLR-11556) Backup/Restore with multiple BackupRepository objects defined results in the wrong repo being used.

[Timothy Potter (JIRA)]

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

Timothy Potter reassigned SOLR-11556:
-

Assignee: Timothy Potter

> Backup/Restore with multiple BackupRepository objects defined results in the 
> wrong repo being used.
> ---
>
> Key: SOLR-11556
> URL: https://issues.apache.org/jira/browse/SOLR-11556
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Backup/Restore
>Affects Versions: 6.3
>Reporter: Timothy Potter
>Assignee: Timothy Potter
>
> I defined two repos for backup/restore, one local and one remote on GCS, e.g.
> {code}
> 
>  class="org.apache.solr.core.backup.repository.HdfsBackupRepository" 
> default="false">
>  ...
> 
>  class="org.apache.solr.core.backup.repository.LocalFileSystemRepository" 
> default="false">
>   /tmp/solr-backups
> 
>  
> {code}
> Since the CollectionHandler does not pass the "repository" param along, once 
> the BackupCmd gets the ZkNodeProps, it selects the wrong repo! 
> The error I'm seeing is:
> {code}
> 2017-10-26 17:07:27.326 ERROR 
> (OverseerThreadFactory-19-thread-1-processing-n:host:8983_solr) [   ] 
> o.a.s.c.OverseerCollectionMessageHandler Collection: product operation: 
> backup failed:java.nio.file.FileSystemNotFoundException: Provider "gs" not 
> installed
> at java.nio.file.Paths.get(Paths.java:147)
> at 
> org.apache.solr.core.backup.repository.LocalFileSystemRepository.resolve(LocalFileSystemRepository.java:82)
> at org.apache.solr.cloud.BackupCmd.call(BackupCmd.java:99)
> at 
> org.apache.solr.cloud.OverseerCollectionMessageHandler.processMessage(OverseerCollectionMessageHandler.java:224)
> at 
> org.apache.solr.cloud.OverseerTaskProcessor$Runner.run(OverseerTaskProcessor.java:463)
> at 
> org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:229)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:748)
> {code}
> Notice the Local backup repo is being selected in the BackupCmd even though I 
> passed repository=hdfs in my backup command, e.g.
> {code}
> curl 
> "http://localhost:8983/solr/admin/collections?action=BACKUP=foo=foo=gs://tjp-solr-test/backups=hdfs;
> {code} 
> I think the fix here is to include the repository param, see patch. I'll fix 
> for the next 7.x release and those on 6 can just apply the patch here.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Created] (SOLR-11556) Backup/Restore with multiple BackupRepository objects defined results in the wrong repo being used.

[Timothy Potter (JIRA)]

Timothy Potter created SOLR-11556:
-

 Summary: Backup/Restore with multiple BackupRepository objects 
defined results in the wrong repo being used.
 Key: SOLR-11556
 URL: https://issues.apache.org/jira/browse/SOLR-11556
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
  Components: Backup/Restore
Affects Versions: 6.3
Reporter: Timothy Potter


I defined two repos for backup/restore, one local and one remote on GCS, e.g.
{code}


 ...


  /tmp/solr-backups

 
{code}
Since the CollectionHandler does not pass the "repository" param along, once 
the BackupCmd gets the ZkNodeProps, it selects the wrong repo! 

The error I'm seeing is:
{code}
2017-10-26 17:07:27.326 ERROR 
(OverseerThreadFactory-19-thread-1-processing-n:host:8983_solr) [   ] 
o.a.s.c.OverseerCollectionMessageHandler Collection: product operation: backup 
failed:java.nio.file.FileSystemNotFoundException: Provider "gs" not installed
at java.nio.file.Paths.get(Paths.java:147)
at 
org.apache.solr.core.backup.repository.LocalFileSystemRepository.resolve(LocalFileSystemRepository.java:82)
at org.apache.solr.cloud.BackupCmd.call(BackupCmd.java:99)
at 
org.apache.solr.cloud.OverseerCollectionMessageHandler.processMessage(OverseerCollectionMessageHandler.java:224)
at 
org.apache.solr.cloud.OverseerTaskProcessor$Runner.run(OverseerTaskProcessor.java:463)
at 
org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:229)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:748)
{code}
Notice the Local backup repo is being selected in the BackupCmd even though I 
passed repository=hdfs in my backup command, e.g.
{code}
curl 
"http://localhost:8983/solr/admin/collections?action=BACKUP=foo=foo=gs://tjp-solr-test/backups=hdfs;
{code} 
I think the fix here is to include the repository param, see patch. I'll fix 
for the next 7.x release and those on 6 can just apply the patch here.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-11473) Make HDFSDirectoryFactory support other prefixes (besides hdfs:/)

[Timothy Potter (JIRA)]

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

Timothy Potter commented on SOLR-11473:
---

I didn't try auto-add replica feature with Alluxio yet. For the update log, I 
worked around the issue by setting the fully qualified classname on the 
 element in the config, e.g.  
... but that doesn't address the dataDir issue.

> Make HDFSDirectoryFactory support other prefixes (besides hdfs:/)
> -
>
> Key: SOLR-11473
> URL: https://issues.apache.org/jira/browse/SOLR-11473
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: hdfs
>Affects Versions: 6.6.1
>Reporter: Radu Gheorghe
>Priority: Minor
>
> Not sure if it's a bug or a missing feature :) I'm trying to make Solr work 
> on Alluxio, as described by [~thelabdude] in 
> https://www.slideshare.net/thelabdude/running-solr-in-the-cloud-at-memory-speed-with-alluxio/1
> The problem I'm facing here is with autoAddReplicas. If I have 
> replicationFactor=1 and the node with that replica dies, the node taking over 
> incorrectly assigns the data directory. For example:
> before
> {code}"dataDir":"alluxio://localhost:19998/solr/test/",{code}
> after
> {code}"dataDir":"alluxio://localhost:19998/solr/test/core_node1/alluxio://localhost:19998/solr/test/",{code}
> The same happens for ulogDir. Apparently, this has to do with this bit from 
> HDFSDirectoryFactory:
> {code}  public boolean isAbsolute(String path) {
> return path.startsWith("hdfs:/");
>   }{code}
> If I add "alluxio:/" in there, the paths are correct and the index is 
> recovered.
> I see a few options here:
> * add "alluxio:/" to the list there
> * add a regular expression in the lines of \[a-z]*:/ I hope that's not too 
> expensive, I'm not sure how often this method is called
> * don't do anything and expect alluxio to work with an "hdfs:/" path? I 
> actually tried that and didn't manage to make it work
> * have a different DirectoryFactory or something else?
> What do you think?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

Re: [VOTE] Release Apache Lucene/Solr 7.0.0 RC3

[Timothy Potter]

Sorry, false alarm ... looks like the Alluxio JAR I added to Solr's
classpath has codahale classes in it.

On Thu, Sep 14, 2017 at 11:54 AM, Timothy Potter <thelabd...@gmail.com> wrote:
> I'm seeing this when starting the latest RC:
>
> 2017-09-14 18:50:09.074 INFO  (main) [   ] o.a.s.c.SolrXmlConfig
> Loading container configuration from
> /home/ec2-user/alluxio/solr-7.0.0/server/solr/solr.xml
> 2017-09-14 18:50:09.179 ERROR (main) [   ] o.a.s.s.SolrDispatchFilter
> Could not start Solr. Check solr/home property and the logs
> 2017-09-14 18:50:09.202 ERROR (main) [   ] o.a.s.c.SolrCore
> null:java.lang.LinkageError: loader constraint violation in interface
> itable initialization: when resolving method
> "org.apache.solr.metrics.MetricSuppliers$DefaultCounterSupplier.newMetric()Lcom/codahale/metrics/Metric;"
> the class loader (instance of
> org/eclipse/jetty/webapp/WebAppClassLoader) of the current class,
> org/apache/solr/metrics/MetricSuppliers$DefaultCounterSupplier, and
> the class loader (instance of
> org/eclipse/jetty/start/Classpath$Loader) for interface
> com/codahale/metrics/MetricRegistry$MetricSupplier have different
> Class objects for the type com/codahale/metrics/Metric used in the
> signature
> at 
> org.apache.solr.metrics.MetricSuppliers.counterSupplier(MetricSuppliers.java:269)
> at 
> org.apache.solr.metrics.SolrMetricManager.(SolrMetricManager.java:119)
> at org.apache.solr.core.CoreContainer.load(CoreContainer.java:492)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.createCoreContainer(SolrDispatchFilter.java:261)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.init(SolrDispatchFilter.java:181)
> at 
> org.eclipse.jetty.servlet.FilterHolder.initialize(FilterHolder.java:137)
> at 
> org.eclipse.jetty.servlet.ServletHandler.initialize(ServletHandler.java:873)
> at 
> org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:349)
> at 
> org.eclipse.jetty.webapp.WebAppContext.startWebapp(WebAppContext.java:1404)
> at 
> org.eclipse.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1366)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:778)
> at 
> org.eclipse.jetty.servlet.ServletContextHandler.doStart(ServletContextHandler.java:262)
> at 
> org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:520)
> at 
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)
> at 
> org.eclipse.jetty.deploy.bindings.StandardStarter.processBinding(StandardStarter.java:41)
> at 
> org.eclipse.jetty.deploy.AppLifeCycle.runBindings(AppLifeCycle.java:188)
> at 
> org.eclipse.jetty.deploy.DeploymentManager.requestAppGoal(DeploymentManager.java:499)
> at 
> org.eclipse.jetty.deploy.DeploymentManager.addApp(DeploymentManager.java:147)
> at 
> org.eclipse.jetty.deploy.providers.ScanningAppProvider.fileAdded(ScanningAppProvider.java:180)
> at 
> org.eclipse.jetty.deploy.providers.WebAppProvider.fileAdded(WebAppProvider.java:458)
> at 
> org.eclipse.jetty.deploy.providers.ScanningAppProvider$1.fileAdded(ScanningAppProvider.java:64)
> at org.eclipse.jetty.util.Scanner.reportAddition(Scanner.java:610)
> at org.eclipse.jetty.util.Scanner.reportDifferences(Scanner.java:529)
> at org.eclipse.jetty.util.Scanner.scan(Scanner.java:392)
> at org.eclipse.jetty.util.Scanner.doStart(Scanner.java:313)
> at 
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)
> at 
> org.eclipse.jetty.deploy.providers.ScanningAppProvider.doStart(ScanningAppProvider.java:150)
> at 
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)
> at 
> org.eclipse.jetty.deploy.DeploymentManager.startAppProvider(DeploymentManager.java:561)
> at 
> org.eclipse.jetty.deploy.DeploymentManager.doStart(DeploymentManager.java:236)
> at 
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)
> at 
> org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:131)
> at org.eclipse.jetty.server.Server.start(Server.java:422)
> at 
> org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:113)
> at 
> org.eclipse.jetty.server.handler.AbstractHandler.doStart(AbstractHandler.java:61)
> at org.eclipse.jetty.server.Server.doStart(Server.java:389)
>
> On Thu, Sep 14, 2017 at 6:34 AM, Adrien Grand <jpou...@gmail.com> wrote:
>> It looks li

Re: [VOTE] Release Apache Lucene/Solr 7.0.0 RC3

[Timothy Potter]

I'm seeing this when starting the latest RC:

2017-09-14 18:50:09.074 INFO  (main) [   ] o.a.s.c.SolrXmlConfig
Loading container configuration from
/home/ec2-user/alluxio/solr-7.0.0/server/solr/solr.xml
2017-09-14 18:50:09.179 ERROR (main) [   ] o.a.s.s.SolrDispatchFilter
Could not start Solr. Check solr/home property and the logs
2017-09-14 18:50:09.202 ERROR (main) [   ] o.a.s.c.SolrCore
null:java.lang.LinkageError: loader constraint violation in interface
itable initialization: when resolving method
"org.apache.solr.metrics.MetricSuppliers$DefaultCounterSupplier.newMetric()Lcom/codahale/metrics/Metric;"
the class loader (instance of
org/eclipse/jetty/webapp/WebAppClassLoader) of the current class,
org/apache/solr/metrics/MetricSuppliers$DefaultCounterSupplier, and
the class loader (instance of
org/eclipse/jetty/start/Classpath$Loader) for interface
com/codahale/metrics/MetricRegistry$MetricSupplier have different
Class objects for the type com/codahale/metrics/Metric used in the
signature
at 
org.apache.solr.metrics.MetricSuppliers.counterSupplier(MetricSuppliers.java:269)
at 
org.apache.solr.metrics.SolrMetricManager.(SolrMetricManager.java:119)
at org.apache.solr.core.CoreContainer.load(CoreContainer.java:492)
at 
org.apache.solr.servlet.SolrDispatchFilter.createCoreContainer(SolrDispatchFilter.java:261)
at 
org.apache.solr.servlet.SolrDispatchFilter.init(SolrDispatchFilter.java:181)
at 
org.eclipse.jetty.servlet.FilterHolder.initialize(FilterHolder.java:137)
at 
org.eclipse.jetty.servlet.ServletHandler.initialize(ServletHandler.java:873)
at 
org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:349)
at 
org.eclipse.jetty.webapp.WebAppContext.startWebapp(WebAppContext.java:1404)
at 
org.eclipse.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1366)
at 
org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:778)
at 
org.eclipse.jetty.servlet.ServletContextHandler.doStart(ServletContextHandler.java:262)
at 
org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:520)
at 
org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)
at 
org.eclipse.jetty.deploy.bindings.StandardStarter.processBinding(StandardStarter.java:41)
at 
org.eclipse.jetty.deploy.AppLifeCycle.runBindings(AppLifeCycle.java:188)
at 
org.eclipse.jetty.deploy.DeploymentManager.requestAppGoal(DeploymentManager.java:499)
at 
org.eclipse.jetty.deploy.DeploymentManager.addApp(DeploymentManager.java:147)
at 
org.eclipse.jetty.deploy.providers.ScanningAppProvider.fileAdded(ScanningAppProvider.java:180)
at 
org.eclipse.jetty.deploy.providers.WebAppProvider.fileAdded(WebAppProvider.java:458)
at 
org.eclipse.jetty.deploy.providers.ScanningAppProvider$1.fileAdded(ScanningAppProvider.java:64)
at org.eclipse.jetty.util.Scanner.reportAddition(Scanner.java:610)
at org.eclipse.jetty.util.Scanner.reportDifferences(Scanner.java:529)
at org.eclipse.jetty.util.Scanner.scan(Scanner.java:392)
at org.eclipse.jetty.util.Scanner.doStart(Scanner.java:313)
at 
org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)
at 
org.eclipse.jetty.deploy.providers.ScanningAppProvider.doStart(ScanningAppProvider.java:150)
at 
org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)
at 
org.eclipse.jetty.deploy.DeploymentManager.startAppProvider(DeploymentManager.java:561)
at 
org.eclipse.jetty.deploy.DeploymentManager.doStart(DeploymentManager.java:236)
at 
org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)
at 
org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:131)
at org.eclipse.jetty.server.Server.start(Server.java:422)
at 
org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:113)
at 
org.eclipse.jetty.server.handler.AbstractHandler.doStart(AbstractHandler.java:61)
at org.eclipse.jetty.server.Server.doStart(Server.java:389)

On Thu, Sep 14, 2017 at 6:34 AM, Adrien Grand  wrote:
> It looks like the vote passed? (hurray!)
>
> Le lun. 11 sept. 2017 à 23:07, Mike Drob  a écrit :
>>
>> SUCCESS! [1:09:28.373226]
>>
>> On Mac OS X 10.12.6 with Oracle Java 1.8.0_131 and Ant 1.10.1
>>
>> On Mon, Sep 11, 2017 at 2:39 PM, Tomás Fernández Löbbe
>>  wrote:
>>>
>>> +1
>>> SUCCESS! [0:44:22.517203]
>>>
>>> Thanks for working on this Anshum!
>>>
>>> On Mon, Sep 11, 2017 at 10:45 AM, Tommaso Teofili
>>>  wrote:

 SUCCESS! [4:47:50.042814]

 +1 for me too, then a quick bugfix release which includes also
 SOLR-11348


 Il giorno lun 11 set 2017 

[jira] [Updated] (SOLR-11335) HdfsDirectory & Factory should not close the FileSystem object retrieved with get

[Timothy Potter (JIRA)]

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

Timothy Potter updated SOLR-11335:
--
Priority: Minor  (was: Major)

Changed to minor given the user can just disable the cache in core-site.xml 
loaded into Solr.

> HdfsDirectory & Factory should not close the FileSystem object retrieved with 
> get
> -
>
> Key: SOLR-11335
> URL: https://issues.apache.org/jira/browse/SOLR-11335
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Hadoop Integration
>Reporter: Timothy Potter
>Priority: Minor
>
> I'm seeing issues where the Hadoop FileSystem instance is closed out from 
> under other objects. From what I understand, the Hadoop FileSystem object 
> (org.apache.hadoop.fs.FileSystem) retrieved with {{FileSystem.get}} as is 
> done in HdfsDirectory's ctor is a shared object that if closed, can affect 
> other code using that same shared instance. You can see this is a cached, 
> shared object here -> 
> https://github.com/apache/hadoop/blob/trunk/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/fs/FileSystem.java#L455
> Thus, I suspect Solr should not be closing any FileSystem instance retrieved 
> with get. It's important to mention that if I set the 
> {{fs.$SCHEME.impl.disable.cache}} to true, then my problems go away, which 
> seems to confirm that Solr is using the API incorrectly. That being said, I'm 
> surprised this hasn't been raised before, so maybe I've missed something 
> basic in Solr's use of HDFS?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-11335) HdfsDirectory & Factory should not close the FileSystem object retrieved with get

[Timothy Potter (JIRA)]

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

Timothy Potter commented on SOLR-11335:
---

With a bit more digging, I see that HdfsUpdateLog sets 
{{fs.hdfs.impl.disable.cache=true}}, but I'm not sure if that Configuration 
applies to HdfsDirectory as well. Then I realized that the initialization of 
HdfsUpdateLog depends on this check:
{code}
  if (dataDir != null && dataDir.startsWith("hdfs:/")) {
{code}
Which doesn't work for me, because my HDFS path is {{alluxio://}}. Given HDFS 
allows different schemes besides HDFS, seems like this code should not only 
look for hdfs:/

> HdfsDirectory & Factory should not close the FileSystem object retrieved with 
> get
> -
>
> Key: SOLR-11335
> URL: https://issues.apache.org/jira/browse/SOLR-11335
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Hadoop Integration
>Reporter: Timothy Potter
>
> I'm seeing issues where the Hadoop FileSystem instance is closed out from 
> under other objects. From what I understand, the Hadoop FileSystem object 
> (org.apache.hadoop.fs.FileSystem) retrieved with {{FileSystem.get}} as is 
> done in HdfsDirectory's ctor is a shared object that if closed, can affect 
> other code using that same shared instance. You can see this is a cached, 
> shared object here -> 
> https://github.com/apache/hadoop/blob/trunk/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/fs/FileSystem.java#L455
> Thus, I suspect Solr should not be closing any FileSystem instance retrieved 
> with get. It's important to mention that if I set the 
> {{fs.$SCHEME.impl.disable.cache}} to true, then my problems go away, which 
> seems to confirm that Solr is using the API incorrectly. That being said, I'm 
> surprised this hasn't been raised before, so maybe I've missed something 
> basic in Solr's use of HDFS?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-11335) HdfsDirectory & Factory should not close the FileSystem object retrieved with get

[Timothy Potter (JIRA)]

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

Timothy Potter commented on SOLR-11335:
---

[~markrmil...@gmail.com] I know you've done a ton of work here, am I missing 
something or is this really a bug?

> HdfsDirectory & Factory should not close the FileSystem object retrieved with 
> get
> -
>
> Key: SOLR-11335
> URL: https://issues.apache.org/jira/browse/SOLR-11335
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Hadoop Integration
>Reporter: Timothy Potter
>
> I'm seeing issues where the Hadoop FileSystem instance is closed out from 
> under other objects. From what I understand, the Hadoop FileSystem object 
> (org.apache.hadoop.fs.FileSystem) retrieved with {{FileSystem.get}} as is 
> done in HdfsDirectory's ctor is a shared object that if closed, can affect 
> other code using that same shared instance. You can see this is a cached, 
> shared object here -> 
> https://github.com/apache/hadoop/blob/trunk/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/fs/FileSystem.java#L455
> Thus, I suspect Solr should not be closing any FileSystem instance retrieved 
> with get. It's important to mention that if I set the 
> {{fs.$SCHEME.impl.disable.cache}} to true, then my problems go away, which 
> seems to confirm that Solr is using the API incorrectly. That being said, I'm 
> surprised this hasn't been raised before, so maybe I've missed something 
> basic in Solr's use of HDFS?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Created] (SOLR-11335) HdfsDirectory & Factory should not close the FileSystem object retrieved with get

[Timothy Potter (JIRA)]

Timothy Potter created SOLR-11335:
-

 Summary: HdfsDirectory & Factory should not close the FileSystem 
object retrieved with get
 Key: SOLR-11335
 URL: https://issues.apache.org/jira/browse/SOLR-11335
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
  Components: Hadoop Integration
Reporter: Timothy Potter


I'm seeing issues where the Hadoop FileSystem instance is closed out from under 
other objects. From what I understand, the Hadoop FileSystem object 
(org.apache.hadoop.fs.FileSystem) retrieved with {{FileSystem.get}} as is done 
in HdfsDirectory's ctor is a shared object that if closed, can affect other 
code using that same shared instance. You can see this is a cached, shared 
object here -> 
https://github.com/apache/hadoop/blob/trunk/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/fs/FileSystem.java#L455

Thus, I suspect Solr should not be closing any FileSystem instance retrieved 
with get. It's important to mention that if I set the 
{{fs.$SCHEME.impl.disable.cache}} to true, then my problems go away, which 
seems to confirm that Solr is using the API incorrectly. That being said, I'm 
surprised this hasn't been raised before, so maybe I've missed something basic 
in Solr's use of HDFS?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Created] (SOLR-11257) Only setting maxThreadCount for ConcurrentMergeScheduler (which is a user error) leads to a confusing validation error msg.

[Timothy Potter (JIRA)]

Timothy Potter created SOLR-11257:
-

 Summary: Only setting maxThreadCount for ConcurrentMergeScheduler 
(which is a user error) leads to a confusing validation error msg.
 Key: SOLR-11257
 URL: https://issues.apache.org/jira/browse/SOLR-11257
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Timothy Potter
Priority: Minor


I tried tuning the maxThreadCount for my Concurrent scheduler using:

{code}
 
  4
   
{code}
and got:
{code}
Validation errors:
Error: java.lang.IllegalArgumentException:java.lang.IllegalArgumentException: 
both maxMergeCount and maxThreadCount must be AUTO_DETECT_MERGES_AND_THREADS
{code}

Hmmm ... don't know what that means? As I user I need a better error message 
than that ^ Of course looking at the code, it seems I must also set: 
{{maxMergeCount}} but that error doesn't tell me that. So this bug is about 
fixing up the error to be more helpful to the user. Of course this is advanced 
functionality, so maybe expecting me to read the code to understand, in which 
case, just close this as invalid.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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