Re: [VOTE] Release Lucene/Solr 8.11.3 RC1
+1 (binding) SUCCESS! [1:05:24.985760] My issue was ANT_ARGS being set to color - fixed with `unset ANT_ARGS` were ANT_ARGS was being set by oh-my-zsh https://github.com/ohmyzsh/ohmyzsh/blob/master/plugins/ant/ant.plugin.zsh. The colored output wouldn't match the regex for the backwards compat testing. Kevin Risden On Wed, Feb 7, 2024 at 8:24 AM Ishan Chattopadhyaya < ichattopadhy...@gmail.com> wrote: > +1 (binding) > > SUCCESS! [1:18:24.494917] > > On Wed, 7 Feb 2024 at 18:24, Jan Høydahl wrote: > >> +1 (binding) >> >> SUCCESS! [1:18:11.930433] >> >> Only ran smoke tester. macOS, Temurin 1.8.0_402 >> >> Jan >> >> 5. feb. 2024 kl. 23:23 skrev Houston Putman : >> >> Please vote for release candidate 1 for Lucene/Solr 8.11.3 >> >> The artifacts can be downloaded from: >> >> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.11.3-RC1-revbaa7c80af4278cc8951a344d8e9320386588d12d >> >> 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.3-RC1-revbaa7c80af4278cc8951a344d8e9320386588d12d >> >> The vote will be open for at least 72 hours i.e. until 2024-02-08 23:00 >> UTC. >> >> [ ] +1 approve >> [ ] +0 no opinion >> [ ] -1 disapprove (and reason why) >> >> Here is my +1 >> >> >>
Re: [VOTE] Release Lucene/Solr 8.11.3 RC1
I'm running the smoke tester on branch_8_11
python3 -u dev-tools/scripts/smokeTestRelease.py \
https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.11.3-RC1-revbaa7c80af4278cc8951a344d8e9320386588d12d
and getting
File
> "/Users/risdenk/repos/apache/lucene-solr/dev-tools/scripts/smokeTestRelease.py",
> line 756, in verifyUnpacked
> confirmAllReleasesAreTestedForBackCompat(version, unpackPath)
> File
> "/Users/risdenk/repos/apache/lucene-solr/dev-tools/scripts/smokeTestRelease.py",
> line 1397, in confirmAllReleasesAreTestedForBackCompat
> raise RuntimeError('some releases are not tested by
> TestBackwardsCompatibility?')
> RuntimeError: some releases are not tested by TestBackwardsCompatibility?
>
Is there something I'm doing wrong?
Kevin Risden
On Tue, Feb 6, 2024 at 3:00 PM Jason Gerlowski
wrote:
> Here's my +1 (binding)
>
> SUCCESS! [0:56:16.591754]
>
> On Mon, Feb 5, 2024 at 5:23 PM Houston Putman wrote:
>
>> Please vote for release candidate 1 for Lucene/Solr 8.11.3
>>
>> The artifacts can be downloaded from:
>>
>> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.11.3-RC1-revbaa7c80af4278cc8951a344d8e9320386588d12d
>>
>> 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.3-RC1-revbaa7c80af4278cc8951a344d8e9320386588d12d
>>
>> The vote will be open for at least 72 hours i.e. until 2024-02-08 23:00
>> UTC.
>>
>> [ ] +1 approve
>> [ ] +0 no opinion
>> [ ] -1 disapprove (and reason why)
>>
>> Here is my +1
>>
>
Re: 8.11.3 release
I've pushed a few things to branch_8_11 recently * https://github.com/apache/lucene-solr/commit/e491400d961b771f146c6e12a7f8ed89eafe128f * https://github.com/apache/lucene-solr/commit/8e545e8f2154698e9bfeee92c40f8541fd7d0152 * https://github.com/apache/lucene-solr/commit/e7560cd2ab024d4315933cd3965aab2961bba994 https://github.com/apache/lucene-solr/pull/2681 is in draft and updated a bunch of relatively low risk dependencies. There might be others we want to upgrade, but figured it was a decent start. Kevin Risden On Thu, Oct 5, 2023 at 4:27 AM Pierre Salagnac wrote: > I just opened a pull request. > https://github.com/apache/lucene-solr/pull/2679 > Details are in the PR. > > Thanks ! > > Le lun. 2 oct. 2023 à 20:25, Ishan Chattopadhyaya < > ichattopadhy...@gmail.com> > a écrit : > > > Thanks Pierre, I'll have it included in 8.11 once you are able to have a > PR > > for this. Thanks! > > > > On Mon, 2 Oct 2023 at 22:22, Pierre Salagnac > > wrote: > > > > > Hi Ishan, > > > Sorry for the late chime in. > > > > > > Some time ago I filled a Jira for a Solr 8 specific bug: > > > https://issues.apache.org/jira/browse/SOLR-16843 > > > > > > At that time, I wasn't expecting more 8.x releases, so I did not open a > > PR > > > for it. > > > I can work on a fix if we have a few days more before the release. I > > think > > > it is worth to have it in solr 8 (that's not a backport) > > > > > > Thanks > > > > > > > > > Le ven. 29 sept. 2023 à 23:24, Ishan Chattopadhyaya < > > > ichattopadhy...@gmail.com> a écrit : > > > > > > > I'm going to track items from 9x releases in the following sheet. > > > > > > > > > > > > > > https://docs.google.com/spreadsheets/d/1FADkjDS0yfXpaUi3fbwsa7Izy5HOxE9AR_NKiss1sIo/edit#gid=0 > > > > > > > > Please let me know if there's any item there that you think would be > > > useful > > > > to backport (if easy) to 8.11, and want me to take a look at > > backporting > > > > it. > > > > Regards, > > > > Ishan > > > > > > > > On Tue, 19 Sept 2023 at 01:15, Ishan Chattopadhyaya < > > > > ichattopadhy...@gmail.com> wrote: > > > > > > > > > Just a reminder to backport any issues one sees fit for a 8.11.3 > > > release. > > > > > I'll try to get an RC out by the end of September, so still more > > than a > > > > > week away. > > > > > > > > > > On Wed, 23 Aug 2023 at 17:09, Ishan Chattopadhyaya < > > > > > ichattopadhy...@gmail.com> wrote: > > > > > > > > > >> Hi Jan, > > > > >> Yes, still targeting September. But I will slip on my initial plan > > of > > > > >> doing it by first week of September. I'm foreseeing mid September > > > > timeframe. > > > > >> Thanks for checking in. > > > > >> Regards, > > > > >> Ishan > > > > >> > > > > >> On Wed, 23 Aug, 2023, 5:05 pm Jan Høydahl, > > > > > wrote: > > > > >> > > > > >>> Hi, > > > > >>> > > > > >>> Following up on Ishan's proposed 8.11.3 release ( > > > > >>> https://lists.apache.org/thread/3xjtv1sxqx8f9nvhkc0cb90b2p76nfx2 > ) > > > > >>> > > > > >>> Does the Lucene project have any bugfix candidates for > backporting? > > > > >>> > > > > >>> Ishan, are you still targeting September? > > > > >>> > > > > >>> Jan > > > > >>> > > > > >>> > > > > >>> > 1. aug. 2023 kl. 14:57 skrev Ishan Chattopadhyaya < > > > > >>> ichattopadhy...@gmail.com>: > > > > >>> > > > > > >>> > Oh yes, good idea. Forgot about the split! > > > > >>> > > > > > >>> > +Lucene Dev > > > > >>> > > > > > >>> > On Tue, 1 Aug, 2023, 6:17 pm Uwe Schindler, > > > wrote: > > > > >>> > > > > > >>> >> Maybe ask on Lucene list, too, if there are some bug people > like > > > to > > > > >
Build Upgraded to Gradle 8.4
Just pushed to main/branch_9x Gradle 8.4 upgrade. Let me know if you see any weirdness. Google Java Format was upgraded so there is a tidy commit that made a bunch of whitespace changes. If you have PRs in progress, probably need to make sure tidy is run after getting up to date with main/branch_9x. Kevin Risden
Re: [VOTE] Release Lucene 9.4.2 RC1
I haven't looked at Lucene smoketester code but I would assume its similar to Solr - SOLR-16132 ( https://github.com/apache/solr/commit/0cfef740617cc40585e3121e0b41e5cc8002471f) fixed some of the gpg-agent stuff recently. Kevin Risden On Fri, Nov 18, 2022 at 10:07 AM Uwe Schindler wrote: > I had also seen this message. My guess: Another build was running in > Jenkins that also spawned an agent with different home dir! I think Robert > already talked about this. We should kill the agents before/after we have > used them. > > Uwe > Am 18.11.2022 um 15:47 schrieb Adrien Grand: > > Reading Uwe's error message more carefully, I had first assumed that the > GPG failure was due to the lack of an ultimately trusted signature, but it > seems like it's due to "can't connect to the agent: IPC connect call > failed" actually, which suggests an issue with the GPG agent? > > On Fri, Nov 18, 2022 at 3:00 PM Michael Sokolov > wrote: > >> I got this message when initially downloading the artifacts: >> >> Downloading >> https://dist.apache.org/repos/dist/dev/lucene/lucene-9.4.2-RC1-rev-858d9b437047a577fa9457089afff43eefa461db/lucene/lucene-9.4.2-src.tgz.asc >> File: >> /tmp/smoke_lucene_9.4.2_858d9b437047a577fa9457089afff43eefa461db/lucene.lucene-9.4.2-src.tgz.gpg.verify.log >> verify trust >> GPG: gpg: WARNING: This key is not certified with a trusted >> signature! >> >> is it related? >> >> On Fri, Nov 18, 2022 at 8:43 AM Uwe Schindler wrote: >> > >> > The problem is: it is working like this since years - the 9.4.1 release >> worked fine. No change! >> > >> > And I can't configure this because GPG uses its own home directory >> setup by smoke tester (see paths below). So it should not look anywhere >> else? In addition "gpg: no ultimately trusted keys found" is just a >> warning, it should not cause gpg to exit. >> > >> > Also why does it only happens at the time of Maven? It checks >> signatures before, too. This is why I restarted the build: >> https://jenkins.thetaphi.de/job/Lucene-Release-Tester/25/console (still >> running) >> > >> > Uwe >> > >> > Am 18.11.2022 um 14:21 schrieb Adrien Grand: >> > >> > Uwe, the error message suggests that Policeman Jenkins is not >> ultimately trusting any of the keys. Does it work if you configure it to >> ultimately trust your "Uwe Schindler (CODE SIGNING KEY) < >> uschind...@apache.org>" key (which I assume you would be ok with)? >> > >> > On Fri, Nov 18, 2022 at 2:18 PM Uwe Schindler wrote: >> >> >> >> I am restarting the build, maybe it was some hickup. Interestingly it >> only failed for the Maven dependencies. P.S.: Why does it import the key >> file over and over? It would be enough to do this once at beginning of >> smoker. >> >> >> >> Uwe >> >> >> >> Am 18.11.2022 um 14:12 schrieb Uwe Schindler: >> >> >> >> Hi, >> >> >> >> I get a failure because your key is somehow rejected by GPG (Ubuntu >> 22.04): >> >> >> >> https://jenkins.thetaphi.de/job/Lucene-Release-Tester/24/console >> >> >> >> verify maven artifact sigs command "gpg --homedir >> /home/jenkins/workspace/Lucene-Release-Tester/smoketmp/lucene.gpg --import >> /home/jenkins/workspace/Lucene-Release-Tester/smoketmp/KEYS" failed: gpg: >> keybox >> '/home/jenkins/workspace/Lucene-Release-Tester/smoketmp/lucene.gpg/pubring.kbx' >> created gpg: >> /home/jenkins/workspace/Lucene-Release-Tester/smoketmp/lucene.gpg/trustdb.gpg: >> trustdb created gpg: key B83EA82A0AFCEE7C: public key "Yonik Seeley < >> yo...@apache.org>" imported gpg: can't connect to the agent: IPC connect >> call failed gpg: key E48025ED13E57FFC: public key "Upayavira < >> u...@odoko.co.uk>" imported [...] gpg: key 051A0FAF76BC6507: public key >> "Adrien Grand (CODE SIGNING KEY) " imported [...] >> gpg: key 32423B0E264B5CBA: public key "Julie Tibshirani (New code signing >> key) " imported gpg: Total number processed: 62 >> gpg: imported: 62 gpg: no ultimately trusted keys found >> >> It looks like for others it succeeds? No idea why. Maybe Ubuntu 22.04 >> has a too-new GPG or it needs to use gpg2? >> >> >> >> -1 to release until this is sorted out. >> >> >> >> Uwe >> >> >> >> Am 17.11.2022 um 15:18 schrieb Adrien Grand: >> >> >> >> Please vote
Re: [JENKINS] Lucene-main-Linux (64bit/jdk-17.0.2) - Build # 34604 - Failure!
> > the problem is a bug in optimization of Hotspot, it is clearly a problem > with JDK 17+ which is currently to be fixed. > I see that https://bugs.openjdk.java.net/browse/JDK-8283386 <https://bugs.openjdk.java.net/browse/JDK-8283386?focusedCommentId=14496153=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14496153> is marked as duplicate of https://bugs.openjdk.org/browse/JDK-8275610. A client has a JVM failure on JDK 17.0.3 that matches PhaseIdealLoop::build_loop_late_post_work. Is that failure now tracked under https://bugs.openjdk.org/browse/JDK-8285835? I noticed that the JDK-8285835 only list 18, 19, 20 as the affected versions. Is it possible that the metadata wasn't updated to include JDK 17 when JDK-8283386 was closed? Kevin Risden On Mon, May 16, 2022 at 1:08 PM Uwe Schindler wrote: > Hi, > > > > Those loops are fine, the problem is a bug in optimization of Hotspot, it > is clearly a problem with JDK 17+ which is currently to be fixed. There is > NOTHING to change in Lucene. > > > > Uwe > > > > - > > Uwe Schindler > > Achterdiek 19, D-28357 Bremen > > https://www.thetaphi.de > > eMail: u...@thetaphi.de > > > > *From:* Yuti G > *Sent:* Monday, May 16, 2022 6:48 PM > *To:* dev@lucene.apache.org > *Subject:* Re: [JENKINS] Lucene-main-Linux (64bit/jdk-17.0.2) - Build # > 34604 - Failure! > > > > Hi Uwe, > > > > Thanks for sharing an example of the for loop in the facet code here. > > > > I have been working on some facet code changes recently and have seen this > kind of iterator-based loop several times. I can open a Jira issue and > submit a PR to change these for loops in the facet module. > > > > Best, > > Yuting Gan > > > > On Mon, May 16, 2022 at 2:09 AM Uwe Schindler wrote: > > That’s again the same bug we have already seen in facet module: > > > https://bugs.openjdk.java.net/browse/JDK-8283386?focusedCommentId=14496153=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14496153 > > > > It’s a bad one and already exists in JDK 17 GA. > > Uwe > > > > - > > Uwe Schindler > > Achterdiek 19, D-28357 Bremen > > https://www.thetaphi.de > > eMail: u...@thetaphi.de > > > > *From:* Dawid Weiss > *Sent:* Monday, May 16, 2022 8:19 AM > *To:* Lucene Dev > *Cc:* bui...@lucene.apache.org > *Subject:* Re: [JENKINS] Lucene-main-Linux (64bit/jdk-17.0.2) - Build # > 34604 - Failure! > > > > > > JVM failure (on JDK 17.0.2!). > > # > > # A fatal error has been detected by the Java Runtime Environment: > > # > > # SIGSEGV (0xb) at pc=0x7fe6a986f711, pid=1132974, tid=1137900 > > # > > # JRE version: OpenJDK Runtime Environment Temurin-17.0.2+8 (17.0.2+8) (build > 17.0.2+8) > > # Java VM: OpenJDK 64-Bit Server VM Temurin-17.0.2+8 (17.0.2+8, mixed mode, > sharing, tiered, compressed class ptrs, parallel gc, linux-amd64) > > # Problematic frame: > > # V [libjvm.so+0xad6711] PhaseIdealLoop::build_loop_late_post_work(Node*, > bool)+0x101 > > # > > # No core dump will be written. Core dumps have been disabled. To enable core > dumping, try "ulimit -c unlimited" before starting Java again > > # > > # An error report file with more information is saved as: > > # > /home/jenkins/workspace/Lucene-main-Linux/lucene/codecs/build/tmp/tests-cwd/hs_err_pid1132974.log > > # > > # Compiler replay data is saved as: > > # > /home/jenkins/workspace/Lucene-main-Linux/lucene/codecs/build/tmp/tests-cwd/replay_pid1132974.log > > # > > # If you would like to submit a bug report, please visit: > > # https://github.com/adoptium/adoptium-support/issues > > # > > > > > > On Mon, May 16, 2022 at 12:30 AM Policeman Jenkins Server < > jenk...@thetaphi.de> wrote: > > Build: https://jenkins.thetaphi.de/job/Lucene-main-Linux/34604/ > Java: 64bit/jdk-17.0.2 -XX:-UseCompressedOops -XX:+UseParallelGC > > All tests passed > > - > To unsubscribe, e-mail: builds-unsubscr...@lucene.apache.org > For additional commands, e-mail: builds-h...@lucene.apache.org > >
Re: [JENKINS] Lucene » Lucene-Check-main - Build # 5746 - Failure!
I created the https://ci-builds.apache.org/job/Solr/job/lucene-solr-1-gradle-cache-cleanup job since a similar error was seen a few months ago: https://lists.apache.org/thread/jor6ct8l2vpq7x98hxdfn8xnp0ln6xqj It did fix the problem, but was never able to identify the root cause. Kevin Risden On Mon, Jun 6, 2022 at 9:56 AM Tomoko Uchida wrote: > I was able to log in to the ASF Jenkins Console and created this job > that just deletes the whole gradle cache folder on nodes that are > labeled "lucene" (please see the job configuration). > https://ci-builds.apache.org/job/Lucene/job/Clean%20up%20Gradle%20cache/ > > I didn't set a schedule for the job and haven't executed it yet (it > may affect all running Lucene jobs) but I think I or anyone with an > ASF account can manually run it. > > 2022年6月6日(月) 15:18 Dawid Weiss : > > > > > > This seems like a gradle cache problem somehow: > > > > Could not load compiled classes for script > '/home/jenkins/jenkins-slave/workspace/Lucene/Lucene-Check-main/gradle/validation/validate-source-patterns.gradle' > from cache. > > > > > > I'm not sure how to fix it on those agent machines - I see a jenkins job > with this name: > > > > > > > https://ci-builds.apache.org/job/Solr/job/lucene-solr-1-gradle-cache-cleanup > > > > > > But this is disabled... Has anybody experienced this before (whoever > created that job)? > > > > > > Dawid > > > > > > On Mon, Jun 6, 2022 at 6:54 AM Apache Jenkins Server < > jenk...@builds.apache.org> wrote: > >> > >> Build: > https://ci-builds.apache.org/job/Lucene/job/Lucene-Check-main/5746/ > >> > >> No tests ran. > >> > >> Build Log: > >> [...truncated 73 lines...] > >> BUILD FAILED in 12s > >> 2 actionable tasks: 2 executed > >> Build step 'Invoke Gradle script' changed build result to FAILURE > >> Build step 'Invoke Gradle script' marked build as failure > >> Archiving artifacts > >> Recording test results > >> ERROR: Step ‘Publish JUnit test result report’ failed: No test report > files were found. Configuration error? > >> Email was triggered for: Failure - Any > >> Sending email for trigger: Failure - Any > >> > >> - > >> To unsubscribe, e-mail: builds-unsubscr...@lucene.apache.org > >> For additional commands, e-mail: builds-h...@lucene.apache.org > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > >
Re: Solr Docker discussion
> > 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 options for this really. > >- _/solr - docker run solr:9.0 (Official Docker Image) >- apache/solr - docker run apache/solr:9.0 > > The benefits of the first are 1) the nice usability of being able to > plainly specify "solr" and 2) the "Docker Official Images" badge on > DockerHub. The downsides are that there are very strict requirements with > creating Official Docker Images, which would complicate and require > separating the way that we build release docker images and local docker > images. > > The benefits of using the apache namespace is that we can build the image > in any way that we want. We would be able to build release and local docker > images the exact same way. The downside is the loss of the "Docker Official > Images" badge. > > *I think there is some consensus that choosing the "apache/solr" location > is fine, and worth the added flexibility we get in the build process.* > > Legal Stuff > > There are a few legal questions we need to keep in mind when creating this > process and doing a release for the first time. > >- Source release - The apache policy is: (from Michael Sokolov) > >“Every ASF release MUST contain one or more source packages, which >>MUST be sufficient for a user to build and test the release provided they >>have access to the appropriate
Re: Our test failure rate is unacceptable.
HdfsAutoAddReplicasTest is just wrapping AutoAddReplicas tests with HDFS last I checked. There haven't been any HDFS changes lately that I've seen. So what changed in regards to AutoAddReplicas? Based on http://fucit.org/solr-jenkins-reports/history-trend-of-recent-failures.html#series/org.apache.solr.cloud.autoscaling.AutoAddReplicasIntegrationTest.testAddCollectionPropAfterCreation it looks like somewhere between 9/7 and 9/14. Kevin Risden On Fri, Sep 18, 2020 at 11:28 AM Atri Sharma wrote: > IMO if a temporary instability is to be introduced deliberately, it should > be published on the list. If it’s inadvertently added, we either fix it > within an hour or so or revert the offending commit. > > On Fri, 18 Sep 2020 at 20:26, Erick Erickson > wrote: > >> http://fucit.org/solr-jenkins-reports/failure-report.html >> >> >> >> HdfsAutoAddReplicasTest failing 100% of the time. >> >> TestPackages.classMethod failing 100% of the time >> >> 3-4 AutoAddReplicas tests failing 98% of the time. >> >> >> >> Is anyone looking at these? I realize the code base is changing a lot, >> and some temporary instability is to be expected. What I’d like is for some >> indication that people are actively addressing these. >> >> >> >> Erick >> >> - >> >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >> >> For additional commands, e-mail: dev-h...@lucene.apache.org >> >> >> >> -- > Regards, > > Atri > Apache Concerted >
Re: [VOTE] Lucene logo contest, third time's a charm
A1, A2, D (binding) Kevin Risden On Thu, Sep 3, 2020 at 4:44 PM jim ferenczi wrote: > A1 (binding) > > Le jeu. 3 sept. 2020 à 07:09, Noble Paul a écrit : > >> A1, A2, D binding >> >> On Thu, Sep 3, 2020 at 7:22 AM Jason Gerlowski >> wrote: >> > >> > A1, A2, D (binding) >> > >> > On Wed, Sep 2, 2020 at 10:47 AM Michael McCandless >> > wrote: >> > > >> > > A2, A1, C5, D (binding) >> > > >> > > Thank you to everyone for working so hard to make such cool looking >> possible future Lucene logos! And to Ryan for the challenging job of >> calling this VOTE :) >> > > >> > > Mike McCandless >> > > >> > > http://blog.mikemccandless.com >> > > >> > > >> > > On Tue, Sep 1, 2020 at 4:21 PM Ryan Ernst wrote: >> > >> >> > >> Dear Lucene and Solr developers! >> > >> >> > >> Sorry for the multiple threads. This should be the last one. >> > >> >> > >> In February a contest was started to design a new logo for Lucene >> [jira-issue]. The initial attempt [first-vote] to call a vote resulted in >> some confusion on the rules, as well the request for one additional >> submission. The second attempt [second-vote] yesterday had incorrect links >> for one of the submissions. I would like to call a new vote, now with more >> explicit instructions on how to vote, and corrected links. >> > >> >> > >> Please read the following rules carefully before submitting your >> vote. >> > >> >> > >> Who can vote? >> > >> >> > >> Anyone is welcome to cast a vote in support of their favorite >> submission(s). Note that only PMC member's votes are binding. If you are a >> PMC member, please indicate with your vote that the vote is binding, to >> ease collection of votes. In tallying the votes, I will attempt to verify >> only those marked as binding. >> > >> >> > >> How do I vote? >> > >> >> > >> Votes can be cast simply by replying to this email. It is a >> ranked-choice vote [rank-choice-voting]. Multiple selections may be made, >> where the order of preference must be specified. If an entry gets more than >> half the votes, it is the winner. Otherwise, the entry with the lowest >> number of votes is removed, and the votes are retallied, taking into >> account the next preferred entry for those whose first entry was removed. >> This process repeats until there is a winner. >> > >> >> > >> The entries are broken up by variants, since some entries have >> multiple color or style variations. The entry identifiers are first a >> capital letter, followed by a variation id (described with each entry >> below), if applicable. As an example, if you prefer variant 1 of entry A, >> followed by variant 2 of entry A, variant 3 of entry C, entry D, and lastly >> variant 4e of entry B, the following should be in your reply: >> > >> >> > >> (binding) >> > >> vote: A1, A2, C3, D, B4e >> > >> >> > >> Entries >> > >> >> > >> The entries are as follows: >> > >> >> > >> A. Submitted by Dustin Haver. This entry has two variants, A1 and A2. >> > >> >> > >> [A1] >> https://issues.apache.org/jira/secure/attachment/12999548/Screen%20Shot%202020-04-10%20at%208.29.32%20AM.png >> > >> [A2] >> https://issues.apache.org/jira/secure/attachment/12997172/LuceneLogo.png >> > >> >> > >> B. Submitted by Stamatis Zampetakis. This has several variants. >> Within the linked entry there are 7 patterns and 7 color palettes. Any vote >> for B should contain the pattern number followed by the lowercase letter of >> the color palette. For example, B3e or B1a. >> > >> >> > >> [B] >> https://issues.apache.org/jira/secure/attachment/12997768/zabetak-1-7.pdf >> > >> >> > >> C. Submitted by Baris Kazar. This entry has 8 variants. >> > >> >> > >> [C1] >> https://issues.apache.org/jira/secure/attachment/13006392/lucene_logo1_full.pdf >> > >> [C2] >> https://issues.apache.org/jira/secure/attachment/13006393/lucene_logo2_full.pdf >> > >> [C3] >> https://issues.apache.org/jira/secure/attachment/13006394/lucene_logo3_full.pdf >> > >> [C4] >> https://issues.apache.org/jira/secure
Re: BadApple report, but please read the first bit
http://fucit.org/solr-jenkins-reports/history-trend-of-recent-failures.html#series/org.apache.solr.cloud.SharedFSAutoReplicaFailoverTest.test David for that specific test you asked the failures are recent with as far as I know no change to HDFS stuff. Starting June/July failing regularly. Kevin Risden On Wed, Aug 12, 2020 at 9:03 AM Erick Erickson wrote: > I have the weekly rollups (with a few gaps) going back to about April > 2018, but nothing’s been done to try to make them generally available. Each > BadApple report has rates for the last 4 weeks in the attached file, just > below "Failures over the last 4 weeks, but not every week. Ordered > most-recent first:” > > > > > On Aug 12, 2020, at 2:06 AM, David Smiley wrote: > > > > Do we have any long term (aka "longitudinal") pass/fail rates for tests? > > > > SharedFSAutoReplicaFailoverTest in particular is kinda-sorta tied to > HDFS, and that's going away to a plug-in for 9.0. The shared file system > notion isn't well supported in SolrCloud, I think. > > > > ~ David Smiley > > Apache Lucene/Solr Search Developer > > http://www.linkedin.com/in/davidwsmiley > > > > > > On Mon, Aug 3, 2020 at 7:26 AM Erick Erickson > wrote: > > There are several tests that are causing a lot of noise: > > > > SharedFSAutoReplicaFailoverTest is failing 90%+ of the time. > > TestBulkSchemaConcurrent 31% > > StressHdfsTest 16% > > SchemaApiFailureTest 13.88% > > > > I encourage people to look at: > http://fucit.org/solr-jenkins-reports/failure-report.html and see if > anything looks like it is affected by recent work. TestBulkSchemaConcurrent > has been failing off and on for a long time, but the failure rate picked up > dramatically in the last couple of weeks. Ditto SchemaApiFailureTest. > > > > Do we even care about Hdfs? Are we deprecating it or not? > > > > Holding relatively steady otherwise: > > > > Raw fail count by week totals, most recent week first (corresponds to > bits): > > Week: 0 had 82 failures > > Week: 1 had 94 failures > > Week: 2 had 502 failures > > Week: 3 had 19 failures > > > > > > Failures in Hoss' reports for the last 4 rollups. > > > > There were 562 unannotated tests that failed in Hoss' rollups. Ordered > by the date I downloaded the rollup file, newest->oldest. See above for the > dates the files were collected > > These tests were NOT BadApple'd or AwaitsFix'd > > > > Failures in the last 4 reports.. > >Report Pct runsfails test > > 0123 0.3 1271 8 RollingRestartTest.test > > 0123 93.3 41 36 SharedFSAutoReplicaFailoverTest.test > > 0123 3.5 627 16 > TestCircuitBreaker.testBuildingMemoryPressure > > 0123 1.0 627 8 > TestCircuitBreaker.testResponseWithCBTiming > > 0123 5.8 1483 79 > TestContainerPlugin.testApiFromPackage > > 0123 2.3 1335 23 TestDistributedGrouping.test > > > > > > > > Full report: > > > > - > > 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: Welcome Ilan Ginzburg as Lucene/Solr committer
Congrats and welcome! Kevin Risden On Mon, Jun 22, 2020 at 11:37 AM Mike Drob wrote: > Welcome! > > On Mon, Jun 22, 2020 at 10:14 AM Namgyu Kim wrote: > >> Congrats and welcome, Ilan! :D >> >> On Tue, Jun 23, 2020 at 12:11 AM Houston Putman >> wrote: >> >>> Welcome Ilan! >>> >>> On Mon, Jun 22, 2020 at 9:53 AM Michael Sokolov >>> wrote: >>> >>>> Welcome Ilan! Nice beat on lonely boy there. >>>> >>>> >>>> On Mon, Jun 22, 2020, 9:45 AM Ilan Ginzburg wrote: >>>> >>>>> Thank you, merci, תודה for the trust and the welcome, Noble and >>>>> everybody! >>>>> >>>>> I’m based in France near Grenoble, a flat city high tech hub >>>>> surrounded by mountains. >>>>> >>>>> For the past 7 years I’ve been working on Search at Salesforce. >>>>> Currently focusing on SolrCloud scaling. >>>>> I also work on making Solr nodes stateless, separating compute from >>>>> storage to better fit Public Cloud environments (see >>>>> Activate '18 <https://youtu.be/UeTFpNeJ1Fo>, Activate '19 >>>>> <https://youtu.be/6fE5KvOfb6A>, SOLR-13101 >>>>> <https://github.com/apache/lucene-solr/tree/jira/SOLR-13101> WIP). >>>>> >>>>> Past employers include EMC/Documentum, HP Labs Palo Alto, Intel. >>>>> Earlier still I created the Apple 2 game Saracen (old timers here might >>>>> remember?). >>>>> >>>>> Other activities include a lot of paragliding, cycling, hiking, >>>>> drumming (here <https://youtu.be/-tZnpr3_VXU> during COVID) and a few >>>>> stints working as a photographer. >>>>> >>>>> I hold a MA in business administration and a PhD in computer science >>>>> (parallel computing). >>>>> >>>>> I’m extremely happy to join the Lucene/Solr community, the future >>>>> looks exciting! >>>>> >>>>> Ilan >>>>> >>>>> On Mon 22 Jun 2020 at 15:22, Joel Bernstein >>>>> wrote: >>>>> >>>>>> Welcome Ilan! >>>>>> >>>>>> >>>>>> Joel Bernstein >>>>>> http://joelsolr.blogspot.com/ >>>>>> >>>>>> >>>>>> On Mon, Jun 22, 2020 at 9:11 AM Michael McCandless < >>>>>> luc...@mikemccandless.com> wrote: >>>>>> >>>>>>> Welcome Ilan! >>>>>>> >>>>>>> Mike McCandless >>>>>>> >>>>>>> http://blog.mikemccandless.com >>>>>>> >>>>>>> >>>>>>> On Sun, Jun 21, 2020 at 5:44 AM Noble Paul wrote: >>>>>>> >>>>>>>> Hi all, >>>>>>>> >>>>>>>> Please join me in welcoming Ilan Ginzburg as the latest Lucene/Solr >>>>>>>> committer. >>>>>>>> Ilan, it's tradition for you to introduce yourself with a brief bio. >>>>>>>> >>>>>>>> Congratulations and Welcome! >>>>>>>> Noble >>>>>>>> >>>>>>>
Re: Welcome Mayya Sharipova as Lucene/Solr committer
Congrats and welcome Mayya! Kevin Risden On Mon, Jun 8, 2020 at 1:19 PM Erick Erickson wrote: > Welcome! > > > On Jun 8, 2020, at 1:11 PM, Ignacio Vera wrote: > > > > Congratulations Mayya! > > > > On Mon, Jun 8, 2020 at 7:04 PM Anshum Gupta > wrote: > > Congratulations and welcome, Mayya! > > > > On Mon, Jun 8, 2020 at 9:58 AM jim ferenczi wrote: > > Hi all, > > > > Please join me in welcoming Mayya Sharipova as the latest Lucene/Solr > committer. > > Mayya, it's tradition for you to introduce yourself with a brief bio. > > > > Congratulations and Welcome! > > > > Jim > > > > > > -- > > Anshum Gupta > > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > >
Re: [VOTE] Solr to become a top-level Apache project (TLP)
+1 (binding) Kevin Risden On Thu, May 14, 2020 at 12:17 PM Nicholas Knize wrote: > +1 (binding) > > Nicholas Knize, Ph.D., GISP > Geospatial Software Guy | Elasticsearch > Apache Lucene PMC Member and Committer > nkn...@apache.org > > > On Thu, May 14, 2020 at 11:02 AM Namgyu Kim wrote: > >> +1 >> >> On Thu, May 14, 2020 at 10:33 PM Tommaso Teofili < >> tommaso.teof...@gmail.com> wrote: >> >>> +1 (binding) >>> >>> Tommaso >>> >>> On Tue, 12 May 2020 at 09:37, Dawid Weiss wrote: >>> >>>> Dear Lucene and Solr developers! >>>> >>>> According to an earlier [DISCUSS] thread on the dev list [2], I am >>>> calling for a vote on the proposal to make Solr a top-level Apache >>>> project (TLP) and separate Lucene and Solr development into two >>>> independent entities. >>>> >>>> To quickly recap the reasons and consequences of such a move: it seems >>>> like the reasons for the initial merge of Lucene and Solr, around 10 >>>> years ago, have been achieved. Both projects are in good shape and >>>> exhibit signs of independence already (mailing lists, committers, >>>> patch flow). There are many technical considerations that would make >>>> development much easier if we move Solr out into its own TLP. >>>> >>>> We discussed this issue [2] and both PMC members and committers had a >>>> chance to review all the pros and cons and express their views. The >>>> discussion showed that there are clearly different opinions on the >>>> matter - some people are in favor, some are neutral, others are >>>> against or not seeing the point of additional labor. Realistically, I >>>> don't think reaching 100% level consensus is going to be possible -- >>>> we are a diverse bunch with different opinions and personalities. I >>>> firmly believe this is the right direction hence the decision to put >>>> it under the voting process. Should something take a wrong turn in the >>>> future (as some folks worry it may), all blame is on me. >>>> >>>> Therefore, the proposal is to separate Solr from under Lucene TLP, and >>>> make it a TLP on its own. The initial structure of the new PMC, >>>> committer base, git repositories and other managerial aspects can be >>>> worked out during the process if the decision passes. >>>> >>>> Please indicate one of the following (see [1] for guidelines): >>>> >>>> [ ] +1 - yes, I vote for the proposal >>>> [ ] -1 - no, I vote against the proposal >>>> >>>> Please note that anyone in the Lucene+Solr community is invited to >>>> express their opinion, though only Lucene+Solr committers cast binding >>>> votes (indicate non-binding votes in your reply, please). >>>> >>>> The vote will be active for a week to give everyone a chance to read >>>> and cast a vote. >>>> >>>> Dawid >>>> >>>> [1] https://www.apache.org/foundation/voting.html >>>> [2] >>>> https://lists.apache.org/thread.html/rfae2440264f6f874e91545b2030c98e7b7e3854ddf090f7747d338df%40%3Cdev.lucene.apache.org%3E >>>> >>>> - >>>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >>>> For additional commands, e-mail: dev-h...@lucene.apache.org >>>> >>>>
Re: [VOTE] Release Lucene/Solr 7.7.3 RC1
+1 SUCCESS! [1:38:36.140929]
Kevin Risden
On Tue, Apr 21, 2020 at 10:09 AM Ignacio Vera wrote:
>
> No issues here
>
> +1 SUCCESS! [1:20:57.847225]
>
> On Tue, Apr 21, 2020 at 3:33 PM Jan Høydahl wrote:
>>
>> SUCCESS! [1:05:02.194590]
>> No issues
>>
>> +1 (did not additional manual checking than running the smoketester)
>>
>> Jan
>>
>> > 21. apr. 2020 kl. 12:27 skrev Andrzej Białecki :
>> >
>> > Hi,
>> >
>> > I’m getting the following error, looks like the checksum doesn’t match the
>> > file:
>> >
>> > Test Solr...
>> > test basics...
>> > check changes HTML...
>> > download solr-7.7.3-src.tgz...
>> >56.9 MB in 586.29 sec (0.1 MB/sec)
>> >verify sha512 digest
>> > Traceback (most recent call last):
>> > File "dev-tools/scripts/smokeTestRelease.py", line 1518, in
>> >main()
>> > File "dev-tools/scripts/smokeTestRelease.py", line 1448, in main
>> >smokeTest(c.java, c.url, c.revision, c.version, c.tmp_dir, c.is_signed,
>> > c.local_keys, ' '.join(c.test_args))
>> > File "dev-tools/scripts/smokeTestRelease.py", line 1504, in smokeTest
>> >checkSigs('solr', solrPath, version, tmpDir, isSigned, keysFile)
>> > File "dev-tools/scripts/smokeTestRelease.py", line 366, in checkSigs
>> >verifyDigests(artifact, urlString, tmpDir)
>> > File "dev-tools/scripts/smokeTestRelease.py", line 556, in verifyDigests
>> >raise RuntimeError('SHA512 digest mismatch for %s: expected %s but got
>> > %s' % (artifact, sha512Expected, sha512Actual))
>> > RuntimeError: SHA512 digest mismatch for solr-7.7.3-src.tgz: expected
>> > 549ab2c35ecfba4610921f0951b3b78595da2bcb6e36da2f2a06828a64a01e656c8d424b4ba8d559b638ab62d871827f004f5f02b8e1eed3b9a0e0cbfd31e8ac
>> > but got
>> > 57a34207b6c742eae42cf5a0a15eb773d545902314c593c6f10794e6854e2c9ea6b252e9761da9ed5e13915882d6eddba87971495ff88c2cb643f523b6aaff77
>> >
>> >
>> >
>> >> On 21 Apr 2020, at 11:36, Noble Paul wrote:
>> >>
>> >> sorry, the direct command is
>> >>
>> >> python3 -u dev-tools/scripts/smokeTestRelease.py
>> >> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-7.7.3-RC1-rev1a0d2a901dfec93676b0fe8be425101ceb754b85/
>> >>
>> >> On Tue, Apr 21, 2020 at 6:15 PM Noble Paul wrote:
>> >>>
>> >>> Please vote for release candidate ? for Lucene/Solr 7.7.3
>> >>>
>> >>> The artifacts can be downloaded from:
>> >>> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-7.7.3-RC1-rev1a0d2a901dfec93676b0fe8be425101ceb754b85
>> >>>
>> >>> You can run the smoke tester directly with this command:
>> >>>
>> >>> python3 -u dev-tools/scripts/smokeTestRelease.py
>> >>> /tmp/releases/7.7.3/lucene-solr-7.7.3-RC1-rev1a0d2a901dfec93676b0fe8be425101ceb754b85
>> >>>
>> >>>
>> >>> Here's my +1
>> >>>
>> >>> SUCCESS! [1:48:02.520060]
>> >>>
>> >>> --
>> >>> -
>> >>> Noble Paul
>> >>
>> >>
>> >>
>> >> --
>> >> -
>> >> Noble Paul
>> >>
>> >> -
>> >> 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: BadApple report
> > 0123 59.4 195 92 HdfsSyncSliceTest.test I'm looking into this HdfsSyncSliceTest failure. Jira https://issues.apache.org/jira/browse/SOLR-13886 Kevin Risden Kevin Risden On Mon, Apr 13, 2020 at 8:35 AM Erick Erickson wrote: > We’re backsliding a bit. Note that over the last two weeks we’ve had > successively more failures, HdfsSyncSliceTest is failing over half the > time! Can we just nuke it? > > Here’s the short form > > aw fail count by week totals, most recent week first (corresponds to bits): > Week: 0 had 117 failures > Week: 1 had 99 failures > Week: 2 had 69 failures > Week: 3 had 65 failures > > > Failures in Hoss' reports for the last 4 rollups. > > There were 252 unannotated tests that failed in Hoss' rollups. Ordered by > the date I downloaded the rollup file, newest->oldest. See above for the > dates the files were collected > These tests were NOT BadApple'd or AwaitsFix'd > > Failures in the last 4 reports.. >Report Pct runsfails test > 0123 59.4 195 92 HdfsSyncSliceTest.test > 0123 0.5 1697 10 HttpPartitionWithTlogReplicasTest.test > 0123 6.1 133 12 > ShardSplitTest.testSplitWithChaosMonkey > 0123 1.8 1712 20 SyncSliceTest.test > 0123 2.5 1754 49 > SystemCollectionCompatTest.testBackCompat > 0123 0.5 1706 26 TestPackages.testPluginLoading > 0123 0.2 1676 4 TestSolrConfigHandlerCloud.test > > > > > > > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Welcome Eric Pugh as a Lucene/Solr committer
Welcome Eric! Kevin Risden On Mon, Apr 6, 2020 at 10:48 AM Alan Woodward wrote: > > Welcome Eric! > > > On 6 Apr 2020, at 13:21, Jan Høydahl wrote: > > > > Hi all, > > > > Please join me in welcoming Eric Pugh as the latest Lucene/Solr committer! > > > > Eric has been part of the Solr community for over a decade, as a code > > contributor, book author, company founder, blogger and mailing list > > contributor! We look forward to his future contributions! > > > > Congratulations and welcome! It is a tradition to introduce yourself with a > > brief bio, Eric. > > > > Jan Høydahl > > - > > 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: Welcome Alessandro Benedetti as a Lucene/Solr committer
Congrats and welcome Alessandro! Kevin Risden On Wed, Mar 18, 2020 at 10:42 AM Munendra S N wrote: > Congratulations Alessandro! > > > > On Wed, Mar 18, 2020 at 8:02 PM Houston Putman > wrote: > >> Congrats Alessandro! >> >> On Wed, Mar 18, 2020 at 10:07 AM Tommaso Teofili < >> tommaso.teof...@gmail.com> wrote: >> >>> welcome on board Alessandro, well deserved! >>> I still remember when we were sitting together in the same room having >>> fun with Lucene/Solr a few years ago, keep up the good job ! >>> >>> Regards, >>> Tommaso >>> >>> On Wed, 18 Mar 2020 at 14:01, David Smiley >>> wrote: >>> >>>> Hi all, >>>> >>>> Please join me in welcoming Alessandro Benedetti as the latest >>>> Lucene/Solr committer! >>>> >>>> Alessandro has been contributing to Lucene and Solr in areas such as >>>> More Like This, Synonym boosting, and Suggesters, and other areas for >>>> years. Furthermore he's been a help to many users on the solr-user mailing >>>> list and has helped others through his blog posts and presentations about >>>> search. We look forward to his future contributions. >>>> >>>> Congratulations and welcome! It is a tradition to introduce yourself >>>> with a brief bio, Alessandro. >>>> >>>> ~ David Smiley >>>> Apache Lucene/Solr Search Developer >>>> http://www.linkedin.com/in/davidwsmiley >>>> >>>
Re: [VOTE] Release Lucene/Solr 8.5.0 RC1
+1 SUCCESS! [1:24:43.574849] Kevin Risden On Mon, Mar 16, 2020 at 3:40 PM Nhat Nguyen wrote: > > +1 > > SUCCESS! [0:52:39.991003] > > On Mon, Mar 16, 2020 at 11:14 AM Cassandra Targett > wrote: >> >> I pushed the Solr Ref Guide DRAFT up this morning (thought I did it on >> Friday, sorry): https://lucene.apache.org/solr/guide/8_5/. >> >> Cassandra >> On Mar 15, 2020, 6:06 PM -0500, Uwe Schindler , wrote: >> >> Hi, >> >> I instructed Policeman Jenkins to automatically test the release for me, the >> result (Java 8 / Java 9 combined Smoketesting): >> >> SUCCESS! [1:24:47.422173] >> (see https://jenkins.thetaphi.de/job/Lucene-Solr-Release-Tester/30/console) >> >> I also downloaded the artifacts and tested manually: >> - Solr starts and stops perfectly on Windows with whitespace in path name: >> Java 8, Java 11 and Java 14 (coming out soon) >> - Javadocs of Lucene look fine >> - JAR files look good >> - All links to repos in pom.xml and ant use HTTPS >> >> So I am fine with releasing this. >> +1 to RELEASE! >> >> Uwe >> >> - >> Uwe Schindler >> Achterdiek 19, D-28357 Bremen >> https://www.thetaphi.de >> eMail: u...@thetaphi.de >> >> -Original Message- >> From: Alan Woodward >> Sent: Friday, March 13, 2020 3:27 PM >> To: dev@lucene.apache.org >> Subject: [VOTE] Release Lucene/Solr 8.5.0 RC1 >> >> Please vote for release candidate 1 for Lucene/Solr 8.5.0 >> >> The artifacts can be downloaded from: >> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.5.0-RC1- >> rev7ac489bf7b97b61749b19fa2ee0dc46e74b8dc42 >> >> 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.5.0-RC1- >> rev7ac489bf7b97b61749b19fa2ee0dc46e74b8dc42 >> >> The vote will be open for three working days i.e. until next Tuesday, >> 2020-03- >> 18 14: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 >> >> >> >> - >> 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: Upgrading Zookeeper?
Go with 3.5.7 since I am pretty sure we have some curator usage. I just looked at upgrading Apache Knox to Zookeeper 3.6.0 [1] and there are some curator/zk issues when testing. There is a curator ticket to update [2]. PS - Looks like there is a ticket for this already [3] going to comment there too. [1] https://issues.apache.org/jira/browse/KNOX-2283 [2] https://issues.apache.org/jira/browse/CURATOR-558 [3] https://issues.apache.org/jira/browse/SOLR-14312 Kevin Risden On Sun, Mar 8, 2020 at 5:36 PM Jörn Franke wrote: > Is the Kerberos authentication fixed for SSL connections in either of the > versions? > > > Am 08.03.2020 um 21:18 schrieb Erick Erickson : > > > > see: SOLR-14312 > > > > Short form: There have been some CVEs etc. fixed since 3.5.5, but then > > 3.6.0 was released. Should we upgrade to 3.5.7 or 3.6.0? If 3.6.0, now > > or wait? > > > > - > > 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: Welcome Nhat Nguyen to the PMC
Congrats and welcome Nhat! Kevin Risden On Tue, Mar 3, 2020 at 12:03 PM Alan Woodward wrote: > Congratulations and welcome Nhat! > > > On 3 Mar 2020, at 17:00, Steve Rowe wrote: > > > > Congrats and welcome Nhat! - Steve > > > >> On Mar 3, 2020, at 11:34 AM, Adrien Grand wrote: > >> > >> I am pleased to announce that Nhat Nguyen has accepted the PMC's > invitation to join. > >> > >> Welcome Nhat! > >> > >> -- > >> Adrien > > > > > > - > > 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: Congratulations to the new Lucene/Solr PMC Chair, Anshum Gupta!
Congrats Anshum! Kevin Risden On Thu, Jan 16, 2020 at 7:30 PM Joel Bernstein wrote: > Congrats Anshum! > > Joel Bernstein > http://joelsolr.blogspot.com/ > > > On Thu, Jan 16, 2020 at 1:05 PM Christine Poerschke (BLOOMBERG/ LONDON) < > cpoersc...@bloomberg.net> wrote: > >> Congrats Anshum! >> >> Christine >> >> From: dev@lucene.apache.org At: 01/15/20 21:15:28 >> To: dev@lucene.apache.org >> Subject: Congratulations to the new Lucene/Solr PMC Chair, Anshum Gupta! >> >> Every year, the Lucene PMC rotates the Lucene PMC chair and Apache Vice >> President position. >> >> This year we have nominated and elected Anshum Gupta as the Chair, a >> decision that the board approved in its January 2020 meeting. >> >> Congratulations, Anshum! >> >> Cassandra >> >> >>
Re: [VOTE] Release Lucene/Solr 8.4.0 RC2
+1 SUCCESS! [1:09:53.172567] Kevin Risden On Fri, Dec 20, 2019 at 9:15 AM Uwe Schindler wrote: > Hi, > > > > I instructed Policeman Jenkins to do the mechanic tests for me: > > https://jenkins.thetaphi.de/job/Lucene-Solr-Release-Tester/28/console > > > > Result: > > SUCCESS! [2:33:17.003383] > > Finished: SUCCESS > > > > He tested 2 Java versions and it looks like he was happy. > > > > I then reviewed Changes and Javadocs: Looks fine. I also started Solr with > whitespace in my username on Windows and it booted up successfully in Java > 8, 11 and 14 EA. > > > > *+1 to release as Lucene/Solr 8.4.0* > > > > Uwe > > > > - > > Uwe Schindler > > Achterdiek 19, D-28357 Bremen > > https://www.thetaphi.de > > eMail: u...@thetaphi.de > > > > *From:* Adrien Grand > *Sent:* Friday, December 20, 2019 12:23 AM > *To:* Lucene Dev > *Subject:* [VOTE] Release Lucene/Solr 8.4.0 RC2 > > > > Please vote for release candidate 2 for Lucene/Solr 8.4.0 > > The artifacts can be downloaded from: > > https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.4.0-RC2-revbc02ab906445fcf4e297f4ef00ab4a54fdd72ca2 > > 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.4.0-RC2-revbc02ab906445fcf4e297f4ef00ab4a54fdd72ca2 > > The vote will be open for at least 3 working days, i.e. until 2019-12-28 > 00:00 UTC. > > [ ] +1 approve > [ ] +0 no opinion > [ ] -1 disapprove (and reason why) > > Here is my +1 > > > > -- > > Adrien >
Re: New branch and feature freeze for Lucene/Solr 8.4.0
Adrien - there is a bug fix for Solr and TLS clientAuth - https://issues.apache.org/jira/browse/SOLR-14106. Based on the comments there don't think its required to respin 8.4.0. Is it ok to commit to branch_8_4 in case there is a need for a respin so it gets picked up? Otherwise I would expect it could be in a potential future 8.4.1 if someone volunteers as a RM. I don't want to mess up the 8.4.0 release so I'll hold off on branch_8_4 commit until I hear. Thanks! Kevin Risden On Tue, Dec 17, 2019 at 10:47 AM Adrien Grand wrote: > Go ahead Cassandra, I have built already, I'm now uploading the artifacts. > > On Tue, Dec 17, 2019 at 4:39 PM Cassandra Targett > wrote: > >> I’m going to have a few commits coming in to branch_8_4 today for the Ref >> Guide - I’m assuming as usual it’s OK for me to go ahead but if you want me >> to hold for a short time while you’re building or whatever, I will. >> On Dec 16, 2019, 9:35 AM -0600, Adrien Grand , wrote: >> >> Awesome, thanks Ishan. >> >> On Mon, Dec 16, 2019 at 4:14 PM Ishan Chattopadhyaya < >> ichattopadhy...@gmail.com> wrote: >> >>> Adrien, I've pushed a fix for that issue. The failure was probably due >>> to usual flakiness, but hopefully you won't see the exception for that >>> test that Dawid reported. >>> I don't think it should be a blocker anymore (the other problem is >>> that a test is trying to write data to source tree; I think that can >>> be solved later). >>> >>> On Mon, Dec 16, 2019 at 8:42 PM Adrien Grand wrote: >>> > >>> > Could someone look at https://issues.apache.org/jira/browse/SOLR-14096 >>> which Dawid just opened? It looks to me like it should be a blocker? >>> > >>> > On Mon, Dec 16, 2019 at 1:55 PM Adrien Grand >>> wrote: >>> >> >>> >> I have to rebuild because of SOLR-14094, so I'll include SOLR-14087 >>> too. >>> >> >>> >> On Mon, Dec 16, 2019 at 1:52 PM Ishan Chattopadhyaya < >>> ichattopadhy...@gmail.com> wrote: >>> >>> >>> >>> Hi Adrien, >>> >>> I reverted one of the changes in SOLR-14087, and backported to 8.4 >>> >>> branch. Apologies for the last moment change. >>> >>> If RC1 goes out without this change, no worries and we'll deal with >>> it later. >>> >>> Thanks and regards, >>> >>> Ishan >>> >>> >>> >>> On Mon, Dec 16, 2019 at 3:50 PM Ishan Chattopadhyaya >>> >>> wrote: >>> >>> > >>> >>> > Hi Adrien, >>> >>> > Let's push it to 8.5. >>> >>> > +1 to proceed for RC1. >>> >>> > Thanks, >>> >>> > Ishan >>> >>> > >>> >>> > On Mon, 16 Dec, 2019, 2:07 PM Adrien Grand, >>> wrote: >>> >>> >> >>> >>> >> Among the various JIRAs mentioned above, it looks like only >>> https://issues.apache.org/jira/browse/SOLR-14066 is not in yet. Please >>> let me know if there are other JIRAs that you are thinking of getting it >>> that have not been pushed yet, but in general I'd like to start pushing >>> changes to 8.5 whenever possible to avoid delaying the release too much. >>> >>> >> >>> >>> >> On Sun, Dec 15, 2019 at 1:17 PM Noble Paul >>> wrote: >>> >>> >>> >>> >>> >>> I plan to commit the following as well. >>> >>> >>> It's just a precautionery measure to avoid any future exploits >>> >>> >>> https://github.com/apache/lucene-solr/pull/1085 >>> >>> >>> >>> >>> >>> On Sun, Dec 15, 2019 at 4:32 PM Ishan Chattopadhyaya >>> >>> >>> wrote: >>> >>> >>> > >>> >>> >>> > I've added a few critical fixes for SOLR-13662 to the branch. >>> I tested >>> >>> >>> > them thoroughly and got reviews for the fixes from Jan, Noble >>> and >>> >>> >>> > Eduardo. >>> >>> >>> > >>> >>> >>> > On Sun, Dec 15, 2019 at 5:18 AM Adrien Grand < >>> jpou...@gmail.com> wrote: >>> >>> >>> > > >>> >>> >>> > > Hi Kevin, >>> >>> >>> > > >>> >
Re: Paying attention to deprecation warnings
There is some "prior work" in this area [1] and [2]. Not specifically about deprecations, but the idea is the same. Use the tools we have like the java compiler to prevent future issues. Yes its going to be work to get to fewer warnings, but we need to make sure that new ones get added. [1] https://issues.apache.org/jira/browse/LUCENE-7631 [2] https://issues.apache.org/jira/browse/SOLR-9629 Kevin Risden On Wed, Dec 18, 2019 at 12:47 PM Erick Erickson wrote: > This’ll be a bit tricky as long as we have Java required 11 on master and > Java 8 on 8x, we’ll have to sort out the deprecations due to the JDK .vs. > everything else. > > That said, +1 to fixing this up, it’s been on my TODO list for, oh, 2 > years or so, but keeps sliding. A hackathon would be a great venue since > there’ll be a zillion changes. > > Is there a way we can, once we have all the deprecation warnings out of a > file, somehow fail precommit/test/build/whatever when deprecations sneak > back in? It’d have to be on a file-by-file basis I’d guess, but that way we > could keep from backsliding. > > You can convince IntelliJ (and I’m sure Eclipse) to show deprecation > warnings when you pick the “recompile this file” which I recently started > using. > > Ditto with precommit warnings…. > > > On Dec 18, 2019, at 4:48 AM, Jan Høydahl wrote: > > > > Hi > > > > Our project compiles and runs with tons of deprecation warnings. > > > > Recently when working on SOLR-14106 and SOLR-14105 we found that there > has been jetty deprecation warnings in the logs ever since the 8.2 release, > and these were early warnings that something was wrong, so not > surprisingly, to get SSL working again in 8.5 the fix was to remove use of > deprecated classes in Jetty. > > > > It may be a too ambitious goal to remove all use of deprecated APIs. But > what about doing a hackaton to try to nail many of them! I bet we find some > real bugs during that process as well. > > > > Jan > > > - > 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.4.0
Tim found SOLR-14086 which looks like a test only dependency leaking into compile caused by SOLR-14033. I put a patch up. I won't get to get it until later tonight or tomorrow ~24hrs from now. This causes any Solr Tika usage with 7z or a few other compressed file types (depends if they use commons-compress) to fail due to different classloaders being used. Kevin Risden On Sat, Dec 14, 2019 at 2:09 PM Jan Høydahl wrote: > Deprecation of DIH is ready for review > https://issues.apache.org/jira/browse/SOLR-14066 > One code change which is a WARN log at startup, other changes are > documentation. > > Low risk and we’d like to deprecate sooner rather than later in 8.x. Your > call Adrien. > > Jan > > 13. des. 2019 kl. 10:03 skrev Adrien Grand : > > Let's get that one in as well, thanks Yonik. > > On Fri, Dec 13, 2019 at 2:26 AM Yonik Seeley wrote: > >> Heads up on https://issues.apache.org/jira/browse/SOLR-14079 >> Bad bug (autoscale triggers use async, so splitByPrefix does not work.) . >> The fix is super simple and very low risk since it's encapsulated within >> the block only used when splitByPrefix=true. >> >> -Yonik >> >> > > -- > Adrien > > >
Re: What should go into license/ folders? (important)
https://www.apache.org/legal/release-policy.html#licensing-documentation Based on reading the above, I think we need to have licenses and notices for everything that ends up in the distribution unless they are downloaded separately. So based on that I agree with your 3 answers. Kevin Risden On Fri, Dec 13, 2019 at 8:34 AM Dawid Weiss wrote: > I'm porting jar checksums to gradle and it's a bit like trying to > reconstruct this from scratch: > > > https://en.wikipedia.org/wiki/The_Tower_of_Babel_(Bruegel)#/media/File:Pieter_Bruegel_the_Elder_-_The_Tower_of_Babel_(Vienna)_-_Google_Art_Project.jpg > > We have dangling files, references to JARs no longer used... It's a mess. > > I'll clean it up but I need to know the following so that its consistent: > > 1) Do we include checksums and licenses of JARs that are only part of > the build? For example, solr-ref-guide has a number of esoteric > dependencies that are not really part of the "distribution". > > 2) Do we include checksums and licenses of JARs that are only used in > tests? JUnit, mocks, etc. > > 3) Should Solr include all licenses (and checksums) of Lucene > dependencies or can we exclude them and only focus on Solr's own > dependencies? Lucene dependencies are still verified and have licenses > but only under lucene/licenses (not in both projects). > > My picks are: > > 1) no, we don't include non-code (build-only) dependencies under licenses/. > 2) yes, we include checksums of test JARs (so that we can be sure > builds are running the same stuff on different machines), > 3) no, Solr's licenses/ folder should only include Solr's own > dependencies. Lucene license files (and possibly JAR checksums) can be > added to Solr distribution package but don't have to be stored/ > versioned/ verified twice. > > Dawid > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > >
Re: BadApples
Yes the "e-mail-2019-12-09.txt" attachment made it through. Many of the tests have failed due to the tightening of the security manager permissions for tests [1]. Most of the failures have been due to failing to null out static variables after a test run [2]. Others are real issues like TestSolrCLIRunExample [3] or the Hadoop related failures [4]. There are others that haven't been triaged yet. Rob has been putting in a lot of effort to try to get this under control as well. Getting the tests to run under the security manager is the first step to trying to enable it for real in Solr. Any help triaging the failures would be appreciated. If you are looking to triage some of the test failures, adding -Dargs="-Djava.security.debug=access,failure" can help find out why the security manager denied access. Some of the failures are different between OS as well where security manager allows the path on Linux but fails on Windows. [1] https://issues.apache.org/jira/browse/SOLR-13991 [2] https://issues.apache.org/jira/browse/SOLR-14000 [3] https://issues.apache.org/jira/browse/SOLR-14028 [4] https://issues.apache.org/jira/browse/SOLR-14033 Kevin Risden On Mon, Dec 9, 2019 at 10:43 AM Erick Erickson wrote: > I’ve attached the full report, but this has been a _really_ ragged week. > Take a look here for the gory details of what’s failing currently: > http://fucit.org/solr-jenkins-reports/failure-report.html > > > The tests that have failed over the last 4 consecutive weeks are: > > Failures in the last 4 reports.. >Report Pct runsfails test > 0123 0.6 784 10 > DimensionalRoutedAliasUpdateProcessorTest.testCatTime > 0123 5.6 743 56 > LegacyCloudClusterPropTest.testCreateCollectionSwitchLegacyCloud > 0123 63.2 101 53 MoveReplicaHDFSTest.test > 0123 6.7 85 5 > ShardSplitTest.testSplitWithChaosMonkey > 0123 2.4 714 9 > SystemCollectionCompatTest.testBackCompat > 0123 9.4 795 47 > TestModelManagerPersistence.testFilePersistence > 0123 9.4 797 49 > TestModelManagerPersistence.testWrapperModelPersistence > 0123 1.5 724 10 TestStressLiveNodes.testStress > Will BadApple all tests above this line except ones listed at > the top** > > Do the attachments even make it through? > > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Welcome Bruno Roustant as Lucene/Solr committer
Congrats and welcome! Kevin Risden On Sat, Nov 23, 2019, 18:00 Jan Høydahl wrote: > Welcome Bruno! > > -- > Jan Høydahl, search solution architect > Cominvent AS - www.cominvent.com > > 23. nov. 2019 kl. 09:29 skrev Adrien Grand : > > Hi all, > > Please join me in welcoming Bruno Roustant as the latest Lucene/Solr > committer! > > It didn't take many JIRA issues for Bruno to demonstrate good > understanding of the lower level bits of Lucene by writing a new > postings format and more recently exploring ideas that ended up > speeding up FSTs while decreasing their memory usage at the same time. > We are very happy that Bruno accepted the PMC's invitation to join. > > Congratulations and welcome, Bruno! It's a tradition to introduce > yourself with a brief bio. > > -- > Adrien > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > > For additional commands, e-mail: dev-h...@lucene.apache.org > > > >
Re: [JENKINS] Lucene-Solr-8.x-Linux (32bit/jdk1.8.0_201) - Build # 1487 - Failure!
I get changed files on master after running the commands before precommit: ➜ lucene-solr git:(master) ✗ git status On branch master Your branch is up to date with 'origin/master'. Changes not staged for commit: (use "git add/rm ..." to update what will be committed) (use "git restore ..." to discard changes in working directory) deleted: solr/core/src/test-files/solr/question-answer-repository/question-answer-request-handler-1.0.jar deleted: solr/core/src/test-files/solr/question-answer-repository/question-answer-request-handler-1.1.jar no changes added to commit (use "git add" and/or "git commit -a") Kevin Risden On Thu, Nov 14, 2019 at 5:21 PM Kevin Risden wrote: > Ishan do you get an error with the following? > > ant clean clean-jars jar-checksums precommit > > This should regenerate any of the checksums. I haven't checked locally but > might help. > > Kevin Risden > > > On Thu, Nov 14, 2019 at 4:48 PM Ishan Chattopadhyaya < > ichattopadhy...@gmail.com> wrote: > >> No clue why licenses are being checked for those jars. Those are test >> jars. I never got a precommit failure. >> ALso, it seems licenses are not actually tested, but somehow those >> sha1 files are generated but not cleaned up. Sigh! I think I have no >> clue where to even start looking to solve this issue. >> >> On Fri, Nov 15, 2019 at 2:19 AM Policeman Jenkins Server >> wrote: >> > >> > Build: https://jenkins.thetaphi.de/job/Lucene-Solr-8.x-Linux/1487/ >> > Java: 32bit/jdk1.8.0_201 -client -XX:+UseG1GC >> > >> > All tests passed >> > >> > Build Log: >> > [...truncated 64469 lines...] >> > BUILD FAILED >> > /home/jenkins/workspace/Lucene-Solr-8.x-Linux/build.xml:634: The >> following error occurred while executing this line: >> > /home/jenkins/workspace/Lucene-Solr-8.x-Linux/build.xml:507: The >> following error occurred while executing this line: >> > /home/jenkins/workspace/Lucene-Solr-8.x-Linux/build.xml:494: Source >> checkout is dirty (unversioned/missing files) after running tests!!! >> Offending files: >> > * solr/licenses/question-answer-request-handler-1.0.jar.sha1 >> > * solr/licenses/question-answer-request-handler-1.1.jar.sha1 >> > >> > Total time: 129 minutes 26 seconds >> > Build step 'Invoke Ant' marked build as failure >> > Archiving artifacts >> > Setting >> ANT_1_8_2_HOME=/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2 >> > [WARNINGS] Skipping publisher since build result is FAILURE >> > Recording test results >> > Setting >> ANT_1_8_2_HOME=/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2 >> > Email was triggered for: Failure - Any >> > Sending email for trigger: Failure - Any >> > Setting >> ANT_1_8_2_HOME=/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2 >> > Setting >> ANT_1_8_2_HOME=/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2 >> > Setting >> ANT_1_8_2_HOME=/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2 >> > Setting >> ANT_1_8_2_HOME=/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2 >> > Setting >> ANT_1_8_2_HOME=/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2 >> > Setting >> ANT_1_8_2_HOME=/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2 >> > >> > - >> > To unsubscribe, e-mail: builds-unsubscr...@lucene.apache.org >> > For additional commands, e-mail: builds-h...@lucene.apache.org >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >> For additional commands, e-mail: dev-h...@lucene.apache.org >> >>
Re: [JENKINS] Lucene-Solr-8.x-Linux (32bit/jdk1.8.0_201) - Build # 1487 - Failure!
Ishan do you get an error with the following? ant clean clean-jars jar-checksums precommit This should regenerate any of the checksums. I haven't checked locally but might help. Kevin Risden On Thu, Nov 14, 2019 at 4:48 PM Ishan Chattopadhyaya < ichattopadhy...@gmail.com> wrote: > No clue why licenses are being checked for those jars. Those are test > jars. I never got a precommit failure. > ALso, it seems licenses are not actually tested, but somehow those > sha1 files are generated but not cleaned up. Sigh! I think I have no > clue where to even start looking to solve this issue. > > On Fri, Nov 15, 2019 at 2:19 AM Policeman Jenkins Server > wrote: > > > > Build: https://jenkins.thetaphi.de/job/Lucene-Solr-8.x-Linux/1487/ > > Java: 32bit/jdk1.8.0_201 -client -XX:+UseG1GC > > > > All tests passed > > > > Build Log: > > [...truncated 64469 lines...] > > BUILD FAILED > > /home/jenkins/workspace/Lucene-Solr-8.x-Linux/build.xml:634: The > following error occurred while executing this line: > > /home/jenkins/workspace/Lucene-Solr-8.x-Linux/build.xml:507: The > following error occurred while executing this line: > > /home/jenkins/workspace/Lucene-Solr-8.x-Linux/build.xml:494: Source > checkout is dirty (unversioned/missing files) after running tests!!! > Offending files: > > * solr/licenses/question-answer-request-handler-1.0.jar.sha1 > > * solr/licenses/question-answer-request-handler-1.1.jar.sha1 > > > > Total time: 129 minutes 26 seconds > > Build step 'Invoke Ant' marked build as failure > > Archiving artifacts > > Setting > ANT_1_8_2_HOME=/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2 > > [WARNINGS] Skipping publisher since build result is FAILURE > > Recording test results > > Setting > ANT_1_8_2_HOME=/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2 > > Email was triggered for: Failure - Any > > Sending email for trigger: Failure - Any > > Setting > ANT_1_8_2_HOME=/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2 > > Setting > ANT_1_8_2_HOME=/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2 > > Setting > ANT_1_8_2_HOME=/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2 > > Setting > ANT_1_8_2_HOME=/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2 > > Setting > ANT_1_8_2_HOME=/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2 > > Setting > ANT_1_8_2_HOME=/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2 > > > > - > > To unsubscribe, e-mail: builds-unsubscr...@lucene.apache.org > > For additional commands, e-mail: builds-h...@lucene.apache.org > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > >
Re: Welcome Houston Putman as Lucene/Solr committer
Congrats and welcome! Kevin Risden On Thu, Nov 14, 2019, 12:05 Jason Gerlowski wrote: > Congratulations! > > On Thu, Nov 14, 2019 at 11:58 AM Gus Heck wrote: > > > > Congratulations and welcome :) > > > > On Thu, Nov 14, 2019 at 11:52 AM Namgyu Kim wrote: > >> > >> Congratulations and welcome, Houston! :D > >> > >> On Fri, Nov 15, 2019 at 1:18 AM Ken LaPorte > wrote: > >>> > >>> Congratulations Houston! Well deserved honor. > >>> > >>> > >>> > >>> -- > >>> 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 > >>> > > > > > > -- > > 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: Zookeeper "Persistent Recursive Watch"
Curator is adding support for it as well to speed up some of the existing recipes. (one of the curator devs developed the persistent recursive watch feature as far as I can tell). I think Zookeeper and Curator are trying to get releases out by the end of the year from what I have been reading on the mailing lists/Slack. Kevin Risden On Mon, Nov 11, 2019 at 3:22 PM David Smiley wrote: > FYI, a big new feature landed in ZooKeeper just recently, "Persistent > Recursive Watch" -- https://issues.apache.org/jira/browse/ZOOKEEPER-1416 > The fix-version is 3.6.0. > > ~ David Smiley > Apache Lucene/Solr Search Developer > http://www.linkedin.com/in/davidwsmiley >
Re: precommit failures
Created https://issues.apache.org/jira/browse/LUCENE-9041 - will post a patch hopefully today. I'll look at 8.x as well. Kevin Risden On Sat, Nov 9, 2019 at 5:41 PM Uwe Schindler wrote: > Interesting, 8.x uses 3.18... 樂 > > So let's upgrade both. > > Uwe > > Am November 9, 2019 10:38:33 PM UTC schrieb Uwe Schindler >: >> >> Yes should be easy possible. Just make sure it passes build (and use >> latest version). >> >> Not sure if branch 8.x is affected, but if the same ecj version is used >> there, upgrade it, too. >> >> Uwe >> >> Am November 9, 2019 9:26:42 PM UTC schrieb Kevin Risden < >> kris...@apache.org>: >>> >>> I saw this happen again and on a whim did some googling to see if it was >>> reported/fixed: >>> >>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=547181 >>> >>> and a duplicate >>> >>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=550263 >>> >>> These both seem to think that this is fixed in a September build, which >>> I think would be >>> >>> >>> org.eclipse.jdt >>> ecj >>> 3.19.0 >>> >>> >>> The current Lucene build version is 3.17.0: >>> >>> >>> https://github.com/apache/lucene-solr/blob/master/lucene/common-build.xml#L2039 >>> >>> Is it possible that it is simple to just upgrade the ecj version? >>> >>> Kevin Risden >>> >>> >>> On Thu, Jun 13, 2019 at 6:42 PM Chris Hostetter < >>> hossman_luc...@fucit.org> wrote: >>> >>>> >>>> So, FWIW: these ecj/precommit ERRORS related to "javax.naming.*" >>>> packages/classes still seems to be happening periodically >>>> but unpredictibly & unreliably... >>>> >>>> 1) speaking persnally: it happens on my machine periodically, even with >>>> "ant clean precommit" and then goes away the very next time i run "ant >>>> clean precommit" -- w/o any changes to the source code, working dir, >>>> java >>>> version, etc... >>>> >>>> openjdk version "11.0.2" 2019-01-15 >>>> OpenJDK Runtime Environment 18.9 (build 11.0.2+9) >>>> OpenJDK 64-Bit Server VM 18.9 (build 11.0.2+9, mixed mode) >>>> >>>> (It's possible it relates to something in the ivy cache, but if so, it >>>> can >>>> aparently "self fix" or "self break" w/o any other java processes >>>> running >>>> on on the machine in the meantime) >>>> >>>> 2) It also happens periodically to jenkins builds, as recently as >>>> yesterday, on multiple jenkins clusters and diff build OSs... >>>> >>>> https://jenkins.thetaphi.de/job/Lucene-Solr-master-MacOSX/5195/ >>>> https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/7988/ >>>> https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/24208/ >>>> https://builds.apache.org/job/Lucene-Solr-Tests-master/3365/ >>>> https://builds.apache.org/job/Lucene-Solr-SmokeRelease-master/1360/ >>>> >>>> ...that's just a handful of examples from the past few days, in >>>> generally >>>> ERRORs that start with "The type javax.naming." seem to pop up on at >>>> least >>>> 1 jenkins build a day. >>>> >>>> The only commonality seems to be builds of *master* using jdk11 >>>> ... it doesn't seem to pop up in any 8x builds (even when using >>>> jdk11 i think because precommit on 8x doesn't do this check >>>> anymore?) >>>> and it doesn't show up in Policeman master builds using jdk12 & jdk13 >>>> >>>> anybody have any idea WTF is happening here? >>>> >>>> >>>> >>>> >>>> : Date: Mon, 06 May 2019 20:25:46 + >>>> : From: Uwe Schindler >>>> : Reply-To: dev@lucene.apache.org >>>> : To: dev@lucene.apache.org, Erick Erickson >>>> : Subject: Re: precommit failures >>>> : >>>> : I am not fully sure if the "java.naming" module is enabled by default >>>> in Java 11. Maybe that's a side effect of some global configuration >>>> parameter. >>>> : >>>> : Is Java version really fully identical including vendor? >>>> : >>>> : The strange thing is that only ecj breaks. Could it be
Re: precommit failures
I saw this happen again and on a whim did some googling to see if it was reported/fixed: https://bugs.eclipse.org/bugs/show_bug.cgi?id=547181 and a duplicate https://bugs.eclipse.org/bugs/show_bug.cgi?id=550263 These both seem to think that this is fixed in a September build, which I think would be org.eclipse.jdt ecj 3.19.0 The current Lucene build version is 3.17.0: https://github.com/apache/lucene-solr/blob/master/lucene/common-build.xml#L2039 Is it possible that it is simple to just upgrade the ecj version? Kevin Risden On Thu, Jun 13, 2019 at 6:42 PM Chris Hostetter wrote: > > So, FWIW: these ecj/precommit ERRORS related to "javax.naming.*" > packages/classes still seems to be happening periodically > but unpredictibly & unreliably... > > 1) speaking persnally: it happens on my machine periodically, even with > "ant clean precommit" and then goes away the very next time i run "ant > clean precommit" -- w/o any changes to the source code, working dir, java > version, etc... > > openjdk version "11.0.2" 2019-01-15 > OpenJDK Runtime Environment 18.9 (build 11.0.2+9) > OpenJDK 64-Bit Server VM 18.9 (build 11.0.2+9, mixed mode) > > (It's possible it relates to something in the ivy cache, but if so, it can > aparently "self fix" or "self break" w/o any other java processes running > on on the machine in the meantime) > > 2) It also happens periodically to jenkins builds, as recently as > yesterday, on multiple jenkins clusters and diff build OSs... > > https://jenkins.thetaphi.de/job/Lucene-Solr-master-MacOSX/5195/ > https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/7988/ > https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/24208/ > https://builds.apache.org/job/Lucene-Solr-Tests-master/3365/ > https://builds.apache.org/job/Lucene-Solr-SmokeRelease-master/1360/ > > ...that's just a handful of examples from the past few days, in generally > ERRORs that start with "The type javax.naming." seem to pop up on at least > 1 jenkins build a day. > > The only commonality seems to be builds of *master* using jdk11 > ... it doesn't seem to pop up in any 8x builds (even when using > jdk11 i think because precommit on 8x doesn't do this check anymore?) > and it doesn't show up in Policeman master builds using jdk12 & jdk13 > > anybody have any idea WTF is happening here? > > > > > : Date: Mon, 06 May 2019 20:25:46 + > : From: Uwe Schindler > : Reply-To: dev@lucene.apache.org > : To: dev@lucene.apache.org, Erick Erickson > : Subject: Re: precommit failures > : > : I am not fully sure if the "java.naming" module is enabled by default in > Java 11. Maybe that's a side effect of some global configuration parameter. > : > : Is Java version really fully identical including vendor? > : > : The strange thing is that only ecj breaks. Could it be that you have > older version of ecj in ant's classpath? > : > : Uwe > : > : Am May 6, 2019 7:47:45 PM UTC schrieb Erick Erickson < > erickerick...@gmail.com>: > : >Weirder and weirder. My mac pro precommits successfully, same Java > : >version but my MBP fails every time. > : > > : >> On May 6, 2019, at 9:03 AM, Dawid Weiss > : >wrote: > : >> > : >> I had it this morning before committing the fst patch from Mike. > : >> Cleaned the repo, re-ran precommit and it passed... Very strange. > : >> > : >> D. > : >> > : >> On Mon, May 6, 2019 at 5:53 PM Erick Erickson > : > wrote: > : >>> > : >>> > : >>> Both Kevin Risden and I are seeing: > : >>> > : >>> [ecj-lint] 1. ERROR in > : > >/Users/Erick/apache/solrVersions/playspace/solr/contrib/dataimporthandler/src/java/org/apache/solr/handler/dataimport/JdbcDataSource.java > : >(at line 28) > : >>> [ecj-lint] import javax.naming.InitialContext; > : >>> [ecj-lint]^^^ > : >>> [ecj-lint] The type javax.naming.InitialContext is not accessible``` > : >>> > : >>> This import hasn’t been changed since 2009. > : >>> > : >>> I'm using: openjdk version “11.0.2” 2019-01-15 > : >>> > : >>> I tried a fresh clone of master and cleaned the ivy cache, still the > : >same problem. But we can't be the only ones seeing this, any clues? > : >>> > : >- > : >>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > : >>> For additional commands, e-m
Re: CVE-2018-11768 in regards to Solr
Solr interacts with Hadoop only as a client. (except in integration tests). >From the https://hadoop.apache.org/cve_list.html page, this looks like it is only an issue in the fsimage which is server side for the Namenode. I don't think that CVE-2018-11768 applies to Solr directly. CVE-2018-11768 Apache Hadoop HDFS FSImage Corruption There is a mismatch in the size of the fields used to store user/group information between memory and disk representation. This causes the user/group information to be corrupted across storing in fsimage and reading back from fsimage. This vulnerability fix contains a fsimage layout change, so once the image is saved in the new layout format you cannot go back to a version that doesn’t support the newer layout. This means that once 2.7.x users upgraded to the fixed version, they cannot downgrade to 2.7.x because there is no fixed version in 2.7.x. We suggest downgrade to 2.8.5 or upper version that contains the vulnerability fix. Kevin Risden On Tue, Oct 29, 2019 at 12:52 PM Kyle Gerald Lamkin wrote: > Hello Solr Devs, > > > > I'm looking for some information about CVE-2018-11768, a Hadoop > vulnerability. In 7.7.2 Solr ships with Hadoop 2.7.4 which is affected, the > closest fixed version is 2.8.5. Solr 8.x ships with Hadoop 3.2 which is not > affected. > > > > I was unable to find an Jira item for this, should I open one for it or is > it not applicable? > > > > Thanks for your time. > > > Regards, > > *Kyle (K.G.) Lamkin* > -- > E-mail: kyle.lam...@ibm.com > > > - 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.3.0 RC2
+1 SUCCESS! [1:34:11.886834] Kevin Risden On Mon, Oct 28, 2019 at 3:43 AM Ignacio Vera wrote: > +1 > > > SUCCESS! [1:13:16.262824] > > On Mon, Oct 28, 2019 at 6:07 AM Shalin Shekhar Mangar < > shalinman...@gmail.com> wrote: > >> +1 >> >> SUCCESS! [1:26:27.659346] >> >> On Sat, Oct 26, 2019 at 12:02 AM Ishan Chattopadhyaya < >> ichattopadhy...@gmail.com> wrote: >> >>> Please vote for release candidate 2 for Lucene/Solr 8.3.0 >>> >>> The artifacts can be downloaded from: >>> >>> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.3.0-RC2-rev2aa586909b911e66e1d8863aa89f173d69f86cd2 >>> >>> 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.3.0-RC2-rev2aa586909b911e66e1d8863aa89f173d69f86cd2 >>> >>> The vote will be open for at least 3 working days, i.e. until >>> 2019-10-30 19: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 >>> >>> >> >> -- >> Regards, >> Shalin Shekhar Mangar. >> >
Re: Welcome Atri Sharma as Lucene/Solr committer
Congrats and welcome Atri! Kevin Risden On Wed, Sep 18, 2019 at 11:05 AM Yonik Seeley wrote: > Congrats Atri! > > -Yonik > > > On Wed, Sep 18, 2019 at 3:12 AM Adrien Grand wrote: > >> Hi all, >> >> Please join me in welcoming Atri Sharma as Lucene/ Solr committer! >> >> If you are following activity on Lucene, this name will likely sound >> familiar to you: Atri has been very busy trying to improve Lucene over >> the past months. In particular, Atri recently started improving our >> top-hits optimizations like early termination on sorted indexes and >> WAND, when indexes are searched using multiple threads. >> >> Congratulations and welcome! It is a tradition to introduce yourself >> with a brief bio. >> >> -- >> Adrien >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >> For additional commands, e-mail: dev-h...@lucene.apache.org >> >>
[jira] [Updated] (SOLR-13726) Krb5HttpClientBuilder avoid setting javax.security.auth.useSubjectCredsOnly
[ https://issues.apache.org/jira/browse/SOLR-13726?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Risden updated SOLR-13726: Component/s: security > Krb5HttpClientBuilder avoid setting javax.security.auth.useSubjectCredsOnly > --- > > Key: SOLR-13726 > URL: https://issues.apache.org/jira/browse/SOLR-13726 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: security, SolrJ >Reporter: Kevin Risden >Priority: Major > > Solr should avoid setting system properties that affect the entire JVM. > Specifically "javax.security.auth.useSubjectCredsOnly" is one that can cause > a bunch of issues if SolrJ is colocated with other Kerberos secured services. > Krb5HttpClientBuilder changes the JVM default to false if it is not set. It > is defaulting to true. This affects everything in the JVM. Since SolrJ is > meant to be client side, we should avoid doing this. > [https://github.com/apache/lucene-solr/blame/master/solr/solrj/src/java/org/apache/solr/client/solrj/impl/Krb5HttpClientBuilder.java#L144] -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13726) Krb5HttpClientBuilder avoid setting javax.security.auth.useSubjectCredsOnly
[ https://issues.apache.org/jira/browse/SOLR-13726?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16923533#comment-16923533 ] Kevin Risden commented on SOLR-13726: - NIFI-5148 handled this specifically for NiFi to avoid the JVM property change in Krb5HttpClientBuilder > Krb5HttpClientBuilder avoid setting javax.security.auth.useSubjectCredsOnly > --- > > Key: SOLR-13726 > URL: https://issues.apache.org/jira/browse/SOLR-13726 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrJ >Reporter: Kevin Risden >Priority: Major > > Solr should avoid setting system properties that affect the entire JVM. > Specifically "javax.security.auth.useSubjectCredsOnly" is one that can cause > a bunch of issues if SolrJ is colocated with other Kerberos secured services. > Krb5HttpClientBuilder changes the JVM default to false if it is not set. It > is defaulting to true. This affects everything in the JVM. Since SolrJ is > meant to be client side, we should avoid doing this. > [https://github.com/apache/lucene-solr/blame/master/solr/solrj/src/java/org/apache/solr/client/solrj/impl/Krb5HttpClientBuilder.java#L144] -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13726) Krb5HttpClientBuilder avoid setting javax.security.auth.useSubjectCredsOnly
[ https://issues.apache.org/jira/browse/SOLR-13726?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16918808#comment-16918808 ] Kevin Risden commented on SOLR-13726: - [~anshum] - curious if you have any opinions/thoughts here on not setting the useSubjectCredsOnly system property. I don't have a patch yet - since I think overall this needs a bit more thought about how we handle Kerberos in SolrJ. Ideally we wrap every SolrJ call internally with the explicit subject. This would avoid having to fall back to the JVM JAAS config unless explicitly required. The Hadoop UserGroupInformation class wraps a lot of the ugly internals of JVM JAAS configs, but it is a pretty heavy dependency to bring into SolrJ (its part of hadoop-common). But it might give some ideas on how to better handle this. > Krb5HttpClientBuilder avoid setting javax.security.auth.useSubjectCredsOnly > --- > > Key: SOLR-13726 > URL: https://issues.apache.org/jira/browse/SOLR-13726 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrJ >Reporter: Kevin Risden >Priority: Major > > Solr should avoid setting system properties that affect the entire JVM. > Specifically "javax.security.auth.useSubjectCredsOnly" is one that can cause > a bunch of issues if SolrJ is colocated with other Kerberos secured services. > Krb5HttpClientBuilder changes the JVM default to false if it is not set. It > is defaulting to true. This affects everything in the JVM. Since SolrJ is > meant to be client side, we should avoid doing this. > [https://github.com/apache/lucene-solr/blame/master/solr/solrj/src/java/org/apache/solr/client/solrj/impl/Krb5HttpClientBuilder.java#L144] -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13726) Krb5HttpClientBuilder avoid setting javax.security.auth.useSubjectCredsOnly
[ https://issues.apache.org/jira/browse/SOLR-13726?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16918806#comment-16918806 ] Kevin Risden commented on SOLR-13726: - Some references about useSubjectCredsOnly: * Source where default is true - http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/687fd7c7986d/src/share/classes/sun/security/jgss/GSSUtil.java#l259 * ugly issue where causes hung threads - https://risdenk.github.io/2018/03/15/hdf-apache-nifi-kerberos-errors-usesubjectcredsonly.html > Krb5HttpClientBuilder avoid setting javax.security.auth.useSubjectCredsOnly > --- > > Key: SOLR-13726 > URL: https://issues.apache.org/jira/browse/SOLR-13726 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Reporter: Kevin Risden >Priority: Major > > Solr should avoid setting system properties that affect the entire JVM. > Specifically "javax.security.auth.useSubjectCredsOnly" is one that can cause > a bunch of issues if SolrJ is colocated with other Kerberos secured services. > Krb5HttpClientBuilder changes the JVM default to false if it is not set. It > is defaulting to true. This affects everything in the JVM. Since SolrJ is > meant to be client side, we should avoid doing this. > [https://github.com/apache/lucene-solr/blame/master/solr/solrj/src/java/org/apache/solr/client/solrj/impl/Krb5HttpClientBuilder.java#L144] -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-13726) Krb5HttpClientBuilder avoid setting javax.security.auth.useSubjectCredsOnly
[ https://issues.apache.org/jira/browse/SOLR-13726?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Risden updated SOLR-13726: Component/s: SolrJ > Krb5HttpClientBuilder avoid setting javax.security.auth.useSubjectCredsOnly > --- > > Key: SOLR-13726 > URL: https://issues.apache.org/jira/browse/SOLR-13726 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrJ >Reporter: Kevin Risden >Priority: Major > > Solr should avoid setting system properties that affect the entire JVM. > Specifically "javax.security.auth.useSubjectCredsOnly" is one that can cause > a bunch of issues if SolrJ is colocated with other Kerberos secured services. > Krb5HttpClientBuilder changes the JVM default to false if it is not set. It > is defaulting to true. This affects everything in the JVM. Since SolrJ is > meant to be client side, we should avoid doing this. > [https://github.com/apache/lucene-solr/blame/master/solr/solrj/src/java/org/apache/solr/client/solrj/impl/Krb5HttpClientBuilder.java#L144] -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13726) Krb5HttpClientBuilder avoid setting javax.security.auth.useSubjectCredsOnly
[ https://issues.apache.org/jira/browse/SOLR-13726?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16918804#comment-16918804 ] Kevin Risden commented on SOLR-13726: - SOLR-7468 introduced this a long time ago. This came up recently while trying to debug an issue where the JVM hangs looking for Kerberos credentials. javax.security.auth.useSubjectCredsOnly=false causes this behavior. We should therefore definitely avoid setting the property. The warning should be enough to help correct this. In an ideal world, the SolrJ kerberos handling would automatically set the Java Subject and not have to worry about this setting being configured at all. > Krb5HttpClientBuilder avoid setting javax.security.auth.useSubjectCredsOnly > --- > > Key: SOLR-13726 > URL: https://issues.apache.org/jira/browse/SOLR-13726 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Reporter: Kevin Risden >Priority: Major > > Solr should avoid setting system properties that affect the entire JVM. > Specifically "javax.security.auth.useSubjectCredsOnly" is one that can cause > a bunch of issues if SolrJ is colocated with other Kerberos secured services. > Krb5HttpClientBuilder changes the JVM default to false if it is not set. It > is defaulting to true. This affects everything in the JVM. Since SolrJ is > meant to be client side, we should avoid doing this. > [https://github.com/apache/lucene-solr/blame/master/solr/solrj/src/java/org/apache/solr/client/solrj/impl/Krb5HttpClientBuilder.java#L144] -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-13726) Krb5HttpClientBuilder avoid setting javax.security.auth.useSubjectCredsOnly
Kevin Risden created SOLR-13726: --- Summary: Krb5HttpClientBuilder avoid setting javax.security.auth.useSubjectCredsOnly Key: SOLR-13726 URL: https://issues.apache.org/jira/browse/SOLR-13726 Project: Solr Issue Type: Bug Security Level: Public (Default Security Level. Issues are Public) Reporter: Kevin Risden Solr should avoid setting system properties that affect the entire JVM. Specifically "javax.security.auth.useSubjectCredsOnly" is one that can cause a bunch of issues if SolrJ is colocated with other Kerberos secured services. Krb5HttpClientBuilder changes the JVM default to false if it is not set. It is defaulting to true. This affects everything in the JVM. Since SolrJ is meant to be client side, we should avoid doing this. [https://github.com/apache/lucene-solr/blame/master/solr/solrj/src/java/org/apache/solr/client/solrj/impl/Krb5HttpClientBuilder.java#L144] -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-9952) S3BackupRepository
[ https://issues.apache.org/jira/browse/SOLR-9952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16903955#comment-16903955 ] Kevin Risden commented on SOLR-9952: [~suryakant.jadhav] - this is the wrong place to ask. Use the solr-user mailing list for questions [1]. Solr 4.10.3 is old and most likely will not work backing up to S3. [1] https://lucene.apache.org/solr/community.html#mailing-lists-irc > S3BackupRepository > -- > > Key: SOLR-9952 > URL: https://issues.apache.org/jira/browse/SOLR-9952 > Project: Solr > Issue Type: New Feature > Components: Backup/Restore >Reporter: Mikhail Khludnev >Priority: Major > Attachments: > 0001-SOLR-9952-Added-dependencies-for-hadoop-amazon-integ.patch, > 0002-SOLR-9952-Added-integration-test-for-checking-backup.patch, Running Solr > on S3.pdf, core-site.xml.template > > > I'd like to have a backup repository implementation allows to snapshot to AWS > S3 -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-6305) Ability to set the replication factor for index files created by HDFSDirectoryFactory
[
https://issues.apache.org/jira/browse/SOLR-6305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevin Risden updated SOLR-6305:
---
Resolution: Fixed
Status: Resolved (was: Patch Available)
> Ability to set the replication factor for index files created by
> HDFSDirectoryFactory
> -
>
> Key: SOLR-6305
> URL: https://issues.apache.org/jira/browse/SOLR-6305
> Project: Solr
> Issue Type: Improvement
> Components: Hadoop Integration, hdfs
> Environment: hadoop-2.2.0
>Reporter: Timothy Potter
>Assignee: Kevin Risden
>Priority: Major
> Fix For: 8.3
>
> Attachments:
> 0001-OIQ-23224-SOLR-6305-Fixed-SOLR-6305-by-reading-the-r.patch,
> SOLR-6305.patch
>
>
> HdfsFileWriter doesn't allow us to create files in HDFS with a different
> replication factor than the configured DFS default because it uses:
> {{FsServerDefaults fsDefaults = fileSystem.getServerDefaults(path);}}
> Since we have two forms of replication going on when using
> HDFSDirectoryFactory, it would be nice to be able to set the HDFS replication
> factor for the Solr directories to a lower value than the default. I realize
> this might reduce the chance of data locality but since Solr cores each have
> their own path in HDFS, we should give operators the option to reduce it.
> My original thinking was to just use Hadoop setrep to customize the
> replication factor, but that's a one-time shot and doesn't affect new files
> created. For instance, I did:
> {{hadoop fs -setrep -R 1 solr49/coll1}}
> My default dfs replication is set to 3 ^^ I'm setting it to 1 just as an
> example
> Then added some more docs to the coll1 and did:
> {{hadoop fs -stat %r solr49/hdfs1/core_node1/data/index/segments_3}}
> 3 <-- should be 1
> So it looks like new files don't inherit the repfact from their parent
> directory.
> Not sure if we need to go as far as allowing different replication factor per
> collection but that should be considered if possible.
> I looked at the Hadoop 2.2.0 code to see if there was a way to work through
> this using the Configuration object but nothing jumped out at me ... and the
> implementation for getServerDefaults(path) is just:
> public FsServerDefaults getServerDefaults(Path p) throws IOException {
> return getServerDefaults();
> }
> Path is ignored ;-)
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-6305) Ability to set the replication factor for index files created by HDFSDirectoryFactory
[
https://issues.apache.org/jira/browse/SOLR-6305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevin Risden updated SOLR-6305:
---
Fix Version/s: 8.3
> Ability to set the replication factor for index files created by
> HDFSDirectoryFactory
> -
>
> Key: SOLR-6305
> URL: https://issues.apache.org/jira/browse/SOLR-6305
> Project: Solr
> Issue Type: Improvement
> Components: Hadoop Integration, hdfs
> Environment: hadoop-2.2.0
>Reporter: Timothy Potter
>Assignee: Kevin Risden
>Priority: Major
> Fix For: 8.3
>
> Attachments:
> 0001-OIQ-23224-SOLR-6305-Fixed-SOLR-6305-by-reading-the-r.patch,
> SOLR-6305.patch
>
>
> HdfsFileWriter doesn't allow us to create files in HDFS with a different
> replication factor than the configured DFS default because it uses:
> {{FsServerDefaults fsDefaults = fileSystem.getServerDefaults(path);}}
> Since we have two forms of replication going on when using
> HDFSDirectoryFactory, it would be nice to be able to set the HDFS replication
> factor for the Solr directories to a lower value than the default. I realize
> this might reduce the chance of data locality but since Solr cores each have
> their own path in HDFS, we should give operators the option to reduce it.
> My original thinking was to just use Hadoop setrep to customize the
> replication factor, but that's a one-time shot and doesn't affect new files
> created. For instance, I did:
> {{hadoop fs -setrep -R 1 solr49/coll1}}
> My default dfs replication is set to 3 ^^ I'm setting it to 1 just as an
> example
> Then added some more docs to the coll1 and did:
> {{hadoop fs -stat %r solr49/hdfs1/core_node1/data/index/segments_3}}
> 3 <-- should be 1
> So it looks like new files don't inherit the repfact from their parent
> directory.
> Not sure if we need to go as far as allowing different replication factor per
> collection but that should be considered if possible.
> I looked at the Hadoop 2.2.0 code to see if there was a way to work through
> this using the Configuration object but nothing jumped out at me ... and the
> implementation for getServerDefaults(path) is just:
> public FsServerDefaults getServerDefaults(Path p) throws IOException {
> return getServerDefaults();
> }
> Path is ignored ;-)
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-6305) Ability to set the replication factor for index files created by HDFSDirectoryFactory
[
https://issues.apache.org/jira/browse/SOLR-6305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevin Risden updated SOLR-6305:
---
Attachment: SOLR-6305.patch
> Ability to set the replication factor for index files created by
> HDFSDirectoryFactory
> -
>
> Key: SOLR-6305
> URL: https://issues.apache.org/jira/browse/SOLR-6305
> Project: Solr
> Issue Type: Improvement
> Components: Hadoop Integration, hdfs
> Environment: hadoop-2.2.0
>Reporter: Timothy Potter
>Assignee: Kevin Risden
>Priority: Major
> Attachments:
> 0001-OIQ-23224-SOLR-6305-Fixed-SOLR-6305-by-reading-the-r.patch,
> SOLR-6305.patch
>
>
> HdfsFileWriter doesn't allow us to create files in HDFS with a different
> replication factor than the configured DFS default because it uses:
> {{FsServerDefaults fsDefaults = fileSystem.getServerDefaults(path);}}
> Since we have two forms of replication going on when using
> HDFSDirectoryFactory, it would be nice to be able to set the HDFS replication
> factor for the Solr directories to a lower value than the default. I realize
> this might reduce the chance of data locality but since Solr cores each have
> their own path in HDFS, we should give operators the option to reduce it.
> My original thinking was to just use Hadoop setrep to customize the
> replication factor, but that's a one-time shot and doesn't affect new files
> created. For instance, I did:
> {{hadoop fs -setrep -R 1 solr49/coll1}}
> My default dfs replication is set to 3 ^^ I'm setting it to 1 just as an
> example
> Then added some more docs to the coll1 and did:
> {{hadoop fs -stat %r solr49/hdfs1/core_node1/data/index/segments_3}}
> 3 <-- should be 1
> So it looks like new files don't inherit the repfact from their parent
> directory.
> Not sure if we need to go as far as allowing different replication factor per
> collection but that should be considered if possible.
> I looked at the Hadoop 2.2.0 code to see if there was a way to work through
> this using the Configuration object but nothing jumped out at me ... and the
> implementation for getServerDefaults(path) is just:
> public FsServerDefaults getServerDefaults(Path p) throws IOException {
> return getServerDefaults();
> }
> Path is ignored ;-)
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6305) Ability to set the replication factor for index files created by HDFSDirectoryFactory
[
https://issues.apache.org/jira/browse/SOLR-6305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16899024#comment-16899024
]
Kevin Risden commented on SOLR-6305:
Updated patch from [~bpasko] with commit message and CHANGES. Looking at
committing soon.
> Ability to set the replication factor for index files created by
> HDFSDirectoryFactory
> -
>
> Key: SOLR-6305
> URL: https://issues.apache.org/jira/browse/SOLR-6305
> Project: Solr
> Issue Type: Improvement
> Components: Hadoop Integration, hdfs
> Environment: hadoop-2.2.0
>Reporter: Timothy Potter
>Assignee: Kevin Risden
>Priority: Major
> Attachments:
> 0001-OIQ-23224-SOLR-6305-Fixed-SOLR-6305-by-reading-the-r.patch,
> SOLR-6305.patch
>
>
> HdfsFileWriter doesn't allow us to create files in HDFS with a different
> replication factor than the configured DFS default because it uses:
> {{FsServerDefaults fsDefaults = fileSystem.getServerDefaults(path);}}
> Since we have two forms of replication going on when using
> HDFSDirectoryFactory, it would be nice to be able to set the HDFS replication
> factor for the Solr directories to a lower value than the default. I realize
> this might reduce the chance of data locality but since Solr cores each have
> their own path in HDFS, we should give operators the option to reduce it.
> My original thinking was to just use Hadoop setrep to customize the
> replication factor, but that's a one-time shot and doesn't affect new files
> created. For instance, I did:
> {{hadoop fs -setrep -R 1 solr49/coll1}}
> My default dfs replication is set to 3 ^^ I'm setting it to 1 just as an
> example
> Then added some more docs to the coll1 and did:
> {{hadoop fs -stat %r solr49/hdfs1/core_node1/data/index/segments_3}}
> 3 <-- should be 1
> So it looks like new files don't inherit the repfact from their parent
> directory.
> Not sure if we need to go as far as allowing different replication factor per
> collection but that should be considered if possible.
> I looked at the Hadoop 2.2.0 code to see if there was a way to work through
> this using the Configuration object but nothing jumped out at me ... and the
> implementation for getServerDefaults(path) is just:
> public FsServerDefaults getServerDefaults(Path p) throws IOException {
> return getServerDefaults();
> }
> Path is ignored ;-)
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-6305) Ability to set the replication factor for index files created by HDFSDirectoryFactory
[
https://issues.apache.org/jira/browse/SOLR-6305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevin Risden updated SOLR-6305:
---
Status: Patch Available (was: Open)
> Ability to set the replication factor for index files created by
> HDFSDirectoryFactory
> -
>
> Key: SOLR-6305
> URL: https://issues.apache.org/jira/browse/SOLR-6305
> Project: Solr
> Issue Type: Improvement
> Components: Hadoop Integration, hdfs
> Environment: hadoop-2.2.0
>Reporter: Timothy Potter
>Assignee: Kevin Risden
>Priority: Major
> Attachments:
> 0001-OIQ-23224-SOLR-6305-Fixed-SOLR-6305-by-reading-the-r.patch
>
>
> HdfsFileWriter doesn't allow us to create files in HDFS with a different
> replication factor than the configured DFS default because it uses:
> {{FsServerDefaults fsDefaults = fileSystem.getServerDefaults(path);}}
> Since we have two forms of replication going on when using
> HDFSDirectoryFactory, it would be nice to be able to set the HDFS replication
> factor for the Solr directories to a lower value than the default. I realize
> this might reduce the chance of data locality but since Solr cores each have
> their own path in HDFS, we should give operators the option to reduce it.
> My original thinking was to just use Hadoop setrep to customize the
> replication factor, but that's a one-time shot and doesn't affect new files
> created. For instance, I did:
> {{hadoop fs -setrep -R 1 solr49/coll1}}
> My default dfs replication is set to 3 ^^ I'm setting it to 1 just as an
> example
> Then added some more docs to the coll1 and did:
> {{hadoop fs -stat %r solr49/hdfs1/core_node1/data/index/segments_3}}
> 3 <-- should be 1
> So it looks like new files don't inherit the repfact from their parent
> directory.
> Not sure if we need to go as far as allowing different replication factor per
> collection but that should be considered if possible.
> I looked at the Hadoop 2.2.0 code to see if there was a way to work through
> this using the Configuration object but nothing jumped out at me ... and the
> implementation for getServerDefaults(path) is just:
> public FsServerDefaults getServerDefaults(Path p) throws IOException {
> return getServerDefaults();
> }
> Path is ignored ;-)
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (SOLR-6305) Ability to set the replication factor for index files created by HDFSDirectoryFactory
[
https://issues.apache.org/jira/browse/SOLR-6305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevin Risden reassigned SOLR-6305:
--
Assignee: Kevin Risden
> Ability to set the replication factor for index files created by
> HDFSDirectoryFactory
> -
>
> Key: SOLR-6305
> URL: https://issues.apache.org/jira/browse/SOLR-6305
> Project: Solr
> Issue Type: Improvement
> Components: Hadoop Integration, hdfs
> Environment: hadoop-2.2.0
>Reporter: Timothy Potter
>Assignee: Kevin Risden
>Priority: Major
> Attachments:
> 0001-OIQ-23224-SOLR-6305-Fixed-SOLR-6305-by-reading-the-r.patch
>
>
> HdfsFileWriter doesn't allow us to create files in HDFS with a different
> replication factor than the configured DFS default because it uses:
> {{FsServerDefaults fsDefaults = fileSystem.getServerDefaults(path);}}
> Since we have two forms of replication going on when using
> HDFSDirectoryFactory, it would be nice to be able to set the HDFS replication
> factor for the Solr directories to a lower value than the default. I realize
> this might reduce the chance of data locality but since Solr cores each have
> their own path in HDFS, we should give operators the option to reduce it.
> My original thinking was to just use Hadoop setrep to customize the
> replication factor, but that's a one-time shot and doesn't affect new files
> created. For instance, I did:
> {{hadoop fs -setrep -R 1 solr49/coll1}}
> My default dfs replication is set to 3 ^^ I'm setting it to 1 just as an
> example
> Then added some more docs to the coll1 and did:
> {{hadoop fs -stat %r solr49/hdfs1/core_node1/data/index/segments_3}}
> 3 <-- should be 1
> So it looks like new files don't inherit the repfact from their parent
> directory.
> Not sure if we need to go as far as allowing different replication factor per
> collection but that should be considered if possible.
> I looked at the Hadoop 2.2.0 code to see if there was a way to work through
> this using the Configuration object but nothing jumped out at me ... and the
> implementation for getServerDefaults(path) is just:
> public FsServerDefaults getServerDefaults(Path p) throws IOException {
> return getServerDefaults();
> }
> Path is ignored ;-)
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
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.2.0 RC1
+1 SUCCESS! [1:37:46.956358] Kevin Risden On Mon, Jul 22, 2019 at 9:41 AM Atri Sharma wrote: > +1 (non binding) > > +1 SUCCESS! [1:17:24.828393] > > On Mon, Jul 22, 2019 at 7:07 PM Adrien Grand wrote: > > > > Non binding indeed, but we appreciate help with testing releases! > > > > On Mon, Jul 22, 2019 at 3:03 PM Tomoko Uchida > > wrote: > > > > > > +1 SUCCESS! [1:31:37.834967] > > > (maybe non-binding) > > > > > > And Luke works fine. > > > > > > 2019年7月21日(日) 21:52 Uwe Schindler : > > > > > > > > Java 13 also worked. > > > > > > > > > > > > > > > > - > > > > > > > > Uwe Schindler > > > > > > > > Achterdiek 19, D-28357 Bremen > > > > > > > > https://www.thetaphi.de > > > > > > > > eMail: u...@thetaphi.de > > > > > > > > > > > > > > > > From: Uwe Schindler > > > > Sent: Sunday, July 21, 2019 2:49 PM > > > > To: dev@lucene.apache.org > > > > Subject: RE: [VOTE] Release Lucene/Solr 8.2.0 RC1 > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > I asked Policeman to run the smoke tester on my behalf, he responded: > > > > > > > > > > > > > > > > SUCCESS! [3:04:23.084427] > > > > > > > > > > > > > > > > (this was testing Java 8 and Java 9 module system). More details, > see here: > https://jenkins.thetaphi.de/job/Lucene-Solr-Release-Tester/25/console > > > > > > > > > > > > > > > > I was also able to start Solr on Java 8 and Java 11 on Windows and > index example documents. I also analyzed some Korean text, all fine. I also > tried to run a custom plugin (query parsing and analysis) for one of my > customers: worked. As I did not recompile it, it verifies that the analysis > factory backwards break was prevented. > > > > > > > > > > > > > > > > So +1 to release this. > > > > > > > > > > > > > > > > Uwe > > > > > > > > > > > > > > > > - > > > > > > > > Uwe Schindler > > > > > > > > Achterdiek 19, D-28357 Bremen > > > > > > > > https://www.thetaphi.de > > > > > > > > eMail: u...@thetaphi.de > > > > > > > > > > > > > > > > From: Ignacio Vera > > > > Sent: Friday, July 19, 2019 8:35 PM > > > > To: dev@lucene.apache.org > > > > Subject: [VOTE] Release Lucene/Solr 8.2.0 RC1 > > > > > > > > > > > > > > > > Please vote for release candidate 1 for Lucene/Solr 8.2.0 > > > > > > > > > > > > > > > > The artifacts can be downloaded from: > > > > > > > > > > > > > > > > > https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.2.0-RC1-rev31d7ec7bbfdcd2c4cc61d9d35e962165410b65fe > > > > > > > > > > > > > > > > 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.2.0-RC1-rev31d7ec7bbfdcd2c4cc61d9d35e962165410b65fe > > > > > > > > Here is my +1 > > > > > > > > SUCCESS! [1:19:01.246595] > > > > > > - > > > 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 > > > > > -- > Regards, > > Atri > Apache Concerted > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > >
[jira] [Commented] (SOLR-13587) Close BackupRepository after every usage
[
https://issues.apache.org/jira/browse/SOLR-13587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16876440#comment-16876440
]
Kevin Risden commented on SOLR-13587:
-
[~mkhludnev] - No I asked around and didn't seem to be any way to work around
the HDFS close stuff. Would need to be fixed in Hadoop first.
> Close BackupRepository after every usage
>
>
> Key: SOLR-13587
> URL: https://issues.apache.org/jira/browse/SOLR-13587
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Backup/Restore
>Affects Versions: 8.1
>Reporter: Mikhail Khludnev
>Assignee: Mikhail Khludnev
>Priority: Major
> Attachments: SOLR-13587.patch
>
>
> Turns out BackupRepository is created every operation, but never closed. I
> suppose it leads to necessity to have {{BadHdfsThreadsFilter}} in
> {{TestHdfsCloudBackupRestore}}. Also, test need to repeat backup/restore
> operation to make sure that closing hdfs filesystem doesn't break it see
> SOLR-9961 for the case.
--
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
Re: BadApple report
HdfsAutoAddReplicasIntegrationTest.testSimple I am going to awaitsfix this test - https://issues.apache.org/jira/browse/SOLR-13338. I haven't had time to look into recent failures. I thought the Jetty upgrade would have helped. It had very similar timeout waiting exception. Kevin Risden On Mon, Jul 1, 2019 at 12:13 PM Erick Erickson wrote: > Pretty steady, I won’t be doing anything with annotations this week: > > **Annotations will be removed from the following tests because they > haven't failed in the last 4 rollups. > > **Methods: 3 >FullSolrCloudDistribCmdsTest.test >MultiThreadedOCPTest.test >SolrZkClientTest.testSimpleUpdateACLs > > > Failures in Hoss' reports for the last 4 rollups. > > There were 585 unannotated tests that failed in Hoss' rollups. Ordered by > the date I downloaded the rollup file, newest->oldest. See above for the > dates the files were collected > These tests were NOT BadApple'd or AwaitsFix'd > All tests that failed 4 weeks running will be BadApple'd unless there are > objections > > Failures in the last 4 reports.. >Report Pct runsfails test > 0123 1.8 955 30 > AliasIntegrationTest.testClusterStateProviderAPI > 0123 0.5 972207 BasicAuthIntegrationTest.testBasicAuth > 0123 30.4 89 24 > HdfsAutoAddReplicasIntegrationTest.testSimple > 0123 0.4 921 10 HttpPartitionTest.test > 0123 0.9 924 12 NestedShardedAtomicUpdateTest.test > 0123 0.5 908 5 > ReindexCollectionTest.testBasicReindexing > 0123 0.9 928 12 RollingRestartTest.test > 0123 12.0 90 11 > ShardSplitTest.testSplitWithChaosMonkey > 0123 0.9 927 8 > SystemCollectionCompatTest.testBackCompat > 0123 0.5 926 23 > TestFieldCacheRewriteMethod.testRegexps > 0123 0.9 924 13 > TestSimpleSearchEquivalence.testBooleanBoostPropagation > 0123 0.9 924 15 > TestSimpleSearchEquivalence.testBoostQuerySimplification > 0123 0.4 924 8 > TestSimpleSearchEquivalence.testPhraseRelativePositions > 0123 0.4 924 9 > TestSimpleSearchEquivalence.testSloppyPhraseRelativePositions > 0123 1.8 908 14 TestTopDocsMerge.testSort_1 > Will BadApple all tests above this line except ones listed at > the top** > > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > >
Re: Re:Welcome Kevin Risden to the PMC
Thanks everyone! Kevin Risden On Sat, Jun 29, 2019 at 8:45 AM Martin Gainty wrote: > welcome Kevin! > > -- > *From:* Christine Poerschke (BLOOMBERG/ LONDON) > *Sent:* Friday, June 28, 2019 4:00 PM > *To:* dev@lucene.apache.org > *Subject:* Re:Welcome Kevin Risden to the PMC > > Welcome Kevin! > > From: dev@lucene.apache.org At: 06/27/19 13:04:23 > To: dev@lucene.apache.org > Subject: Welcome Kevin Risden to the PMC > > I am pleased to announce that Kevin Risden has accepted the PMC's > invitation to > join. > > Welcome Kevin! > > -- > Jan Høydahl, search solution architect > Cominvent AS - www.cominvent.com > > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > > >
[jira] [Commented] (SOLR-13587) Close BackupRepository after every usage
[
https://issues.apache.org/jira/browse/SOLR-13587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16875878#comment-16875878
]
Kevin Risden commented on SOLR-13587:
-
And when I say "can't" I mean literally there is no close option on an HDFS
filesystem instance. It leaks threads since the filesystem instance starts some
thread pools and has no close method to stop them. It would be great if we
could actually call close on an HDFS filesystem, but nope.
> Close BackupRepository after every usage
>
>
> Key: SOLR-13587
> URL: https://issues.apache.org/jira/browse/SOLR-13587
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Backup/Restore
>Affects Versions: 8.1
>Reporter: Mikhail Khludnev
>Assignee: Mikhail Khludnev
>Priority: Major
> Attachments: SOLR-13587.patch
>
>
> Turns out BackupRepository is created every operation, but never closed. I
> suppose it leads to necessity to have {{BadHdfsThreadsFilter}} in
> {{TestHdfsCloudBackupRestore}}. Also, test need to repeat backup/restore
> operation to make sure that closing hdfs filesystem doesn't break it see
> SOLR-9961 for the case.
--
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-13587) Close BackupRepository after every usage
[
https://issues.apache.org/jira/browse/SOLR-13587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16875877#comment-16875877
]
Kevin Risden commented on SOLR-13587:
-
Yea so HDFS filesystem instances can't be closed. Sadly. I looked into this as
part of SOLR-5007. I found the same thing that backup repositories don't
open/close things properly. Probably hidden by the fact that HDFS leaks threads.
> Close BackupRepository after every usage
>
>
> Key: SOLR-13587
> URL: https://issues.apache.org/jira/browse/SOLR-13587
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Backup/Restore
>Affects Versions: 8.1
>Reporter: Mikhail Khludnev
>Assignee: Mikhail Khludnev
>Priority: Major
> Attachments: SOLR-13587.patch
>
>
> Turns out BackupRepository is created every operation, but never closed. I
> suppose it leads to necessity to have {{BadHdfsThreadsFilter}} in
> {{TestHdfsCloudBackupRestore}}. Also, test need to repeat backup/restore
> operation to make sure that closing hdfs filesystem doesn't break it see
> SOLR-9961 for the case.
--
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
Re: Welcome Munendra S N as Lucene/Solr committer
Congrats and welcome Munendra! Kevin Risden On Tue, Jun 25, 2019 at 6:06 AM Christine Poerschke (BLOOMBERG/ LONDON) < cpoersc...@bloomberg.net> wrote: > Welcome Munendra! > > Christine > > From: dev@lucene.apache.org At: 06/21/19 14:50:57 > To: dev@lucene.apache.org > Subject: Re: Welcome Munendra S N as Lucene/Solr committer > > Thanks Ishan, and thank you everyone for this opportunity > I came across Lucene/Solr when I joined as Software Engineer at Unbxd. I > have been working with Lucene/Solr from past 3 years and started > contributing from past 2 years. > I'm delighted to be part of this great team. Looking forward to the > exciting times. > > Regards, > Munendra S N > > > On Fri, Jun 21, 2019 at 4:52 PM Jan Høydahl wrote: > >> Welcome Munendra! >> >> -- >> Jan Høydahl, search solution architect >> Cominvent AS - www.cominvent.com >> >> 21. jun. 2019 kl. 11:41 skrev Ishan Chattopadhyaya < >> ichattopadhy...@gmail.com>: >> >> Hi all, >> >> Please join me in welcoming Munendra as a Lucene/Solr committer! >> >> Munendra has been working on bug fixes and improvements in various >> parts of Solr. >> >> Congratulations and welcome! It is a tradition to introduce yourself >> with a brief bio, Munendra. >> >> Ishan >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >> >> For additional commands, e-mail: dev-h...@lucene.apache.org >> >> >> >> >
[jira] [Commented] (SOLR-12988) Known OpenJDK >= 11 SSL (TLSv1.3) bugs can cause problems with Solr
[
https://issues.apache.org/jira/browse/SOLR-12988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16870270#comment-16870270
]
Kevin Risden commented on SOLR-12988:
-
http://jdk.java.net/13/
There are release notes and other info about different builds. There are also
emails from JDK folks about certain builds from different phrases of the
release process.
> Known OpenJDK >= 11 SSL (TLSv1.3) bugs can cause problems with Solr
> ---
>
> Key: SOLR-12988
> URL: https://issues.apache.org/jira/browse/SOLR-12988
> Project: Solr
> Issue Type: Test
>Reporter: Hoss Man
>Assignee: Cao Manh Dat
>Priority: Major
> Labels: Java11, Java12, Java13
> Attachments: SOLR-12988.patch, SOLR-12988.patch, SOLR-13413.patch
>
>
> There are several known OpenJDK JVM bugs (begining with Java11, when TLS v1.3
> support was first added) that are known to affect Solr's SSL support, and
> have caused numerous test failures -- notably early "testing" builds of
> OpenJDK 11, 12, & 13, as well as the officially released OpenJDK 11, 11.0.1,
> and 11.0.2.
> From the standpoint of the Solr project, there is very little we can do to
> mitigate these bugs, and have taken steps to ensure any code using our
> {{SSLTestConfig}} / {{RandomizeSSL}} test-framework classes will be "SKIPed"
> with an {{AssumptionViolatedException}} when used on JVMs that are known to
> be problematic.
> Users who encounter any of the types of failures described below, or
> developers who encounter test runs that "SKIP" with a message refering to
> this issue ID, are encouraged to Upgrade their JVM. (or as a last resort: try
> disabling "TLSv1.3" in your JVM security properties)
>
> Examples of known bugs as they have manifested in Solr tests...
> * https://bugs.openjdk.java.net/browse/JDK-8212885
> ** "TLS 1.3 resumed session does not retain peer certificate chain"
> ** affects users with {{checkPeerNames=true}} in your SSL configuration
> ** causes 100% failure rate in Solr's
> {{TestMiniSolrCloudClusterSSL.testSslWithCheckPeerName}}
> ** can result in exceptions for SolrJ users, or in solr cloud server logs
> when making intra-node requests, with a root cause of
> "javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated"
> ** {noformat}
>[junit4] 2> Caused by: javax.net.ssl.SSLPeerUnverifiedException: peer
> not authenticated
>[junit4] 2> at
> java.base/sun.security.ssl.SSLSessionImpl.getPeerCertificates(SSLSessionImpl.java:526)
>[junit4] 2> at
> org.apache.http.conn.ssl.SSLConnectionSocketFactory.verifyHostname(SSLConnectionSocketFactory.java:464)
>[junit4] 2> at
> org.apache.http.conn.ssl.SSLConnectionSocketFactory.createLayeredSocket(SSLConnectionSocketFactory.java:397)
>[junit4] 2> at
> org.apache.http.conn.ssl.SSLConnectionSocketFactory.connectSocket(SSLConnectionSocketFactory.java:355)
>[junit4] 2> at
> org.apache.http.impl.conn.DefaultHttpClientConnectionOperator.connect(DefaultHttpClientConnectionOperator.java:142)
>[junit4] 2> at
> org.apache.http.impl.conn.PoolingHttpClientConnectionManager.connect(PoolingHttpClientConnectionManager.java:359)
>[junit4] 2> at
> org.apache.http.impl.execchain.MainClientExec.establishRoute(MainClientExec.java:381)
>[junit4] 2> at
> org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:237)
>[junit4] 2> at
> org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:185)
>[junit4] 2> at
> org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:89)
>[junit4] 2> at
> org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:111)
>[junit4] 2> at
> org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:185)
>[junit4] 2> at
> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:83)
>[junit4] 2> at
> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:56)
>[junit4] 2> at
> org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:542)
> {noformat}
> * https://bugs.openjdk.java.net/browse/JDK-8213202
> ** "Possible race condition in TLS 1.3 session resumption"
> ** May affect any and all Solr SSL users, although noted only in tests when
> "clientAuth" was co
[jira] [Commented] (SOLR-13338) HdfsAutoAddReplicasIntegrationTest failures
[ https://issues.apache.org/jira/browse/SOLR-13338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16864422#comment-16864422 ] Kevin Risden commented on SOLR-13338: - Now that Jetty was upgraded (SOLR-13413 / SOLR-13541), will check on the test failures for this test and see if they start to get better. > HdfsAutoAddReplicasIntegrationTest failures > --- > > Key: SOLR-13338 > URL: https://issues.apache.org/jira/browse/SOLR-13338 > Project: Solr > Issue Type: Test > Components: Hadoop Integration, hdfs, Tests > Reporter: Kevin Risden >Assignee: Kevin Risden >Priority: Minor > > HdfsAutoAddReplicasIntegrationTest failures have increased after SOLR-13330 > (previously failed a different way with SOLR-13060), but they are starting to > reproduce and beasting causes failures locally. They fail the same each time. > Planning to figure out what is going on. -- 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-13541) Upgrade Jetty to 9.4.19.v20190610
[ https://issues.apache.org/jira/browse/SOLR-13541?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16863154#comment-16863154 ] Kevin Risden edited comment on SOLR-13541 at 6/13/19 2:50 PM: -- Jetty 9.4.15+ has the endpointIdentificationAlgorithm enabled by default (https://github.com/eclipse/jetty.project/issues/3454) which causes the above error. Jetty 9.4.16+ has https://github.com/eclipse/jetty.project/issues/3464 related to improving the situation. We might need some tweaks to our Jetty SslContextFactory. was (Author: risdenk): Jetty 9.4.15+ has the endpointIdentificationAlgorithm enabled by default (https://github.com/eclipse/jetty.project/issues/3454) which causes the above error. > Upgrade Jetty to 9.4.19.v20190610 > - > > Key: SOLR-13541 > URL: https://issues.apache.org/jira/browse/SOLR-13541 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Erick Erickson >Assignee: Erick Erickson >Priority: Major > Attachments: _test.res > > Time Spent: 10m > Remaining Estimate: 0h > -- 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-13541) Upgrade Jetty to 9.4.19.v20190610
[ https://issues.apache.org/jira/browse/SOLR-13541?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16863154#comment-16863154 ] Kevin Risden commented on SOLR-13541: - Jetty 9.4.15+ has the endpointIdentificationAlgorithm enabled by default (https://github.com/eclipse/jetty.project/issues/3454) which causes the above error. > Upgrade Jetty to 9.4.19.v20190610 > - > > Key: SOLR-13541 > URL: https://issues.apache.org/jira/browse/SOLR-13541 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Erick Erickson >Assignee: Erick Erickson >Priority: Major > Attachments: _test.res > > Time Spent: 10m > Remaining Estimate: 0h > -- 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-13541) Upgrade Jetty to 9.4.19.v20190610
[
https://issues.apache.org/jira/browse/SOLR-13541?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16863148#comment-16863148
]
Kevin Risden edited comment on SOLR-13541 at 6/13/19 2:44 PM:
--
[~erickerickson] - Pulled this out from the logs. I wonder if our tests aren't
setting up the SAN (subject alternative names) correctly in the TLS/SSL
certificate for localhost/127.0.0.1 TLS/SSL testing. There has been a push to
move from CN -> SAN checking in certificates. Browsers/JDK/etc have been making
that change. It accounts for at least a few of the test failures it looks like.
{code:java}
[junit4] 2> Caused by: java.security.cert.CertificateException: No subject
alternative names matching IP address 127.0.0.1 found
[junit4] 2>at
sun.security.util.HostnameChecker.matchIP(HostnameChecker.java:168)
[junit4] 2>at
sun.security.util.HostnameChecker.match(HostnameChecker.java:94)
[junit4] 2>at
sun.security.ssl.X509TrustManagerImpl.checkIdentity(X509TrustManagerImpl.java:455)
[junit4] 2>at
sun.security.ssl.AbstractTrustManagerWrapper.checkAdditionalTrust(SSLContextImpl.java:1068)
[junit4] 2>at
sun.security.ssl.AbstractTrustManagerWrapper.checkServerTrusted(SSLContextImpl.java:1007)
[junit4] 2>at
sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1601)
[junit4] 2>... 22 more
{code}
was (Author: risdenk):
[~erickerickson] - Pulled this out from the logs. I wonder if our tests aren't
setting up the SAN (subject alternative names) correctly for local host TLS/SSL
testing. There has been a push to move from CN -> SAN checking in certificates.
Browsers/JDK/etc have been making that change. It accounts for at least a few
of the test failures it looks like.
{code:java}
[junit4] 2> Caused by: java.security.cert.CertificateException: No subject
alternative names matching IP address 127.0.0.1 found
[junit4] 2>at
sun.security.util.HostnameChecker.matchIP(HostnameChecker.java:168)
[junit4] 2>at
sun.security.util.HostnameChecker.match(HostnameChecker.java:94)
[junit4] 2>at
sun.security.ssl.X509TrustManagerImpl.checkIdentity(X509TrustManagerImpl.java:455)
[junit4] 2>at
sun.security.ssl.AbstractTrustManagerWrapper.checkAdditionalTrust(SSLContextImpl.java:1068)
[junit4] 2>at
sun.security.ssl.AbstractTrustManagerWrapper.checkServerTrusted(SSLContextImpl.java:1007)
[junit4] 2>at
sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1601)
[junit4] 2>... 22 more
{code}
> Upgrade Jetty to 9.4.19.v20190610
> -
>
> Key: SOLR-13541
> URL: https://issues.apache.org/jira/browse/SOLR-13541
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Major
> Attachments: _test.res
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
--
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-13541) Upgrade Jetty to 9.4.19.v20190610
[
https://issues.apache.org/jira/browse/SOLR-13541?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16863148#comment-16863148
]
Kevin Risden commented on SOLR-13541:
-
[~erickerickson] - Pulled this out from the logs. I wonder if our tests aren't
setting up the SAN (subject alternative names) correctly for local host TLS/SSL
testing. There has been a push to move from CN -> SAN checking in certificates.
Browsers/JDK/etc have been making that change. It accounts for at least a few
of the test failures it looks like.
{code:java}
[junit4] 2> Caused by: java.security.cert.CertificateException: No subject
alternative names matching IP address 127.0.0.1 found
[junit4] 2>at
sun.security.util.HostnameChecker.matchIP(HostnameChecker.java:168)
[junit4] 2>at
sun.security.util.HostnameChecker.match(HostnameChecker.java:94)
[junit4] 2>at
sun.security.ssl.X509TrustManagerImpl.checkIdentity(X509TrustManagerImpl.java:455)
[junit4] 2>at
sun.security.ssl.AbstractTrustManagerWrapper.checkAdditionalTrust(SSLContextImpl.java:1068)
[junit4] 2>at
sun.security.ssl.AbstractTrustManagerWrapper.checkServerTrusted(SSLContextImpl.java:1007)
[junit4] 2>at
sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1601)
[junit4] 2>... 22 more
{code}
> Upgrade Jetty to 9.4.19.v20190610
> -
>
> Key: SOLR-13541
> URL: https://issues.apache.org/jira/browse/SOLR-13541
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Major
> Attachments: _test.res
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
--
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
Re: 8.1.2 bug fix release
+1 to 8.1.2 and the Jetty upgrade. FYI Erick created https://issues.apache.org/jira/browse/SOLR-13541 specifically for the Jetty upgrade. Kevin Risden On Wed, Jun 12, 2019 at 4:47 PM Đạt Cao Mạnh wrote: > Hi David, yeah sure, that bug fix seems important. > I also want to do the upgrade Jetty 9.4.19 for 8.1.2 (fix: SOLR-13413 > <https://issues.apache.org/jira/browse/SOLR-13413>). Do you guys have any > objections? > > On Wed, Jun 12, 2019 at 3:40 PM David Smiley > wrote: > >> Yes thanks for volunteering. Also, lets get this serious bug fix in: >> https://issues.apache.org/jira/browse/SOLR-13523 >> >> ~ David Smiley >> Apache Lucene/Solr Search Developer >> http://www.linkedin.com/in/davidwsmiley >> >> >> On Wed, Jun 12, 2019 at 9:27 AM Đạt Cao Mạnh >> wrote: >> >>> Hi, >>> >>> Just right after the 8.1.1 release has been published we’ve discovered >>> a serious bug in BasicAuthentication which affect all released versions of >>> Solr including 8.0, 8.1, 8.1.1. Details of the bug can be found in >>> SOLR-13510. >>> >>> I’m volunteering to do this release, if there are no objections, and >>> I’d like to create a RC early next week. >>> >>> -- >>> *Best regards,* >>> *Cao Mạnh Đạt* >>> *E-mail: caomanhdat...@gmail.com * >>> >> > > -- > *Best regards,* > *Cao Mạnh Đạt* > *E-mail: caomanhdat...@gmail.com * >
[jira] [Commented] (SOLR-13413) suspicious test failures caused by jetty TimeoutException related to using HTTP2
[ https://issues.apache.org/jira/browse/SOLR-13413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16862229#comment-16862229 ] Kevin Risden commented on SOLR-13413: - Looks like Jetty 9.4.19 was just released: https://github.com/eclipse/jetty.project/releases/tag/jetty-9.4.19.v20190610 > suspicious test failures caused by jetty TimeoutException related to using > HTTP2 > > > Key: SOLR-13413 > URL: https://issues.apache.org/jira/browse/SOLR-13413 > Project: Solr > Issue Type: Bug >Affects Versions: 8.0 >Reporter: Hoss Man >Assignee: Cao Manh Dat >Priority: Major > Attachments: > nocommit_TestDistributedStatsComponentCardinality_trivial-no-http2.patch > > > There is evidence in some recent jenkins failures that we may have some manor > of bug in our http2 client/server code that can cause intra-node query > requests to stall / timeout non-reproducibly. > In at least one known case, forcing the jetty & SolrClients used in the test > to use http1.1, seems to prevent these test failures. -- 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-13434) OpenTracing support for Solr
[ https://issues.apache.org/jira/browse/SOLR-13434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16862025#comment-16862025 ] Kevin Risden edited comment on SOLR-13434 at 6/12/19 11:33 AM: --- [~caomanhdat] I used "ant run-maven-build -DskipTests=true" when working with the Hadoop 3 upgrade to fix maven build issues. was (Author: risdenk): [~caomanhdat] I used "ant run-maven-build" when working with the Hadoop 3 upgrade to fix maven build issues. > OpenTracing support for Solr > > > Key: SOLR-13434 > URL: https://issues.apache.org/jira/browse/SOLR-13434 > Project: Solr > Issue Type: New Feature >Reporter: Shalin Shekhar Mangar >Assignee: Cao Manh Dat >Priority: Major > Fix For: master (9.0), 8.2 > > Attachments: SOLR-13434.patch > > Time Spent: 7h 40m > Remaining Estimate: 0h > > [OpenTracing|https://opentracing.io/] is a vendor neutral API and > infrastructure for distributed tracing. Many OSS tracers just as Jaeger, > OpenZipkin, Apache SkyWalking as well as commercial tools support OpenTracing > APIs. Ideally, we can implement it once and have integrations for popular > tracers like we have with metrics and prometheus. > I'm aware of SOLR-9641 but HTrace has since retired from incubator for lack > of activity so this is a fresh attempt at solving this problem. -- 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-13434) OpenTracing support for Solr
[ https://issues.apache.org/jira/browse/SOLR-13434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16862025#comment-16862025 ] Kevin Risden commented on SOLR-13434: - [~caomanhdat] I used "ant run-maven-build" when working with the Hadoop 3 upgrade to fix maven build issues. > OpenTracing support for Solr > > > Key: SOLR-13434 > URL: https://issues.apache.org/jira/browse/SOLR-13434 > Project: Solr > Issue Type: New Feature >Reporter: Shalin Shekhar Mangar >Assignee: Cao Manh Dat >Priority: Major > Fix For: master (9.0), 8.2 > > Attachments: SOLR-13434.patch > > Time Spent: 7h 40m > Remaining Estimate: 0h > > [OpenTracing|https://opentracing.io/] is a vendor neutral API and > infrastructure for distributed tracing. Many OSS tracers just as Jaeger, > OpenZipkin, Apache SkyWalking as well as commercial tools support OpenTracing > APIs. Ideally, we can implement it once and have integrations for popular > tracers like we have with metrics and prometheus. > I'm aware of SOLR-9641 but HTrace has since retired from incubator for lack > of activity so this is a fresh attempt at solving this problem. -- 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-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
[ https://issues.apache.org/jira/browse/SOLR-13452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16861518#comment-16861518 ] Kevin Risden commented on SOLR-13452: - [~markrmil...@gmail.com] and [~joel.bernstein] - yea that sounds correct. If trying to use the esri functions, you will get an error today. I missed adding the new dependency when upgrading Calcite. Not sure about the materialize dependencies. The Calcite integration is very limited today so we probably haven't hit any of those classes. Would be good to open a Jira to track down if we should include those dependencies separately. > Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle. > - > > Key: SOLR-13452 > URL: https://issues.apache.org/jira/browse/SOLR-13452 > Project: Solr > Issue Type: Improvement > Components: Build >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Major > Fix For: master (9.0) > > > I took some things from the great work that Dat did in > [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a > little further. > > When working with gradle in sub modules directly, I recommend > [https://github.com/dougborg/gdub] > This gradle branch uses the following plugin for version locking, version > configuration and version consistency across modules: > [https://github.com/palantir/gradle-consistent-versions] > > https://github.com/apache/lucene-solr/tree/jira/SOLR-13452_gradle_3 -- 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
Re: Github PRs without attached JIRA issue
PR template would definitely be good. Easiest to implement with biggest impact. I like that all issues are in Jira. There is already an infra bot that will auto link Jiras and PRs if the PR has the a JIRA reference in it I think. For reference this is also the idea of contributing guidelines in addition to the PR template [1] There are a few types of files that would help people if they stumble on the github repo [2]. [1] https://help.github.com/en/articles/setting-guidelines-for-repository-contributors [2] https://help.github.com/en/articles/creating-a-default-community-health-file-for-your-organization Kevin Risden On Fri, Jun 7, 2019 at 9:58 AM David Smiley wrote: > I think a PR template would be great. Lets see yours Cassandra! > > ~ David Smiley > Apache Lucene/Solr Search Developer > http://www.linkedin.com/in/davidwsmiley > > > On Fri, Jun 7, 2019 at 9:35 AM Cassandra Targett > wrote: > >> Heh, here’s another idea I’ve had in my drafts folder for a while but >> thought if I suggest it I should be available to follow up on it and wasn’t >> sure if I’d have time to properly. >> >> I actually started a pull request template and have a mostly complete >> version I could share (via a PR, I guess?). I don’t think it will 100% >> solve it, but it would greatly increase the number of issues that comply, >> for lack of a better term, with our processes/expectations for changes. In >> my draft I also included a short checklist to encourage people to make >> the patch for master, include tests with their patches, run precommit, >> and a few other things I thought might help new contributors understand >> what we need to get their patches reviewed faster. >> >> Your D and E ideas are interesting. I worry about fragmenting where >> definitive info about changes is stored (D) - I think there is a lot of >> value in having a single system of record for the community. >> >> I’d definitely be for exploring moving entirely to Github (E) - I think I >> said something along those lines in the lucene-solr Slack channel a few >> months ago - but have not spent much time figuring out all the downstream >> implications. I think we’d have to consider what we would gain vs what we >> would lose. I definitely don’t yet have a list, but I’m not initially >> against the idea. >> >> Cassandra >> On Jun 7, 2019, 5:53 AM -0500, Jan Høydahl , >> wrote: >> >> Hi, >> >> We have some contributors that open GitHub PRs without also opening a >> JIRA and linking the two. Probably because they are used to that workflow >> from other projects and expect someone to have a look at the contribution. >> There is an email sent to the dev list, and sometimes it is noticed, other >> times the PR just falls through the cracks and is forgotten. >> >> Here is a list of currently open PRs without a JIRA attached, 51 in total: >> >> >> https://github.com/apache/lucene-solr/pulls?utf8=✓=is%3Apr+is%3Aopen+NOT+LUCENE+in%3Atitle+AND+NOT+SOLR+in%3Atitle+ >> <https://github.com/apache/lucene-solr/pulls?utf8=%E2%9C%93=is%3Apr+is%3Aopen+NOT+LUCENE+in%3Atitle+AND+NOT+SOLR+in%3Atitle+> >> >> How can we improve on the situation? I see a few alternatives: >> >> A. Setup a bot with a GitHub WebHook that inspects the title and auto >> adds a comment if LUCENE or SOLR is missing >> https://developer.github.com/v3/activity/events/types/#pullrequestevent >> B. Send the result of the above query to the dev@ list monthly for >> someone to jump in and interact >> C. Add a GitHub Pull-Request Template >> https://help.github.com/en/articles/creating-a-pull-request-template-for-your-repository >> In there put some text about the requirement for a JIRA >> D. Treat PRs as first-class issues, without the need for a shadow JIRA. >> In that case, we'd reference PRs in CHANGES too, e.g.: >> * #217: Fix bug foo >> E. Migrate away from JIRA and use GitHub issues + PR instead. Some Apache >> projects do that already :) >> >> Let the discussion begin :) >> >> -- >> Jan Høydahl, search solution architect >> Cominvent AS - www.cominvent.com >> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >> For additional commands, e-mail: dev-h...@lucene.apache.org >> >>
Re: These two tests are failing a LOT over the last few days....
Is it due to the HTTP2 client changes for basic auth? https://issues.apache.org/jira/browse/SOLR-13510 Kevin Risden On Thu, Jun 6, 2019 at 7:50 PM Erick Erickson wrote: > [repro] 5/5 failed: org.apache.solr.security.BasicAuthIntegrationTest > [repro] 5/5 failed: org.apache.solr.security.JWTAuthPluginIntegrationTest > > Anyone recognize what recent commits might have triggered these? > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > >
Re: Welcome Namgyu Kim as Lucene/Solr committer
Congrats and welcome! Kevin Risden On Mon, Jun 3, 2019 at 2:14 PM Erick Erickson wrote: > Welcome! Good to have you aboard. > > > On Jun 3, 2019, at 10:57 AM, David Smiley > wrote: > > > > Welcome Namgyu! > > > > ~ David Smiley > > Apache Lucene/Solr Search Developer > > http://www.linkedin.com/in/davidwsmiley > > > > > > On Mon, Jun 3, 2019 at 1:52 PM Adrien Grand wrote: > > Hi all, > > > > Please join me in welcoming Namgyu Kim as Lucene/ Solr committer! > > > > Kim has been helping address technical debt and fixing bugs in the > > last year, including a cleanup to our DutchAnalyzer[0] and > > improvements to the StoredFieldsVisitor API[1]. More recently he also > > started improving our korean analyzer[2]. > > > > [0] https://issues.apache.org/jira/browse/LUCENE-8582 > > [1] https://issues.apache.org/jira/browse/LUCENE-8805 > > [2] https://issues.apache.org/jira/browse/LUCENE-8784 > > > > Congratulations and welcome! It is a tradition to introduce yourself > > with a brief bio. > > > > -- > > Adrien > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > > For additional commands, e-mail: dev-h...@lucene.apache.org > > > > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > >
[jira] [Commented] (SOLR-9952) S3BackupRepository
[ https://issues.apache.org/jira/browse/SOLR-9952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16852482#comment-16852482 ] Kevin Risden commented on SOLR-9952: [~varunthacker] - not entirely sure what your question is about params conflicting. Hrishikesh and I talked about it earlier on this ticket on Jan 13, 2017 about how the parameters shouldn't conflict if you use absolutely parameters or rename the system properties in solr.xml. > S3BackupRepository > -- > > Key: SOLR-9952 > URL: https://issues.apache.org/jira/browse/SOLR-9952 > Project: Solr > Issue Type: New Feature > Security Level: Public(Default Security Level. Issues are Public) > Components: Backup/Restore >Reporter: Mikhail Khludnev >Priority: Major > Attachments: > 0001-SOLR-9952-Added-dependencies-for-hadoop-amazon-integ.patch, > 0002-SOLR-9952-Added-integration-test-for-checking-backup.patch, Running Solr > on S3.pdf, core-site.xml.template > > > I'd like to have a backup repository implementation allows to snapshot to AWS > S3 -- 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-9952) S3BackupRepository
[ https://issues.apache.org/jira/browse/SOLR-9952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16852372#comment-16852372 ] Kevin Risden commented on SOLR-9952: [~Goodman] - I understand the frustration. With the Hadoop 3 work in Solr 8.0+ you will be MUCH better off as far as S3 goes. The hadoop-aws jars in Hadoop 2.7.x are very old now. Lots of improvements but it requires upgrading the entire Hadoop package at once. If possible I would try with Solr 8.1.1 and see if you run into the same things. In theory on Solr 8.0+, you should be able to use s3a and not run into the connection pool shutdown stuff. I didn't play with the backup/restore but instead tested with running Solr collections off of s3a. Here is a reference to what I tried [https://github.com/risdenk/solr-s3a-testing]. I also tried against real s3 to make sure I didn't miss anything. > S3BackupRepository > -- > > Key: SOLR-9952 > URL: https://issues.apache.org/jira/browse/SOLR-9952 > Project: Solr > Issue Type: New Feature > Security Level: Public(Default Security Level. Issues are Public) > Components: Backup/Restore >Reporter: Mikhail Khludnev >Priority: Major > Attachments: > 0001-SOLR-9952-Added-dependencies-for-hadoop-amazon-integ.patch, > 0002-SOLR-9952-Added-integration-test-for-checking-backup.patch, Running Solr > on S3.pdf, core-site.xml.template > > > I'd like to have a backup repository implementation allows to snapshot to AWS > S3 -- 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
Re: [VOTE] Release Lucene/Solr 7.7.2 RC1
+1 SUCCESS! [1:14:45.390365] Kevin Risden On Tue, May 28, 2019 at 7:54 PM Jan Høydahl wrote: > Please vote for release candidate 1 for Lucene/Solr 7.7.2 > > The artifacts can be downloaded from: > > https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-7.7.2-RC1-revd4c30fc2856154f2c1fefc589eb7cd070a415b94 > > 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-7.7.2-RC1-revd4c30fc2856154f2c1fefc589eb7cd070a415b94 > > The vote will be open for at least 3 working days, i.e. until 2019-06-04 > 08:00 UTC. > > [ ] +1 approve > [ ] +0 no opinion > [ ] -1 disapprove (and reason why) > > Here is my +1 > > SUCCESS! [1:06:20.144701] > > -- > Jan Høydahl, search solution architect > Cominvent AS - www.cominvent.com > > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > >
[jira] [Commented] (SOLR-13434) OpenTracing support for Solr
[ https://issues.apache.org/jira/browse/SOLR-13434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16846757#comment-16846757 ] Kevin Risden commented on SOLR-13434: - [~caomanhdat] - might be easier to review as a PR? Nothing wrong with patches just seems like a big change. > OpenTracing support for Solr > > > Key: SOLR-13434 > URL: https://issues.apache.org/jira/browse/SOLR-13434 > Project: Solr > Issue Type: New Feature > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Shalin Shekhar Mangar >Assignee: Cao Manh Dat >Priority: Major > Fix For: master (9.0), 8.2 > > Attachments: SOLR-13434.patch > > > [OpenTracing|https://opentracing.io/] is a vendor neutral API and > infrastructure for distributed tracing. Many OSS tracers just as Jaeger, > OpenZipkin, Apache SkyWalking as well as commercial tools support OpenTracing > APIs. Ideally, we can implement it once and have integrations for popular > tracers like we have with metrics and prometheus. > I'm aware of SOLR-9641 but HTrace has since retired from incubator for lack > of activity so this is a fresh attempt at solving this problem. -- 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
Re: [VOTE] Release Lucene/Solr 8.1.1 RC1
+1 SUCCESS! [1:17:47.587332] Kevin Risden On Wed, May 22, 2019 at 1:53 PM Andrzej Białecki wrote: > Please vote for release candidate 1 for Lucene/Solr 8.1.1. > > The artifacts can be downloaded from: > > https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.1.1-RC1-revfcbe46c28cef11bc058779afba09521de1b19bef > > 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.1.1-RC1-revfcbe46c28cef11bc058779afba09521de1b19bef > > > Here's my +1 > SUCCESS! [1:00:35.149875] > > — > > Andrzej Białecki > > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > >
[jira] [Commented] (LUCENE-8807) Change all download URLs in build files to HTTPS
[
https://issues.apache.org/jira/browse/LUCENE-8807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16844899#comment-16844899
]
Kevin Risden commented on LUCENE-8807:
--
[~thetaphi] - I think there is one typo in the patch from a quick review:
Should be https instead of http2
> Change all download URLs in build files to HTTPS
>
>
> Key: LUCENE-8807
> URL: https://issues.apache.org/jira/browse/LUCENE-8807
> Project: Lucene - Core
> Issue Type: Task
> Components: general/build
>Affects Versions: 8.1
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
>Priority: Blocker
> Fix For: 7.7.2, master (9.0), 8.2, 8.1.1
>
> Attachments: LUCENE-8807.patch, LUCENE-8807.patch
>
>
> At least for Lucene this is not a security issue, because we have checksums
> for all downloaded JAR dependencies, but ASF asked all projects to ensure
> that download URLs for dependencies are using HTTPS:
> {quote}
> [...] Projects like Lucene do checksum whitelists of
> all their build dependencies, and you may wish to consider that as a
> protection against threats beyond just MITM [...]
> {quote}
> This patch fixes the URLs for most files referenced in {{*build.xml}} and
> {{*ivy*.xml}} to HTTPS. There are a few data files in benchmark which use
> HTTP only, but that's uncritical and I added a TODO. Some were broken already.
> I removed the "uk.maven.org" workarounds for Maven, as this does not work
> with HTTPS. By keeping those inside, we break the whole chain of trust, as
> any non-working HTTPS would fallback to the insecure uk.maven.org Maven
> mirror.
> As the great chinese firewall is changing all the time, we should just wait
> for somebody complaining.
--
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
Re: Welcome Michael Sokolov as Lucene/ Solr committer
Welcome and congrats! Kevin Risden On Mon, May 13, 2019 at 3:32 PM Uwe Schindler wrote: > Welcome Mike, great to have you on board! ️ > > Uwe > > Am May 13, 2019 7:23:18 PM UTC schrieb Michael Sokolov >: >> >> Thanks Dawid, and thank you to everyone who voted to grant me access >> to this awesome project! >> >> I spent many years building full text search web applications serving >> large texts (especially dictionaries, encyclopedias, and academic >> journals). I cut my teeth with AltaVista back in 1998, and tried many >> other search engines before finally coming around to Solr/Lucene. >> >> I am pretty sure my first interaction with the Apache Solr/Lucene >> community was back in 2012, when I was looking to solve a performance >> problem we encountered highlighting gigantic documents. Since then >> I've worked on many projects involving Solr and Lucene, and >> ElasticSearch, and made various contributions, implemented some of my >> own extensions, made a separate XML query engine based on Solr (Lux - >> no longer active), went to a few Lucene/Solr Revolutions (spoke at >> one), and always in the back of my mind was the idea of contributing >> more actively and becoming a full participant in this thriving open >> source project. Now I'm really excited that has come to pass, and look >> forward to digging in even deeper, and helping to keep this thing >> going. >> >> -Mike >> >> On Mon, May 13, 2019 at 3:12 PM Dawid Weiss wrote: >> >>> >>> Hello everyone, >>> >>> Please join me in welcoming Michael Sokolov as Lucene/ Solr committer! >>> >>> Many of you probably know Mike as he's been around for quite a while >>> -- answering questions, reviewing patches, providing insight and >>> actively working on new code. >>> >>> Congratulations and welcome! It is a tradition to introduce yourself >>> with a brief bio, Mike. >>> >>> Dawid >>> >> -- >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >> For additional commands, e-mail: dev-h...@lucene.apache.org >> >> > -- > Uwe Schindler > Achterdiek 19, 28357 Bremen > https://www.thetaphi.de >
Re: Lucene/Solr 7.7.2
Finished backport of SOLR-13112 for Jackson 2.9.8 Kevin Risden On Thu, May 9, 2019 at 6:57 PM Jan Høydahl wrote: > Looks safe to backport, go ahead! > > -- > Jan Høydahl, search solution architect > Cominvent AS - www.cominvent.com > > 9. mai 2019 kl. 23:07 skrev Cassandra Targett : > > Someone brought https://issues.apache.org/jira/browse/SOLR-13112 to my > attention today, which upgraded the Jackson dependencies to 2.9.8. Would it > be possible for those to be backported to branch_7_7 for inclusion in 7.7.2? > > Cassandra > On May 8, 2019, 2:51 PM -0500, Jan Høydahl , wrote: > > Yes please do! > > -- > Jan Høydahl, search solution architect > Cominvent AS - www.cominvent.com > > 8. mai 2019 kl. 18:25 skrev Ishan Chattopadhyaya < > ichattopadhy...@gmail.com>: > > I would like to backport SOLR-13410, as without this the ADDROLE of > "overseer" is effectively broken. Please let me know if that is fine. > > On Sat, May 4, 2019 at 2:22 AM Jan Høydahl wrote: > > > Sure, go ahead! > > -- > Jan Høydahl, search solution architect > Cominvent AS - www.cominvent.com > > 3. mai 2019 kl. 17:53 skrev Andrzej Białecki < > andrzej.biale...@lucidworks.com>: > > Hi, > > I would like to back-port the recent changes in the re-opened SOLR-12833, > since the increased memory consumption adversely affects existing 7x users. > > On 3 May 2019, at 10:38, Jan Høydahl wrote: > > To not confuse two releases at the same time, I'll delay the first 7.7.2 > RC until after a successful 8.1 vote. > Uwe, can you re-enable the Jenkins 7.7 jobs to make sure we have a healthy > branch_7_7? > Feel free to push important bug fixes to the branch in the meantime, > announcing them in this thread. > > -- > Jan Høydahl, search solution architect > Cominvent AS - www.cominvent.com > > 30. apr. 2019 kl. 18:19 skrev Ishan Chattopadhyaya < > ichattopadhy...@gmail.com>: > > +1 Jan for May 7th. > Hopefully, 8.1 would be already out by then (or close to being there). > > On Tue, Apr 30, 2019 at 1:33 PM Bram Van Dam wrote: > > > On 29/04/2019 23:33, Jan Høydahl wrote: > > I'll vounteer as RM for 7.7.2 and aim at first RC on Tuesday May 7th > > > Thank you! > > > > > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > > For additional commands, e-mail: dev-h...@lucene.apache.org > > > > >
[jira] [Resolved] (SOLR-13112) Upgrade jackson to 2.9.8
[ https://issues.apache.org/jira/browse/SOLR-13112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Risden resolved SOLR-13112. - Resolution: Fixed Reresolving after pushing to branch_7_7 > Upgrade jackson to 2.9.8 > > > Key: SOLR-13112 > URL: https://issues.apache.org/jira/browse/SOLR-13112 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 7.6 > Environment: RedHat Linux. May run from RHEL versions 5, 6 or 7 > but this issue is from Sonatype component scan and should be independent of > Linux platform version. >Reporter: RobertHathaway >Assignee: Kevin Risden >Priority: Major > Fix For: 7.7.2, 8.1, master (9.0) > > Attachments: SOLR-13112.patch > > Time Spent: 20m > Remaining Estimate: 0h > > We can't move to Solr 7 without fixing this issue flagged by Sonatype scan Of > Solr - 7.6.0 Build, > Using Scanner 1.56.0-01 > Threat Level 8 Against Solr v7.6. com.fasterxml.jackson.core : > jackson-databind : 2.9.6 > FasterXML jackson-databind 2.x before 2.9.7 might allow remote attackers to > execute arbitrary code by leveraging failure to block the slf4j-ext class > from polymorphic deserialization. > http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-14718 -- 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-13461) Update Parallel SQL docs to be very clear select * isn't supported.
[ https://issues.apache.org/jira/browse/SOLR-13461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16837444#comment-16837444 ] Kevin Risden commented on SOLR-13461: - I would guess the score addition and making select * not work is due to this change: [https://github.com/apache/lucene-solr/commit/ec6ee96ae6df1fdb2fffd881b45cb48670a10c5b#diff-378575439f2fa63a836101b4297e7ef0R259] > Update Parallel SQL docs to be very clear select * isn't supported. > --- > > Key: SOLR-13461 > URL: https://issues.apache.org/jira/browse/SOLR-13461 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: documentation >Affects Versions: 8.0 >Reporter: Eric Pugh >Priority: Minor > > Small tweak to documentation to really highlight select * not supported. -- 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-13112) Upgrade jackson to 2.9.8
[ https://issues.apache.org/jira/browse/SOLR-13112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16837433#comment-16837433 ] Kevin Risden commented on SOLR-13112: - Sounds good [~ctargett] - I'll take care of the commit. > Upgrade jackson to 2.9.8 > > > Key: SOLR-13112 > URL: https://issues.apache.org/jira/browse/SOLR-13112 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 7.6 > Environment: RedHat Linux. May run from RHEL versions 5, 6 or 7 > but this issue is from Sonatype component scan and should be independent of > Linux platform version. >Reporter: RobertHathaway >Assignee: Kevin Risden >Priority: Major > Fix For: 7.7.2, 8.1, master (9.0) > > Attachments: SOLR-13112.patch > > Time Spent: 20m > Remaining Estimate: 0h > > We can't move to Solr 7 without fixing this issue flagged by Sonatype scan Of > Solr - 7.6.0 Build, > Using Scanner 1.56.0-01 > Threat Level 8 Against Solr v7.6. com.fasterxml.jackson.core : > jackson-databind : 2.9.6 > FasterXML jackson-databind 2.x before 2.9.7 might allow remote attackers to > execute arbitrary code by leveraging failure to block the slf4j-ext class > from polymorphic deserialization. > http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-14718 -- 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-13338) HdfsAutoAddReplicasIntegrationTest failures
[ https://issues.apache.org/jira/browse/SOLR-13338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16837393#comment-16837393 ] Kevin Risden commented on SOLR-13338: - So a lot of these issues look like [SOLR-13413|https://www.google.com/url?q=https://issues.apache.org/jira/browse/SOLR-13413=D=hangouts=1557588898292000=AFQjCNGkWSSI7IjkUF5vpflX-dY0Gs6HLw] where there is just a timeout waiting. I haven't had a chance to test the Jetty change against this test. > HdfsAutoAddReplicasIntegrationTest failures > --- > > Key: SOLR-13338 > URL: https://issues.apache.org/jira/browse/SOLR-13338 > Project: Solr > Issue Type: Test > Security Level: Public(Default Security Level. Issues are Public) > Components: Hadoop Integration, hdfs, Tests >Reporter: Kevin Risden > Assignee: Kevin Risden >Priority: Minor > > HdfsAutoAddReplicasIntegrationTest failures have increased after SOLR-13330 > (previously failed a different way with SOLR-13060), but they are starting to > reproduce and beasting causes failures locally. They fail the same each time. > Planning to figure out what is going on. -- 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-13112) Upgrade jackson to 2.9.8
[ https://issues.apache.org/jira/browse/SOLR-13112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16837388#comment-16837388 ] Kevin Risden commented on SOLR-13112: - [~ctargett] - are you taking care of the commit? If not I can backport the change this afternoon (~4 hours from now). > Upgrade jackson to 2.9.8 > > > Key: SOLR-13112 > URL: https://issues.apache.org/jira/browse/SOLR-13112 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 7.6 > Environment: RedHat Linux. May run from RHEL versions 5, 6 or 7 > but this issue is from Sonatype component scan and should be independent of > Linux platform version. >Reporter: RobertHathaway >Assignee: Kevin Risden >Priority: Major > Fix For: 7.7.2, 8.1, master (9.0) > > Attachments: SOLR-13112.patch > > Time Spent: 20m > Remaining Estimate: 0h > > We can't move to Solr 7 without fixing this issue flagged by Sonatype scan Of > Solr - 7.6.0 Build, > Using Scanner 1.56.0-01 > Threat Level 8 Against Solr v7.6. com.fasterxml.jackson.core : > jackson-databind : 2.9.6 > FasterXML jackson-databind 2.x before 2.9.7 might allow remote attackers to > execute arbitrary code by leveraging failure to block the slf4j-ext class > from polymorphic deserialization. > http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-14718 -- 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-13461) Update Parallel SQL docs to be very clear select * isn't supported.
[ https://issues.apache.org/jira/browse/SOLR-13461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16837358#comment-16837358 ] Kevin Risden commented on SOLR-13461: - H so "select *" used to work Do you have the error message you get? I can try to look and see why select * doesn't work anymore. I found a comment about this being broken from 2017 that I somehow missed. https://issues.apache.org/jira/browse/SOLR-8847?focusedCommentId=16014628=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16014628 Apparently the score field is being added somehow? I don't remember adding that, but seems like an issue since select * is useful. [~joel.bernstein] - do you know what is happening with the score field and select *? > Update Parallel SQL docs to be very clear select * isn't supported. > --- > > Key: SOLR-13461 > URL: https://issues.apache.org/jira/browse/SOLR-13461 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: documentation >Affects Versions: 8.0 >Reporter: Eric Pugh >Priority: Minor > > Small tweak to documentation to really highlight select * not supported. -- 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
Re: [VOTE] Release Lucene/Solr 8.1.0 RC2
+1 SUCCESS! [1:17:45.727492] Kevin Risden On Thu, May 9, 2019 at 11:37 AM Ishan Chattopadhyaya < ichattopadhy...@gmail.com> wrote: > Please vote for release candidate 2 for Lucene/Solr 8.1.0 > > The artifacts can be downloaded from: > > https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.1.0-RC2-revdbe5ed0b2f17677ca6c904ebae919363f2d36a0a > > 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.1.0-RC2-revdbe5ed0b2f17677ca6c904ebae919363f2d36a0a > > Here's my +1 > SUCCESS! [0:44:31.244021] > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > >
[jira] [Commented] (SOLR-13413) suspicious test failures caused by jetty TimeoutException related to using HTTP2
[ https://issues.apache.org/jira/browse/SOLR-13413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16836386#comment-16836386 ] Kevin Risden commented on SOLR-13413: - [~caomanhdat] - thanks for tracking this down! > suspicious test failures caused by jetty TimeoutException related to using > HTTP2 > > > Key: SOLR-13413 > URL: https://issues.apache.org/jira/browse/SOLR-13413 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Hoss Man >Assignee: Cao Manh Dat >Priority: Major > Attachments: > nocommit_TestDistributedStatsComponentCardinality_trivial-no-http2.patch > > > There is evidence in some recent jenkins failures that we may have some manor > of bug in our http2 client/server code that can cause intra-node query > requests to stall / timeout non-reproducibly. > In at least one known case, forcing the jetty & SolrClients used in the test > to use http1.1, seems to prevent these test failures. -- 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
Re: [VOTE] Release Lucene/Solr 8.1.0 RC1
+1 SUCCESS! [1:15:45.039228] Kevin Risden On Wed, May 8, 2019 at 11:12 AM David Smiley wrote: > +1 > SUCCESS! [1:29:43.016321] > > Thanks for doing the release Ishan! > > ~ David Smiley > Apache Lucene/Solr Search Developer > http://www.linkedin.com/in/davidwsmiley > > > On Tue, May 7, 2019 at 1:49 PM Ishan Chattopadhyaya < > ichattopadhy...@gmail.com> wrote: > >> Please vote for release candidate 1 for Lucene/Solr 8.1.0 >> >> The artifacts can be downloaded from: >> >> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.1.0-RC1-reve5839fb416083fcdaeedfb1e329a9fdaa29fdc50 >> >> 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.1.0-RC1-reve5839fb416083fcdaeedfb1e329a9fdaa29fdc50 >> >> Here's my +1 >> SUCCESS! [0:46:38.948020] >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >> For additional commands, e-mail: dev-h...@lucene.apache.org >> >>
Re: Socket Timeouts
You might be interested in:
https://issues.apache.org/jira/browse/SOLR-13389
Kevin Risden
On Sun, May 5, 2019 at 1:35 PM Gus Heck wrote:
> I'm working with a client that's trying to process a lot of data (billions
> of docs) via a streaming expression, and the initial query is (not
> surprisingly) taking a long time. Lots of various types of timeouts have
> been cropping up and I've found myself thinking I solved some only to
> discover that the settings in solr.xml are far less wide reaching than I
> thought initially. The present 5% scale cluster seems to hit one particular
> time out about 50% of the time which has made it particularly confusing.
> I'm guessing it's probably depending on something like how busy the
> virtualization in Amazon is, just barely making it when it gets more
> resources and timing out if anything is starved.
>
> As I look around the code base I'm finding a LOT of places where timeouts
> on SolrClients and CloudSolrClients are just arbitrarily set to one-off
> constant values. The one bugging me right now is
>
> public abstract class SolrClientBuilder> {
>
> protected HttpClient httpClient;
> protected ResponseParser responseParser;
> protected Integer connectionTimeoutMillis = 15000;
> protected Integer socketTimeoutMillis = 12;
>
> Which I am unable to change because of this code in SolrStream:
>
> /**
> * Opens the stream to a single Solr instance.
> **/
> public void open() throws IOException {
> if(cache == null) {
> client = new HttpSolrClient.Builder(baseUrl).build();
> } else {
> client = cache.getHttpSolrClient(baseUrl);
> }
>
> I need to make this particular case configurable, so that I can get
> results from a very long running query, but I sense that there is a much
> wider problem in that we don't seem to have any organized plan for how
> socket timeouts are set/managed in the code.
>
> What thoughts have people had on this front?
>
> -Gus
>
> --
> http://www.needhamsoftware.com (work)
> http://www.the111shift.com (play)
>
Re: Fwd: Lucene/Solr 8.0
The docker hub stuff took a while since Solr 8 should have made it simpler but didn't completely. Some of the details are here: https://github.com/docker-solr/docker-solr/issues/196 It looks like the README or Description didn't get updated even though the latest version is correct: https://hub.docker.com/_/solr Kevin Risden On Fri, May 3, 2019 at 2:06 AM Ishan Chattopadhyaya < ichattopadhy...@gmail.com> wrote: > Hi Jason, > I now see docker hub synced up and is finally serving 8.0.0. This > happened, as per docker hub, "3 days ago". > Not sure why this delay (perhaps due to the security breach at docker > hub?). > Thanks for looking into this. > Regards, > Ishan > > On Fri, May 3, 2019 at 4:22 AM Jason Gerlowski > wrote: > > > > Are you sure Ishan? I just did a "docker pull solr" and it looks like > > I'm getting 8.0. Here's what I tried: https://pastebin.com/uPwCammc > > > > From the commit history here, maybe this is a recent change though? > > https://github.com/docker-solr/docker-solr > > > > Anyway, if you retry and still see 7.7.1, let me know and we can > > figure things out from there. > > > > On Thu, May 2, 2019 at 5:05 PM Ishan Chattopadhyaya > > wrote: > > > > > > What should be done to get 8.0 version added to Docker Hub [0]? > > > Would this need to be done by Martijn Koster at Lucidworks? If so, can > > > someone please request him to take a look? > > > Or is this something that even we (@ Apache) can do too? > > > > > > [0] - https://hub.docker.com/_/solr/ > > > > > > On Tue, Apr 30, 2019 at 9:44 PM Ishan Chattopadhyaya > > > wrote: > > > > > > > > On a different note, I realized 2 days back that the solr:latest on > > > > docker hub points to 7.7.1. What do we need to do to get 8.0 docker > > > > image on docker hub? > > > > > > > > On Tue, Apr 30, 2019 at 6:57 PM Cassandra Targett < > casstarg...@gmail.com> wrote: > > > > > > > > > > I have a number of changes in a local branch for the 8.0 Ref Guide > page “Major Changes in Solr 8” about HTTP/2 which might help. I hadn’t > intended to push my branch, but I could if it helps. I also have a bunch of > unfinished content I started about nested documents, but tearing apart the > CHANGES.txt to figure out what is new and how that impacts upgrades is > incredibly painful and time-consuming, and I don’t have a ton of time these > days. This is why the 8.0 Ref Guide isn’t out yet. > > > > > > > > > > Tangentially, I feel like we need to work something else out about > Wiki release notes (and, remember, wiki.apache.org is going away really > soon now) and the Ref Guide. It’s odd to me that one person decides how to > present what’s new in the Wiki release notes, and someone else decides how > to present a whole other set of content about the same set of features for > the Ref Guide. Usually I skip the what’s new part for the minor releases, > but for major ones, there needs to be a comprehensive “here’s what’s new > and what’s changed” - we’ve done it for 5->6 and 6->7, it’s part of the > major version process now. > > > > > > > > > > Anyway, let me know if you want to see what I have so far, and > I’ll try to find some time to push it or make a patch. > > > > > On Apr 30, 2019, 8:00 AM -0500, David Smiley < > david.w.smi...@gmail.com>, wrote: > > > > > > > > > > Hi Dat, > > > > > > > > > > I plan to update Solr's release notes for 8.0 retroactively. > https://wiki.apache.org/solr/ReleaseNote80 has more info on nested docs; > I wrote this well over a month ago. Can you please enhance the part on > HTTP2 to be more informative? For example... what *benefit* does HTTP2 > bring to internode communication? I know you benchmarked things. Maybe > mention the road to full HTTP2 continues into 8.x? > > > > > > > > > > I'm sending this to the dev list so really anyone else can help > like list other major features... though I think maybe it's just these two. > > > > > > > > > > ~ David Smiley > > > > > Apache Lucene/Solr Search Developer > > > > > http://www.linkedin.com/in/davidwsmiley > > > > > > > > > > -- Forwarded message - > > > > > From: David Smiley > > > > > Date: Thu, Mar 14, 2019 at 9:34 AM > > > > > Subject: Re: Lucene/Solr 8.0 > > > > > To: Solr/Lucene Dev > > > > > > > &g
[jira] [Commented] (SOLR-13294) TestSQLHandler failures on windows jenkins machines
[
https://issues.apache.org/jira/browse/SOLR-13294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16831146#comment-16831146
]
Kevin Risden commented on SOLR-13294:
-
[~joel.bernstein] - Can this be resolved? Looks like no failures recently?
> TestSQLHandler failures on windows jenkins machines
> ---
>
> Key: SOLR-13294
> URL: https://issues.apache.org/jira/browse/SOLR-13294
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Hoss Man
>Assignee: Joel Bernstein
>Priority: Major
>
> _Windows_ jenkins builds frequently - but _not always_ - fail on
> {{TestSQLHandler}} @ L236
> In cases where a windows jenkins build finds a failing seed for
> {{TestSQLHandler}}, and the same jenkins build attempts to reproduce using
> that seed, it reliably encounters a *different* failure earlier in the test
> (related to docValues being missing from a sort field).
> These seeds do not fail for me when attempted on a Linux machine, and my own
> attempts @ beasting on linux hasn't turned up any similar failures.
> Here's an example from jenkins - the exact same pattern has occured in other
> windows jenkins builds on other branches at the exact same asserts..
> [https://jenkins.thetaphi.de/view/Lucene-Solr/job/Lucene-Solr-8.0-Windows/57/]
> {noformat}
> Using Java: 32bit/jdk1.8.0_172 -server -XX:+UseConcMarkSweepGC
> ...
> Checking out Revision 0376bc0052a53480ecb2edea7dfe58298bda5deb
> (refs/remotes/origin/branch_8_0)
> ...
>[junit4] 2> NOTE: reproduce with: ant test -Dtestcase=TestSQLHandler
> -Dtests.method=doTest -Dtests.seed=EEE2628F22F5C82A -Dtests.slow=true
> -Dtests.locale=id -Dtests.timezone=BST -Dtests.asserts=true
> -Dtests.file.encoding=ISO-8859-1
>[junit4] FAILURE 23.3s J0 | TestSQLHandler.doTest <<<
>[junit4]> Throwable #1: java.lang.AssertionError
>[junit4]>at
> __randomizedtesting.SeedInfo.seed([EEE2628F22F5C82A:49A6DA2B4F4EDB93]:0)
>[junit4]>at
> org.apache.solr.handler.TestSQLHandler.testBasicSelect(TestSQLHandler.java:236)
>[junit4]>at
> org.apache.solr.handler.TestSQLHandler.doTest(TestSQLHandler.java:93)
>[junit4]>at
> org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:1082)
>[junit4]>at
> org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:1054)
>[junit4]>at java.lang.Thread.run(Thread.java:748)
> ...
>[junit4] 2> NOTE: reproduce with: ant test -Dtestcase=TestSQLHandler
> -Dtests.method=doTest -Dtests.seed=EEE2628F22F5C82A -Dtests.slow=true
> -Dtests.badapples=true -Dtests.locale=id -Dtests.timezone=BST
> -Dtests.asserts=true -Dtests.file.encoding=ISO-8859-1
>[junit4] ERROR 20.8s J0 | TestSQLHandler.doTest <<<
>[junit4]> Throwable #1: java.io.IOException: -->
> http://127.0.0.1:61309/collection1_shard2_replica_n1:Failed to execute
> sqlQuery 'select id, field_i, str_s, field_i_p, field_f_p, field_d_p,
> field_l_p from collection1 where (text='()' OR text='') AND
> text='' order by field_i desc' against JDBC connection
> 'jdbc:calcitesolr:'.
>[junit4]> Error while executing SQL "select id, field_i, str_s,
> field_i_p, field_f_p, field_d_p, field_l_p from collection1 where
> (text='()' OR text='') AND text='' order by field_i desc":
> java.io.IOException: java.util.concurrent.ExecutionException:
> java.io.IOException: -->
> http://127.0.0.1:61309/collection1_shard2_replica_n1/:id{type=string,properties=indexed,stored,sortMissingLast,uninvertible}
> must have DocValues to use this feature.
>[junit4]>at
> __randomizedtesting.SeedInfo.seed([EEE2628F22F5C82A:49A6DA2B4F4EDB93]:0)
>[junit4]>at
> org.apache.solr.client.solrj.io.stream.SolrStream.read(SolrStream.java:215)
>[junit4]>at
> org.apache.solr.handler.TestSQLHandler.getTuples(TestSQLHandler.java:2617)
>[junit4]>at
> org.apache.solr.handler.TestSQLHandler.testBasicSelect(TestSQLHandler.java:145)
>[junit4]>at
> org.apache.solr.handler.TestSQLHandler.doTest(TestSQLHandler.java:93)
>[junit4]>at
> org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:
[jira] [Commented] (SOLR-13040) Harden TestSQLHandler.
[ https://issues.apache.org/jira/browse/SOLR-13040?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16831147#comment-16831147 ] Kevin Risden commented on SOLR-13040: - [~joel.bernstein] - Can this also be resolved since looks like SOLR-13294 fixed the issues? > Harden TestSQLHandler. > -- > > Key: SOLR-13040 > URL: https://issues.apache.org/jira/browse/SOLR-13040 > Project: Solr > Issue Type: Sub-task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Mark Miller >Assignee: Joel Bernstein >Priority: Major > -- 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
Re: [lucene-solr] 01/02: Fix MLT like text with custom frequencies
It might be https://issues.apache.org/jira/browse/LUCENE-8756
Kevin Risden
On Tue, Apr 30, 2019 at 2:35 PM Gus Heck wrote:
> I'm seeing precommit failures on master that appear to be from this
> commit. Also it's not clear from the commit message which issue this
> belongs to...
>
> [forbidden-apis] Loading classes to check...
> [forbidden-apis] Scanning classes for violations...
> [forbidden-apis] Forbidden method invocation:
> java.lang.String#format(java.lang.String,java.lang.Object[]) [Uses default
> locale]
> [forbidden-apis] in org.apache.lucene.queries.mlt.TestMoreLikeThis
> (TestMoreLikeThis.java:497)
> [forbidden-apis] Scanned 239 class file(s) for forbidden API invocations
> (in 0.08s), 1 error(s).
>
>
> On Tue, Apr 30, 2019 at 12:16 PM wrote:
>
>> This is an automated email from the ASF dual-hosted git repository.
>>
>> mikemccand pushed a commit to branch master
>> in repository https://gitbox.apache.org/repos/asf/lucene-solr.git
>>
>> commit 351e21f6203e8f3aece0cd5adf4049974bd2d636
>> Author: Olli Kuonanoja
>> AuthorDate: Mon Apr 8 16:44:30 2019 +0300
>>
>> Fix MLT like text with custom frequencies
>>
>> When an analyzer with custom term frequencies is used with MLT like
>> texts, the custom term frequencies are incorrectly omitted and a fixed
>> frequency of 1 is used instead.
>>
>> This commit fixes the issue by using `TermFrequencyAttribute` to get
>> the term frequencies instead of using fixed 1. Also adds test cases
>> for them mentioned issue.
>> ---
>> .../apache/lucene/queries/mlt/MoreLikeThis.java| 12 +++-
>> .../lucene/queries/mlt/TestMoreLikeThis.java | 70
>> ++
>> 2 files changed, 79 insertions(+), 3 deletions(-)
>>
>> diff --git
>> a/lucene/queries/src/java/org/apache/lucene/queries/mlt/MoreLikeThis.java
>> b/lucene/queries/src/java/org/apache/lucene/queries/mlt/MoreLikeThis.java
>> index 61ebe93..7c077e5 100644
>> ---
>> a/lucene/queries/src/java/org/apache/lucene/queries/mlt/MoreLikeThis.java
>> +++
>> b/lucene/queries/src/java/org/apache/lucene/queries/mlt/MoreLikeThis.java
>> @@ -28,6 +28,7 @@ import java.util.Set;
>> import org.apache.lucene.analysis.Analyzer;
>> import org.apache.lucene.analysis.TokenStream;
>> import org.apache.lucene.analysis.tokenattributes.CharTermAttribute;
>> +import org.apache.lucene.analysis.tokenattributes.TermFrequencyAttribute;
>> import org.apache.lucene.document.Document;
>> import org.apache.lucene.index.FieldInfos;
>> import org.apache.lucene.index.Fields;
>> @@ -824,6 +825,7 @@ public final class MoreLikeThis {
>>int tokenCount = 0;
>>// for every token
>>CharTermAttribute termAtt =
>> ts.addAttribute(CharTermAttribute.class);
>> + TermFrequencyAttribute tfAtt =
>> ts.addAttribute(TermFrequencyAttribute.class);
>>ts.reset();
>>while (ts.incrementToken()) {
>> String word = termAtt.toString();
>> @@ -838,9 +840,9 @@ public final class MoreLikeThis {
>> // increment frequency
>> Int cnt = termFreqMap.get(word);
>> if (cnt == null) {
>> - termFreqMap.put(word, new Int());
>> + termFreqMap.put(word, new Int(tfAtt.getTermFrequency()));
>> } else {
>> - cnt.x++;
>> + cnt.x += tfAtt.getTermFrequency();
>> }
>>}
>>ts.end();
>> @@ -982,7 +984,11 @@ public final class MoreLikeThis {
>> int x;
>>
>> Int() {
>> - x = 1;
>> + this(1);
>> +}
>> +
>> +Int(int initialValue) {
>> + x = initialValue;
>> }
>>}
>> }
>> diff --git
>> a/lucene/queries/src/test/org/apache/lucene/queries/mlt/TestMoreLikeThis.java
>> b/lucene/queries/src/test/org/apache/lucene/queries/mlt/TestMoreLikeThis.java
>> index 4a60015..aeec534 100644
>> ---
>> a/lucene/queries/src/test/org/apache/lucene/queries/mlt/TestMoreLikeThis.java
>> +++
>> b/lucene/queries/src/test/org/apache/lucene/queries/mlt/TestMoreLikeThis.java
>> @@ -27,7 +27,12 @@ import java.util.Map;
>>
>> import org.apache.lucene.analysis.Analyzer;
>> import org.apache.lucene.analysis.MockAnalyzer;
>> +import org.apache.lucene.analysis.MockTokenFilter;
>> import org.apache.lucene.analysis.MockTokenizer;
>> +import org.apache.lucene.analysis.TokenFilter;
>> +import org.apache.lucene.analysis.TokenStream;
>> +import org.apache.lucene.analysis.tokenattributes.CharTer
[jira] [Resolved] (SOLR-10053) TestSolrCloudWithDelegationTokens failures
[ https://issues.apache.org/jira/browse/SOLR-10053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Risden resolved SOLR-10053. - Resolution: Fixed This test isn't disabled anymore, hasn't been failing, and after upgrade to Hadoop 3 HADOOP-14044 would have been fixed as well. > TestSolrCloudWithDelegationTokens failures > -- > > Key: SOLR-10053 > URL: https://issues.apache.org/jira/browse/SOLR-10053 > Project: Solr > Issue Type: Test > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Ishan Chattopadhyaya >Assignee: Ishan Chattopadhyaya >Priority: Major > Attachments: fail.log, stdout, stdout, stdout, stdout > > > The TestSolrCloudWithDelegationTokens tests fail often at Jenkins. I have > been so far unable to reproduce them using the failing seeds. However, > beasting these tests seem to cause failures (once after about 10-12 runs). > Latest Jenkins failure: > https://builds.apache.org/job/Lucene-Solr-NightlyTests-6.4/12/ > It wasn't apparent what caused these failures. To cut down the noise on > Jenkins, I propose that we disable the test with @AwaitsFix (or bad apple) > annotation and continue to debug and fix this test. > WDYT, [~markrmil...@gmail.com]? -- 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] [Resolved] (SOLR-9586) TestSolrCloudWithDelegationTokens fails regularly on Jenkins runs
[ https://issues.apache.org/jira/browse/SOLR-9586?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Risden resolved SOLR-9586. Resolution: Fixed Looks like this was fixed in SOLR-10053 > TestSolrCloudWithDelegationTokens fails regularly on Jenkins runs > - > > Key: SOLR-9586 > URL: https://issues.apache.org/jira/browse/SOLR-9586 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Alan Woodward >Priority: Major > > Mainly on Windows, sometimes on Solaris. Failing seeds don't reproduce on a > Mac. -- 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-13394) Change default GC from CMS to G1
[ https://issues.apache.org/jira/browse/SOLR-13394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16826974#comment-16826974 ] Kevin Risden commented on SOLR-13394: - [~ichattopadhyaya] - Was this supposed to be changed on the 8.x branch or just on master (9.x) where the switch to JDK 11 was made? > Change default GC from CMS to G1 > > > Key: SOLR-13394 > URL: https://issues.apache.org/jira/browse/SOLR-13394 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Ishan Chattopadhyaya >Assignee: Ishan Chattopadhyaya >Priority: Major > Fix For: 8.1 > > Attachments: SOLR-13394.patch > > Time Spent: 40m > Remaining Estimate: 0h > > CMS has been deprecated in new versions of Java > (http://openjdk.java.net/jeps/291). This issue is to switch Solr default from > CMS to G1. -- 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-13414) SolrSchema - Avoid NPE if Luke returns field with no type defined
[
https://issues.apache.org/jira/browse/SOLR-13414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevin Risden updated SOLR-13414:
Attachment: SOLR-13414.patch
> SolrSchema - Avoid NPE if Luke returns field with no type defined
> -
>
> Key: SOLR-13414
> URL: https://issues.apache.org/jira/browse/SOLR-13414
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Parallel SQL
>Affects Versions: 7.3, 7.7.1
>Reporter: David Barnett
>Assignee: Kevin Risden
>Priority: Minor
> Fix For: 7.7.2, 8.1, master (9.0)
>
> Attachments: SOLR-13414.patch, SOLR-13414.patch,
> before_starting_solr.png, command_prompt.png, luke_out.xml, managed-schema,
> new_solr-8983-console.log, new_solr.log, solr-8983-console.log,
> solr-8983-console.log, solr-core-7.8.0-SNAPSHOT.jar, solr.log
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> *Summary*
> If the underlying Lucene index has fields defined but no type, SolrSchema
> fails with NPE. The index most likely has issues and would be better to
> delete/recreate the index. This ticket adds a null check to prevent the NPE
> and won't break on a potentially invalid index.
> *Initial Description*
> When attempting to create a JDBC sql query against a large collection (400m +
> records) we get a null error.
> After [initial discussion in
> solr-user|http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201904.mbox/%3C1dd6ac3b-e17b-4c29-872e-c7560504a46c%40Spark%3E]
> I have been asked to open this ticket - The exception thrown does not
> provide sufficient detail to understand the underlying problem. Its it
> thought to be an issue with the schema not initialising correctly.
> Attached is the managed-schema after a downconfig.
> Stack trace from email thread:
> *Solr Admin UI Logging*
> {code:java}
> java.io.IOException: Failed to execute sqlQuery 'select id from document
> limit 10' against JDBC connection 'jdbc:calcitesolr:'.
> Error while executing SQL "select id from document limit 10": null
> at
> org.apache.solr.client.solrj.io.stream.JDBCStream.open(JDBCStream.java:271)
> at
> org.apache.solr.client.solrj.io.stream.ExceptionStream.open(ExceptionStream.java:54)
> at
> org.apache.solr.handler.StreamHandler$TimerStream.open(StreamHandler.java:394)
> at
> org.apache.solr.client.solrj.io.stream.TupleStream.writeMap(TupleStream.java:78)
> at
> org.apache.solr.common.util.JsonTextWriter.writeMap(JsonTextWriter.java:164)
> at org.apache.solr.common.util.TextWriter.writeVal(TextWriter.java:69)
> at
> org.apache.solr.response.TextResponseWriter.writeVal(TextResponseWriter.java:152)
> at
> org.apache.solr.common.util.JsonTextWriter.writeNamedListAsMapWithDups(JsonTextWriter.java:386)
> at
> org.apache.solr.common.util.JsonTextWriter.writeNamedList(JsonTextWriter.java:292)
> at
> org.apache.solr.response.JSONWriter.writeResponse(JSONWriter.java:73)
> at
> org.apache.solr.response.JSONResponseWriter.write(JSONResponseWriter.java:66)
> at
> org.apache.solr.response.QueryResponseWriterUtil.writeQueryResponse(QueryResponseWriterUtil.java:65)
> at
> org.apache.solr.servlet.HttpSolrCall.writeResponse(HttpSolrCall.java:788)
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:525)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:395)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:341)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1602)
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:540)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:146)
> at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:257)
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1588)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1345)
[jira] [Updated] (SOLR-13328) HostnameVerifier in HttpClientBuilder is ignored when HttpClientUtil creates connection
[ https://issues.apache.org/jira/browse/SOLR-13328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Risden updated SOLR-13328: Fix Version/s: (was: 8.0.1) (was: 8.1) > HostnameVerifier in HttpClientBuilder is ignored when HttpClientUtil creates > connection > --- > > Key: SOLR-13328 > URL: https://issues.apache.org/jira/browse/SOLR-13328 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: clients - java >Affects Versions: 8.0 >Reporter: jefferyyuan >Priority: Minor > > In SolrHttpClientBuilder, we can configure a lot of things including > HostnameVerifier. > We have code like below: > HttpClientUtil.setHttpClientBuilder(new CommonNameVerifierClientConfigurer()); > CommonNameVerifierClientConfigurer will set our own HostnameVerifier which > checks subject dn name. > But this doesn't work as when we create SSLConnectionSocketFactory at > HttpClientUtil.DefaultSchemaRegistryProvider.getSchemaRegistry() we don't > check and use HostnameVerifier in SolrHttpClientBuilder at all. > The fix would be very simple, at > HttpClientUtil.DefaultSchemaRegistryProvider.getSchemaRegistry, if > HostnameVerifier in SolrHttpClientBuilder is not null, use it, otherwise same > logic as before. -- 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
