Re: Congratulations to the new Apache Solr PMC Chair, Jan Høydahl!
Congratulations Jan ! On Sat, 20 Feb 2021 at 5:30 AM, Jan Høydahl wrote: > Thanks everyone! > > It's an exciting season for Solr, and I look forward to serving the > project as chair. > Also thanks to Anshum for an excellent job last term for Lucene. > > Jan > > > 18. feb. 2021 kl. 19:55 skrev Anshum Gupta : > > > > Hi everyone, > > > > I’d like to inform everyone that the newly formed Apache Solr PMC > nominated > > and elected Jan Høydahl for the position of the Solr PMC Chair and Vice > > President. This decision was approved by the board in its February 2021 > > meeting. > > > > Congratulations Jan! > > > > -- > > Anshum Gupta > >
Re: GC cost of creating String resource description on IndexInput clone
Late evaluation sounds like it would definitely be nice, but I worry about holding on to object instances longer than necessary might lead to memory leaks. Sounds like a good issue to open on JIRA. On Fri, Feb 19, 2021 at 3:58 PM Viral Gandhi wrote: > Hello everyone, > > We recently added Java Flight Recorder (JFR) to our internal benchmarking. > While looking through top heap allocations from JFR output, we noticed the > following to be in top 5 contributors to garbage creation. > > org.apache.lucene.store.IndexInput#getFullSliceDescription() > at org.apache.lucene.store.ByteBufferIndexInput#buildSlice() >at org.apache.lucene.store.ByteBufferIndexInput#slice() >at > org.apache.lucene.store.ByteBufferIndexInput$SingleBufferImpl#slice() >at org.apache.lucene.store.IndexInput#randomAccessSlice() > > It seems that we construct a new String resource description for each > clone/slice of IndexInput instance. Resource description for a clone/slice > instance is a String concatenation of resource description from original > instance and current slice description. Also, clone/slice can happen > multiple times per query per segment. > > Can we avoid upfront String allocation by late-evaluating > IndexInput.toString() on the cloned instance? One approach could be to > hold a reference of the base IndexInput instance in the cloned instance. > Then while evaluating IndexInput.toString() on a cloned instance, we can > construct a resource description by concatenating base instance's > toString() with current resource description. My understanding is that > IndexInput.toString() is primarily used for debugging purposes hence we > can benefit from the late-evaluation. > > With this approach, we are seeing sustainable GC time reduction of ~6% and > gain of ~1% to red-line QPS (throughput). My intention to start this thread > is to collect feedback on this approach as well as to discuss any other > ideas. > > Thanks, > Viral Gandhi >
Re: Congratulations to the new Apache Solr PMC Chair, Jan Høydahl!
Thanks everyone! It's an exciting season for Solr, and I look forward to serving the project as chair. Also thanks to Anshum for an excellent job last term for Lucene. Jan > 18. feb. 2021 kl. 19:55 skrev Anshum Gupta : > > Hi everyone, > > I’d like to inform everyone that the newly formed Apache Solr PMC nominated > and elected Jan Høydahl for the position of the Solr PMC Chair and Vice > President. This decision was approved by the board in its February 2021 > meeting. > > Congratulations Jan! > > -- > Anshum Gupta - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Congratulations to the new Apache Solr PMC Chair, Jan Høydahl!
Congratulations Jan! On Thu, Feb 18, 2021 at 7:56 PM Anshum Gupta wrote: > > Hi everyone, > > I’d like to inform everyone that the newly formed Apache Solr PMC nominated > and elected Jan Høydahl for the position of the Solr PMC Chair and Vice > President. This decision was approved by the board in its February 2021 > meeting. > > Congratulations Jan! > > -- > Anshum Gupta - 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
+1 SUCCESS! [0:44:40.820638] Mike McCandless http://blog.mikemccandless.com On Tue, Feb 16, 2021 at 9:42 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 > >
Re: Congratulations to the new Apache Solr PMC Chair, Jan Høydahl!
Congrats Jan and Best Wishes! Also many thanks to Anshum for all his efforts in the last term! Also a belated shout out to Cassandra and other chairs in the past for their much appreciated efforts for the community ! Regards Aroop > On Feb 18, 2021, at 10:55 AM, Anshum Gupta wrote: > > Hi everyone, > > I’d like to inform everyone that the newly formed Apache Solr PMC nominated > and elected Jan Høydahl for the position of the Solr PMC Chair and Vice > President. This decision was approved by the board in its February 2021 > meeting. > > Congratulations Jan! > > -- > Anshum Gupta - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
GC cost of creating String resource description on IndexInput clone
Hello everyone, We recently added Java Flight Recorder (JFR) to our internal benchmarking. While looking through top heap allocations from JFR output, we noticed the following to be in top 5 contributors to garbage creation. org.apache.lucene.store.IndexInput#getFullSliceDescription() at org.apache.lucene.store.ByteBufferIndexInput#buildSlice() at org.apache.lucene.store.ByteBufferIndexInput#slice() at org.apache.lucene.store.ByteBufferIndexInput$SingleBufferImpl#slice() at org.apache.lucene.store.IndexInput#randomAccessSlice() It seems that we construct a new String resource description for each clone/slice of IndexInput instance. Resource description for a clone/slice instance is a String concatenation of resource description from original instance and current slice description. Also, clone/slice can happen multiple times per query per segment. Can we avoid upfront String allocation by late-evaluating IndexInput.toString() on the cloned instance? One approach could be to hold a reference of the base IndexInput instance in the cloned instance. Then while evaluating IndexInput.toString() on a cloned instance, we can construct a resource description by concatenating base instance's toString() with current resource description. My understanding is that IndexInput.toString() is primarily used for debugging purposes hence we can benefit from the late-evaluation. With this approach, we are seeing sustainable GC time reduction of ~6% and gain of ~1% to red-line QPS (throughput). My intention to start this thread is to collect feedback on this approach as well as to discuss any other ideas. Thanks, Viral Gandhi
Re: Congratulations to the new Apache Solr PMC Chair, Jan Høydahl!
Congrats! On Fri, Feb 19, 2021 at 10:06 AM Divye wrote: > > Congratulations Jan! > > Regards, > Divye > > On Fri, 19 Feb, 2021, 00:26 Anshum Gupta, wrote: > > > Hi everyone, > > > > I’d like to inform everyone that the newly formed Apache Solr PMC nominated > > and elected Jan Høydahl for the position of the Solr PMC Chair and Vice > > President. This decision was approved by the board in its February 2021 > > meeting. > > > > Congratulations Jan! > > > > -- > > Anshum Gupta > > - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Random disabling of asserts in tests is not working
Hi Uwe, No, it's not randomized - always runs with the security manager enabled. All the options are here: https://github.com/apache/lucene-solr/blob/master/gradle/testing/randomization.gradle#L68-L103 When the value says "random" we pick the random value at runtime (so that it also works within IDEs). We could pick security manager at build-time (derive from project seed). This is a no-brainer to do. As Robert said - perhaps we should keep some things more strict for developers and just shuffle on the CI-only. This requires passing -Ptests.*=... flags but is simple, I think. Dawid On Fri, Feb 19, 2021 at 7:45 PM Uwe Schindler wrote: > Hi, > > I don’t fully remember what the setup previously was, but at least for > master and 8.x it does not automatically enable/disable asserts. We can of > course do this together with the other settings like GC or compressed OOPs, > its just a few more lines in the Groovy file. > > > > I was also thinking that we have Security Manager enabled/disabled from > time to time. But recently, I see no randomization for this on Jenkins, > unless it’s part of the Gradle build. > > > > Uwe > > > > - > > Uwe Schindler > > Achterdiek 19, D-28357 Bremen > > https://www.thetaphi.de > > eMail: u...@thetaphi.de > > > > *From:* Robert Muir > *Sent:* Friday, February 19, 2021 3:13 PM > *To:* dev@lucene.apache.org > *Subject:* Re: Random disabling of asserts in tests is not working > > > > I don't think it is enabled (at least in policeman jenkins). perhaps it > didn't work correctly when the build was cutover to gradle. Take a look at > any old build such as > https://jenkins.thetaphi.de/view/Lucene-Solr/job/Lucene-Solr-master-Linux/29491/ > . You can see the variables it randomizes right there. > > > > You can confirm by clicking console->full log and it prints exact gradle > command that it runs: > https://jenkins.thetaphi.de/view/Lucene-Solr/job/Lucene-Solr-master-Linux/29491/consoleFull > > > > Let's look into it, in a couple weeks or so? > > > > On Fri, Feb 19, 2021 at 8:32 AM Michael McCandless < > luc...@mikemccandless.com> wrote: > > On Fri, Feb 19, 2021 at 8:07 AM Robert Muir wrote: > > > > I think it has a downside: having a bug in an assert is really more of a > corner case. This is the kind of thing jenkins is for? > > > > Ahh, that is indeed a really good point. I would want/expect asserts to > always work correctly when running local tests ... if we randomly disabled > them in our checkouts it can cause a false sense of security, too soon. > > > > OK, I agree, let's leave it as randomization in Jenkins! How do we know > that Jenkins job/s are still randomizing assertions? Who tests the tester? > > > > Mike McCandless > > http://blog.mikemccandless.com > >
RE: Random disabling of asserts in tests is not working
Hi, I don’t fully remember what the setup previously was, but at least for master and 8.x it does not automatically enable/disable asserts. We can of course do this together with the other settings like GC or compressed OOPs, its just a few more lines in the Groovy file. I was also thinking that we have Security Manager enabled/disabled from time to time. But recently, I see no randomization for this on Jenkins, unless it’s part of the Gradle build. Uwe - Uwe Schindler Achterdiek 19, D-28357 Bremen https://www.thetaphi.de eMail: u...@thetaphi.de From: Robert Muir Sent: Friday, February 19, 2021 3:13 PM To: dev@lucene.apache.org Subject: Re: Random disabling of asserts in tests is not working I don't think it is enabled (at least in policeman jenkins). perhaps it didn't work correctly when the build was cutover to gradle. Take a look at any old build such as https://jenkins.thetaphi.de/view/Lucene-Solr/job/Lucene-Solr-master-Linux/29491/ . You can see the variables it randomizes right there. You can confirm by clicking console->full log and it prints exact gradle command that it runs: https://jenkins.thetaphi.de/view/Lucene-Solr/job/Lucene-Solr-master-Linux/29491/consoleFull Let's look into it, in a couple weeks or so? On Fri, Feb 19, 2021 at 8:32 AM Michael McCandless mailto:luc...@mikemccandless.com> > wrote: On Fri, Feb 19, 2021 at 8:07 AM Robert Muir mailto:rcm...@gmail.com> > wrote: I think it has a downside: having a bug in an assert is really more of a corner case. This is the kind of thing jenkins is for? Ahh, that is indeed a really good point. I would want/expect asserts to always work correctly when running local tests ... if we randomly disabled them in our checkouts it can cause a false sense of security, too soon. OK, I agree, let's leave it as randomization in Jenkins! How do we know that Jenkins job/s are still randomizing assertions? Who tests the tester? Mike McCandless http://blog.mikemccandless.com
Re: Congratulations to the new Lucene PMC Chair, Michael Sokolov!
Congratulations, Mike! On Fri, Feb 19, 2021 at 4:13 AM Koji Sekiguchi wrote: > Congratulations Mike! > > Koji > > On 2021/02/18 6:31, Anshum Gupta wrote: > > Every year, the Lucene PMC rotates the Lucene PMC chair and Apache Vice > President position. > > > > This year we nominated and elected Michael Sokolov as the Chair, a > decision that the board approved > > in its February 2021 meeting. > > > > Congratulations, Mike! > > > > -- > > Anshum Gupta > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > >
Re: Congratulations to the new Apache Solr PMC Chair, Jan Høydahl!
Congratulations Jan! Regards, Divye On Fri, 19 Feb, 2021, 00:26 Anshum Gupta, wrote: > Hi everyone, > > I’d like to inform everyone that the newly formed Apache Solr PMC nominated > and elected Jan Høydahl for the position of the Solr PMC Chair and Vice > President. This decision was approved by the board in its February 2021 > meeting. > > Congratulations Jan! > > -- > Anshum Gupta >
Re: Random disabling of asserts in tests is not working
I don't think it is enabled (at least in policeman jenkins). perhaps it didn't work correctly when the build was cutover to gradle. Take a look at any old build such as https://jenkins.thetaphi.de/view/Lucene-Solr/job/Lucene-Solr-master-Linux/29491/ . You can see the variables it randomizes right there. You can confirm by clicking console->full log and it prints exact gradle command that it runs: https://jenkins.thetaphi.de/view/Lucene-Solr/job/Lucene-Solr-master-Linux/29491/consoleFull Let's look into it, in a couple weeks or so? On Fri, Feb 19, 2021 at 8:32 AM Michael McCandless < luc...@mikemccandless.com> wrote: > On Fri, Feb 19, 2021 at 8:07 AM Robert Muir wrote: > > I think it has a downside: having a bug in an assert is really more of a >> corner case. This is the kind of thing jenkins is for? >> > > Ahh, that is indeed a really good point. I would want/expect asserts to > always work correctly when running local tests ... if we randomly disabled > them in our checkouts it can cause a false sense of security, too soon. > > OK, I agree, let's leave it as randomization in Jenkins! How do we know > that Jenkins job/s are still randomizing assertions? Who tests the tester? > > Mike McCandless > > http://blog.mikemccandless.com >
Re: Random disabling of asserts in tests is not working
I don't argue either way - just stating it's possible to randomize this. > I think it has a downside: having a bug in an assert is really more of a > corner case. This is the kind of thing jenkins is for? > This may be the reason why it's fixed by default (it is/was in ant too).
Re: Random disabling of asserts in tests is not working
On Fri, Feb 19, 2021 at 8:07 AM Robert Muir wrote: I think it has a downside: having a bug in an assert is really more of a > corner case. This is the kind of thing jenkins is for? > Ahh, that is indeed a really good point. I would want/expect asserts to always work correctly when running local tests ... if we randomly disabled them in our checkouts it can cause a false sense of security, too soon. OK, I agree, let's leave it as randomization in Jenkins! How do we know that Jenkins job/s are still randomizing assertions? Who tests the tester? Mike McCandless http://blog.mikemccandless.com
Re: Random disabling of asserts in tests is not working
I think it has a downside: having a bug in an assert is really more of a corner case. This is the kind of thing jenkins is for? Locally it would be nice for the compile-test-debug loop for the asserts to always be working. Tying it into random seeds is gonna result in tests that behave in crazy ways: I'm thinking about first time contributors and stuff. Not every test is some crazy random one... On Fri, Feb 19, 2021 at 7:08 AM Michael McCandless < luc...@mikemccandless.com> wrote: > Ahh, you are right, Dawid! I thought our test infra had the randomization > of enabling or disabling assertions, but it looks like it is our Jenkins > jobs that contain the randomization. > > Could we somehow move the randomness into our test infrastructure? E.g. > it would have helped Gautam (and other developers in the future) catch that > subtle but nasty bug in his PR during private development rather than later > in random Jenkins runs. If I remember right, we originally added this > randomization precisely because we had such a bug, and the bug got released > and later caught and fixed in a subsequent release. > > Or is that a bad idea for some reason :) > > Mike McCandless > > http://blog.mikemccandless.com > > > On Fri, Feb 19, 2021 at 3:44 AM Dawid Weiss wrote: > >> Run, for example: >> >> gradlew -p lucene testOpts >> >> to see the options available. Notice this one: >> >> tests.asserts= true # Enables or disables assertions >> mode. >> >> and run your tests with: >> >> gradlew -p lucene -Ptests.asserts=false test >> >> From IDE level you can disable assertions with -Dtests.asserts=false >> (and not adding -ea). >> >> D. >> >> On Thu, Feb 18, 2021 at 3:45 AM Gautam Worah >> wrote: >> > >> > Hi Folks, >> > >> > I was working on PR LUCENE-9476 when we found cases where `asserts` in >> test cases were always enabled. To verify whether this was true, I wrote a >> simple test case that called assert 1000 times, modified a variable and >> then checked its value. This test case always passed because `assert` was >> always enabled. >> > >> > Mike McCandless mentioned in the PR that Lucene earlier had the >> capability to randomly disable `asserts` so that there were no accidental >> cases of developers relying on `asserts` always being enabled. We may have >> lost this feature when the project transitioned to Gradle. >> > When I change the default value of `tests.asserts` in >> randomization.gradle to false, the test fails promptly. >> > >> > Has anyone else noticed this/knows more about this? >> > >> > Thanks, >> > Gautam Worah. >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >> For additional commands, e-mail: dev-h...@lucene.apache.org >> >>
Re: Random disabling of asserts in tests is not working
We sure can - you'd have to derive the default option for tests.asserts from the seed, much like it's done for file encoding: https://github.com/apache/lucene-solr/blob/master/gradle/testing/randomization.gradle#L94-L97 This has to be done on the build side, not at runtime, because once the JVM starts, it's too late (assertions are either on or off). D. On Fri, Feb 19, 2021 at 1:08 PM Michael McCandless wrote: > > Ahh, you are right, Dawid! I thought our test infra had the randomization of > enabling or disabling assertions, but it looks like it is our Jenkins jobs > that contain the randomization. > > Could we somehow move the randomness into our test infrastructure? E.g. it > would have helped Gautam (and other developers in the future) catch that > subtle but nasty bug in his PR during private development rather than later > in random Jenkins runs. If I remember right, we originally added this > randomization precisely because we had such a bug, and the bug got released > and later caught and fixed in a subsequent release. > > Or is that a bad idea for some reason :) > > Mike McCandless > > http://blog.mikemccandless.com > > > On Fri, Feb 19, 2021 at 3:44 AM Dawid Weiss wrote: >> >> Run, for example: >> >> gradlew -p lucene testOpts >> >> to see the options available. Notice this one: >> >> tests.asserts= true # Enables or disables assertions mode. >> >> and run your tests with: >> >> gradlew -p lucene -Ptests.asserts=false test >> >> From IDE level you can disable assertions with -Dtests.asserts=false >> (and not adding -ea). >> >> D. >> >> On Thu, Feb 18, 2021 at 3:45 AM Gautam Worah wrote: >> > >> > Hi Folks, >> > >> > I was working on PR LUCENE-9476 when we found cases where `asserts` in >> > test cases were always enabled. To verify whether this was true, I wrote a >> > simple test case that called assert 1000 times, modified a variable and >> > then checked its value. This test case always passed because `assert` was >> > always enabled. >> > >> > Mike McCandless mentioned in the PR that Lucene earlier had the capability >> > to randomly disable `asserts` so that there were no accidental cases of >> > developers relying on `asserts` always being enabled. We may have lost >> > this feature when the project transitioned to Gradle. >> > When I change the default value of `tests.asserts` in randomization.gradle >> > to false, the test fails promptly. >> > >> > Has anyone else noticed this/knows more about this? >> > >> > Thanks, >> > Gautam Worah. >> >> - >> 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: Random disabling of asserts in tests is not working
Ahh, you are right, Dawid! I thought our test infra had the randomization of enabling or disabling assertions, but it looks like it is our Jenkins jobs that contain the randomization. Could we somehow move the randomness into our test infrastructure? E.g. it would have helped Gautam (and other developers in the future) catch that subtle but nasty bug in his PR during private development rather than later in random Jenkins runs. If I remember right, we originally added this randomization precisely because we had such a bug, and the bug got released and later caught and fixed in a subsequent release. Or is that a bad idea for some reason :) Mike McCandless http://blog.mikemccandless.com On Fri, Feb 19, 2021 at 3:44 AM Dawid Weiss wrote: > Run, for example: > > gradlew -p lucene testOpts > > to see the options available. Notice this one: > > tests.asserts= true # Enables or disables assertions > mode. > > and run your tests with: > > gradlew -p lucene -Ptests.asserts=false test > > From IDE level you can disable assertions with -Dtests.asserts=false > (and not adding -ea). > > D. > > On Thu, Feb 18, 2021 at 3:45 AM Gautam Worah > wrote: > > > > Hi Folks, > > > > I was working on PR LUCENE-9476 when we found cases where `asserts` in > test cases were always enabled. To verify whether this was true, I wrote a > simple test case that called assert 1000 times, modified a variable and > then checked its value. This test case always passed because `assert` was > always enabled. > > > > Mike McCandless mentioned in the PR that Lucene earlier had the > capability to randomly disable `asserts` so that there were no accidental > cases of developers relying on `asserts` always being enabled. We may have > lost this feature when the project transitioned to Gradle. > > When I change the default value of `tests.asserts` in > randomization.gradle to false, the test fails promptly. > > > > Has anyone else noticed this/knows more about this? > > > > Thanks, > > Gautam Worah. > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > >
Re: Congratulations to the new Apache Solr PMC Chair, Jan Høydahl!
Congratulations Jan! On Fri, Feb 19, 2021 at 9:41 AM Dawid Weiss wrote: > Congratulations, Jan! > > On Thu, Feb 18, 2021 at 7:56 PM Anshum Gupta > wrote: > > > > Hi everyone, > > > > I’d like to inform everyone that the newly formed Apache Solr PMC > nominated and elected Jan Høydahl for the position of the Solr PMC Chair > and Vice President. This decision was approved by the board in its February > 2021 meeting. > > > > Congratulations Jan! > > > > -- > > Anshum Gupta >
Re: Congratulations to the new Apache Solr PMC Chair, Jan Høydahl!
Congratulations Jan! Koji On 2021/02/19 3:55, Anshum Gupta wrote: Hi everyone, I’d like to inform everyone that the newly formed Apache Solr PMC nominated and elected Jan Høydahl for the position of the Solr PMC Chair and Vice President. This decision was approved by the board in its February 2021 meeting. Congratulations Jan! -- Anshum Gupta - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Congratulations to the new Lucene PMC Chair, Michael Sokolov!
Congratulations Mike! Koji On 2021/02/18 6:31, Anshum Gupta wrote: Every year, the Lucene PMC rotates the Lucene PMC chair and Apache Vice President position. This year we nominated and elected Michael Sokolov as the Chair, a decision that the board approved in its February 2021 meeting. Congratulations, Mike! -- Anshum Gupta - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Random disabling of asserts in tests is not working
Run, for example: gradlew -p lucene testOpts to see the options available. Notice this one: tests.asserts= true # Enables or disables assertions mode. and run your tests with: gradlew -p lucene -Ptests.asserts=false test >From IDE level you can disable assertions with -Dtests.asserts=false (and not adding -ea). D. On Thu, Feb 18, 2021 at 3:45 AM Gautam Worah wrote: > > Hi Folks, > > I was working on PR LUCENE-9476 when we found cases where `asserts` in test > cases were always enabled. To verify whether this was true, I wrote a simple > test case that called assert 1000 times, modified a variable and then checked > its value. This test case always passed because `assert` was always enabled. > > Mike McCandless mentioned in the PR that Lucene earlier had the capability to > randomly disable `asserts` so that there were no accidental cases of > developers relying on `asserts` always being enabled. We may have lost this > feature when the project transitioned to Gradle. > When I change the default value of `tests.asserts` in randomization.gradle to > false, the test fails promptly. > > Has anyone else noticed this/knows more about this? > > Thanks, > Gautam Worah. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Congratulations to the new Apache Solr PMC Chair, Jan Høydahl!
Congratulations, Jan! On Thu, Feb 18, 2021 at 7:56 PM Anshum Gupta wrote: > > Hi everyone, > > I’d like to inform everyone that the newly formed Apache Solr PMC nominated > and elected Jan Høydahl for the position of the Solr PMC Chair and Vice > President. This decision was approved by the board in its February 2021 > meeting. > > Congratulations Jan! > > -- > Anshum Gupta - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Congratulations to the new Lucene PMC Chair, Michael Sokolov!
Congratulations and many many thanks! On Fri, Feb 19, 2021 at 8:46 AM Alessandro Benedetti wrote: > Congrats Michael! > -- > Alessandro Benedetti > Apache Lucene/Solr Committer > Director, R Software Engineer, Search Consultant > www.sease.io > > > On Fri, 19 Feb 2021 at 05:35, Melcom87s > wrote: > >> Congrats! >> >> >> >> - >> ᐅ Targeted Web Traffic AFFORDABLE web traffic package >> is the best ideal for small businesses Website Traffic Packages : >> Turn Traffic Increase Into Revenue >> -- >> Sent from: >> https://lucene.472066.n3.nabble.com/Lucene-Java-Developer-f564358.html >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >> For additional commands, e-mail: dev-h...@lucene.apache.org >> >>
