Re: Congratulations to the new Lucene PMC Chair, Michael Sokolov!
Congratulations, Mike and thank you! On Thu, Feb 18, 2021 at 3:02 AM Anshum Gupta wrote: > Every year, the Lucene PMC rotates the Lucene PMC chair and Apache Vice > President position. > > This year we nominated and elected Michael Sokolov as the Chair, a > decision that the board approved in its February 2021 meeting. > > Congratulations, Mike! > > -- > Anshum Gupta > -- Regards, Shalin Shekhar Mangar.
Re: Old programmers do fade away
Hi Erick, It's been a pleasure and an honor! I know nothing about squirrels or tomatoes (except that the latter are tasty) but I do know about hobbies so I wish you all the best with them! If you indeed want to be a welder, I am sure that you'll become a good one and probably end up teaching a few folks about it as well :-) Keep us folks in mind and drop us an update from time-to-time. I suggest twitter - it's not new but you might want to sign up for it ;) Take care and have fun! Cheers, Shalin On 1/3/21, Günter Hipler wrote: > Hi Erick > > thanks for your work you have done for the library world. > You were one of the people who made it possible to show libraries the > way to use search engines for their "discovery services". > > Günter > > On 30.12.20 15:09, Erick Erickson wrote: >> 40 years is enough. OK, it's only been 39 1/2 years. Dear Lord, has it >> really been that long? Programming's been fun, I've gotten to solve >> puzzles every day. The art and science of programming has changed over >> that time. Let me tell you about the joys of debugging with a Z80 stack >> emulator that required that you to look on the stack for variables and >> trace function calls by knowing how to follow frame pointers. Oh the >> tedium! Oh the (lack of) speed! Not to mention that 64K of memory was all >> you had to work with. I had a co-worker who could predict the number of >> bytes by which the program would shrink based on extracting common code to >> functions. The "good old days"...weren't... >> >> I'd been thinking that I'd treat Lucene/Solr as a hobby, doing occasional >> work on it when I was bored over long winter nights. I've discovered, >> though, that I've been increasingly reluctant to crack open the code. I >> guess that after this much time, I'm ready to hang up my spurs. One major >> factor is the realization that there's so much going on with Lucene/Solr >> that simply being aware of the changes, much less trying to really >> understand them, isn't something I can do casually. >> >> I bought a welder and find myself more interested in playing with that >> than programming. Wait until you see the squirrel-proof garden enclosure >> I'm building with it. If my initial plan doesn't work, next up is an >> electric fence along the top. The laser-sighted automatic machine gun >> emplacement will take more planning...Ahhh, probably won't be able to get >> a permit from the township for that though. Do you think the police would >> notice? Perhaps I should add that the local police station is two blocks >> away and in the line of fire. But an infrared laser powerful enough to >> "pre-cook" them wouldn't be as obvious would it? >> >> Why am I so fixated on squirrels? One of the joys of gardening is fresh >> tomatoes rather than those red things they sell in the store. The >> squirrels ATE EVERY ONE OF MY TOMATOES WHILE THEY WERE STILL GREEN LAST >> YEAR! And the melons. In the words of B. Bunny: "Of course you realize >> this means war" (https://www.youtube.com/watch?v=4XNr-BQgpd0)... >> >> Then there's working in the garden and landscaping, the desk I want to >> build for my wife, travel as soon as I can, maybe seeing if some sailboats >> need crew...you get the idea. >> >> It's been a privilege to work with this group, you're some of the best and >> brightest. Many thanks to all who've generously given me their time and >> guidance. It's been a constant source of amazement to me how willing >> people are to take time out of their own life and work to help me when >> I've had questions. I owe a lot of people beers ;) >> >> I'll be stopping my list subscriptions, Slack channels (dm me if you need >> something), un-assigning any JIRAs and that kind of thing over the next >> while. If anyone's interested in taking over the BadApple report, let me >> know and I can put the code up somewhere. It takes about 10 minutes to do >> each week. I won't disappear entirely, things like the code-reformatting >> effort are nicely self-contained for instance and something I can to >> casually. >> >> My e-mail address if you need to get in touch with me is: >> "erick.erick...@gmail.com". There's a correlation between gmail addresses >> that are just a name with no numbers and a person's age... A co-worker >> came over to my desk in pre-historical times and said "there's this new >> mail service you might want to sign up for"... Like I said, 40 years is >> enough. >> >> Best to all, >> Erick >>
Re: [Apache Solr] Twitter Account
Hi Ishan I almost missed this thread. I do own and manage the ApacheSolr twitter handle and I am happy to share credentials with you (or any other committer for that matter). I'll DM you on the ASF Slack. On Sun, Dec 6, 2020 at 9:20 AM Ishan Chattopadhyaya < ichattopadhy...@gmail.com> wrote: > I can volunteer. I am fairly regular with Twitter and release management. > @Shalin > Shekhar Mangar , if needed, please let me know. > > On Sun, 6 Dec, 2020, 6:59 am Marcus Eagan, wrote: > >> One of the committers should pick it up, make release announcements, and >> share important insights with the community periodically. >> >> On Sat, Dec 5, 2020 at 14:06 Anshum Gupta wrote: >> >>> Yes, I agree that it should be more active, but that's not really an >>> official 'Apache' Solr account :) >>> >>> I know at some point Shalin tried to find someone who would be up for it >>> and manage it, but considering we are all volunteering, it's tough to keep >>> up and he didn't get any volunteers. >>> >>> As of now it's just a dormant account w.r.t. activity. >>> >>> On Sat, Dec 5, 2020 at 2:40 AM Alessandro Benedetti < >>> abenede...@apache.org> wrote: >>> >>>> Hi, >>>> I noticed the Apache Solr twitter account not to be that active >>>> anymore. >>>> There are not even a tweet - > release 1 to 1 matching. >>>> Not to mention the countless interesting blog posts Solr related, that >>>> could benefit the community if better shared. >>>> >>>> In my opinion, that's a shame, given the good number of followers the >>>> account has. >>>> Who's managing it? >>>> >>>> I understand that the management of that page must be unbiased, sharing >>>> interesting posts, without direct commercial purpose, given the fact many >>>> companies (including mine) make a living out of Apache Solr (but also give >>>> back to the community in form of blogs and contributions). >>>> >>>> >>>> >>>> Regards >>>> >>> >>> >>> -- >>> Anshum Gupta >>> >> -- >> Marcus Eagan >> >> -- Regards, Shalin Shekhar Mangar.
Re: Welcome Houston Putman to the PMC
Congratulations Houston! On Wed, Dec 2, 2020 at 2:50 AM Mike Drob wrote: > I am pleased to announce that Houston Putman has accepted the PMC's > invitation to join. > > Congratulations and welcome, Houston! > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > > -- Regards, Shalin Shekhar Mangar.
Re: Welcome Julie Tibshirani as Lucene/Solr committer
Congratulations and welcome Julie! On Wed, Nov 18, 2020 at 8:38 PM Michael Sokolov wrote: > I'm pleased to announce that Julie Tibshirani has accepted the PMC's > invitation to become a committer. > > Julie, the tradition is that new committers introduce themselves with > a brief bio. > > I think we may still be sorting out the details of your Apache account > (julie@ may have been taken?), but as soon as that has been sorted out > and karma has been granted, you can use your new powers to add > yourself to the committers section of the Who We Are page on the > website: <http://lucene.apache.org/whoweare.html> > > Congratulations and welcome! > > Mike Sokolov > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > > -- Regards, Shalin Shekhar Mangar.
Re: 8.7 Release
Also strangely, Solr's CHANGES.txt on branch_8x has two 8.7.0 sections! On Sat, Oct 24, 2020 at 5:40 PM Shalin Shekhar Mangar < shalinman...@gmail.com> wrote: > FYI - I have added a 8.8.0 section in Solr's change log on master as part > of SOLR-14942 > > On Wed, Oct 21, 2020 at 1:36 PM Atri Sharma wrote: > >> Please go ahead. >> >> I will add the section today. I believed the section is added once the >> RC1 is generated — but let me get this done. Thanks for pointing it out. >> >> On Wed, 21 Oct 2020 at 07:01, Houston Putman >> wrote: >> >>> I will be committing SOLR-14907 >>> <https://issues.apache.org/jira/browse/SOLR-14907> tomorrow, which >>> provides a V2 API for a feature that was added with a V1 endpoint. Would >>> you mind if I add this to branch_8_7 Atri? >>> >>> On a side note, I am making a PR for something that doesn't have to be >>> included in 8_7. I notice there isn't an 8.8.0 CHANGES.txt section yet in >>> master or 8x. The next minor/major version sections should get created when >>> minor/major version branches are cut, right? Please correct me if I'm wrong >>> on that. (I looked at the releaseWizard, and this looks like the case) >>> >>> >>> - Houston >>> >>> On Tue, Oct 20, 2020 at 5:36 AM Ishan Chattopadhyaya < >>> ichattopadhy...@gmail.com> wrote: >>> >>>> I have no bandwidth to tackle the deprecations, nor the energy to fight >>>> those who oppose it. >>>> >>>> On Tue, 20 Oct, 2020, 2:43 pm Atri Sharma, wrote: >>>> >>>>> There are release blockers for 8_7: >>>>> >>>>> https://issues.apache.org/jira/browse/SOLR-14354 >>>>> https://issues.apache.org/jira/browse/SOLR-13973 >>>>> https://issues.apache.org/jira/browse/SOLR-14067 >>>>> >>>>> On Tue, Oct 20, 2020 at 1:23 PM Jan Høydahl >>>>> wrote: >>>>> > >>>>> > I pushed SOLR-14936 that I mentioned yesterday - a non-code bugfix >>>>> for Grafana dashboard json. >>>>> > >>>>> > Jan >>>>> > >>>>> > 19. okt. 2020 kl. 19:19 skrev Adrien Grand : >>>>> > >>>>> > FYI I pushed a fix for a test-only bug introduced by LUCENE-9524. >>>>> > >>>>> > On Mon, Oct 19, 2020 at 2:47 PM Jan Høydahl >>>>> wrote: >>>>> >> >>>>> >> I’d like to merge in SOLR-14936 to 8.7. It’s a non-code change >>>>> which fixes a bug in grafana dashboard JSON. >>>>> >> >>>>> >> Jan >>>>> >> >>>>> >> > 19. okt. 2020 kl. 11:54 skrev Atri Sharma : >>>>> >> > >>>>> >> > Fixed the issue. Cherry picking to branch_8_7 now. >>>>> >> > >>>>> >> > Apologies, I must have created branch_8_x accidentally. Let me >>>>> delete. >>>>> >> > >>>>> >> > On Mon, Oct 19, 2020 at 1:40 AM Adrien Grand >>>>> wrote: >>>>> >> >> >>>>> >> >> 1. This is failing 8.7 builds, e.g. >>>>> https://builds.apache.org/job/Lucene/job/Lucene-Solr-Tests-8.7/3/console, >>>>> so yes we should backport to 8.7. >>>>> >> >> By the way I don't understand why you created a branch_8_x >>>>> branch in addition to branch_8x, was it a mistake? The release wizard >>>>> doesn't seem to be recommending something like that? >>>>> >> >> >>>>> >> >> 2. Yes this is actually the point of cutting a branch, this >>>>> helps reduce chances of introducing blockers while we're working on >>>>> addressing the existing blockers. >>>>> >> >> >>>>> >> >> On Sun, Oct 18, 2020 at 9:50 PM Atri Sharma >>>>> wrote: >>>>> >> >>> >>>>> >> >>> BTw, guidance needed: >>>>> >> >>> >>>>> >> >>> 1. The doc fixes I need to do for this, should I be backporting >>>>> them to branch_8_7, or apply them to branch_8_x and cut a new branch? >>>>> >> >>> >>>>> >> >>> 2. I still see blocker issues on 8.7 (thanks Ishan!) — is it >>>>>
Re: 8.7 Release
>>>>>>>>>>>>>> Christine >>>> >>
Re: Welcome Atri Sharma to the PMC
Congratulations and welcome Atri! On Thu, Aug 20, 2020 at 11:46 PM Ishan Chattopadhyaya < ichattopadhy...@gmail.com> wrote: > I am pleased to announce that Atri Sharma has accepted the PMC's > invitation to join. > > Congratulations and welcome, Atri! > > > -- Regards, Shalin Shekhar Mangar.
Re: Welcome Namgyu Kim to the PMC
Congratulations and welcome, Namgyu! On Mon, Aug 3, 2020 at 4:49 AM Ishan Chattopadhyaya < ichattopadhy...@gmail.com> wrote: > I am pleased to announce that Namgyu Kim has accepted the PMC's > invitation to join. > > Congratulations and welcome, Namgyu! > -- Regards, Shalin Shekhar Mangar.
Re: Welcome Gus Heck to the PMC
Congratulations and welcome, Gus! On Mon, Aug 3, 2020 at 4:51 AM Ishan Chattopadhyaya < ichattopadhy...@gmail.com> wrote: > I am pleased to announce that Gus Heck has accepted the PMC's invitation > to join. > > Congratulations and welcome, Gus! > -- Regards, Shalin Shekhar Mangar.
Re: Welcome Munendra SN to the PMC
Congratulations and welcome, Munendra! On Mon, Aug 3, 2020 at 4:50 AM Ishan Chattopadhyaya < ichattopadhy...@gmail.com> wrote: > I am pleased to announce that Munendra SN has accepted the PMC's > invitation to join. > > Congratulations and welcome, Munendra! > -- Regards, Shalin Shekhar Mangar.
Re: [VOTE] Release Lucene/Solr 8.6.0 RC1
+1 SUCCESS! [0:47:49.133876] On Wed, Jul 8, 2020 at 2:26 PM Bruno Roustant wrote: > Please vote for release candidate 1 for Lucene/Solr 8.6.0 > > The artifacts can be downloaded from: > > > https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.6.0-RC1-reva9c5fb0da2dfc8c7375622c80dbf1a0cc26f44dc > > You can run the smoke tester directly with this command: > > python3 -u dev-tools/scripts/smokeTestRelease.py \ > > https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.6.0-RC1-reva9c5fb0da2dfc8c7375622c80dbf1a0cc26f44dc > > The vote will be open for at least 72 hours i.e. until 2020-07-11 09:00 > UTC. > > [ ] +1 approve > [ ] +0 no opinion > [ ] -1 disapprove (and reason why) > > Here is my +1 > -- Regards, Shalin Shekhar Mangar.
Re: Welcome Tomoko Uchida to the PMC
Congratulations and welcome, Tomoko! On Sat, Jul 4, 2020 at 11:56 AM Adrien Grand wrote: > I am pleased to announce that Tomoko Uchida has accepted the PMC's > invitation to join. > > Welcome Tomoko! > > -- > Adrien > -- Regards, Shalin Shekhar Mangar.
Re: Welcome Michael Sokolov to the PMC
Congratulations and welcome, Michael! On Fri, Jul 3, 2020 at 5:27 PM Adrien Grand wrote: > I am pleased to announce that Michael Sokolov has accepted the PMC's > invitation to join. > > Welcome Michael! > > -- > Adrien > -- Regards, Shalin Shekhar Mangar.
Re: Welcome Ilan Ginzburg as Lucene/Solr committer
Congratulations and welcome Ilan! On Sun, Jun 21, 2020 at 3:14 PM 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 > -- Regards, Shalin Shekhar Mangar.
Re: How to build SolrCloud collection from instance dirs after ZK is lost?
Hi Mikhail, 1. Create an empty collection with the same number of shards as before 2. Set legacyCloud cluster property to true (it is false by default) using: ./server/scripts/cloud-scripts/zkcli.sh -zkhost 127.0.0.1:2181 -cmd clusterprop -name legacyCloud -val true 3. Bring your solr nodes back online, they should register themselves to ZK as they used to do in old versions of Solr But as always in such cases, take snapshots of those persistent disks and test before you execute :) Also, be aware of this bug: https://issues.apache.org/jira/browse/SOLR-11503 when in future you want to turn off legacyCloud mode. Good luck! On Thu, Jun 18, 2020 at 1:06 PM Mikhail Khludnev wrote: > Hello, > I'm challenged with cluster recovery. Think about total failure: ZK state > is lost, however instanceDirs survived since they are mounted via EBS. > Let's say collection is read/only and/or it doesn't have replicas, just > leaders. > Is there a way to create a new empty collection and say, hey here's shard1 > instance, shard2 instance is there etc? > > Customer says that the old version of solr does it automatically: when > empty zk is connected, collection's shards just appear there. Right now due > to https://issues.apache.org/jira/browse/SOLR-12066 Cleanup deleted core > when node start - if instances with data dirs connect to empty ZK it just > wipes dirs away. > > Thanks > -- > Sincerely yours > Mikhail Khludnev > -- Regards, Shalin Shekhar Mangar.
Re: [VOTE] Release Lucene/Solr 8.5.2 RC1
+1 SUCCESS! [0:47:23.934909] On Wed, May 20, 2020 at 11:28 PM Mike Drob wrote: > Devs, > > Please vote for release candidate 1 for Lucene/Solr 8.5.2 > > The artifacts can be downloaded from: > > https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.5.2-RC1-rev384dadd9141cec3f848d8c416315dc2384749814 > > 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.2-RC1-rev384dadd9141cec3f848d8c416315dc2384749814 > > The vote will be open until 2020-05-26 18:00 UTC (extended deadline due to > multiple holidays in the next 72 hours) > > [ ] +1 approve > [ ] +0 no opinion > [ ] -1 disapprove (and reason why) > > Here is my +1 (non-binding) > > Mike > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > > -- Regards, Shalin Shekhar Mangar.
Re: [VOTE] Solr to become a top-level Apache project (TLP)
+1 (binding) On Tue, May 12, 2020 at 1:07 PM 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 > > -- Regards, Shalin Shekhar Mangar.
Re: Overseer documentation
This is good stuff Ilan. Thank you for writing and sharing with us. I intend to take a deeper look at this next week. On Wed, Apr 22, 2020 at 2:36 AM Ilan Ginzburg wrote: > Hello Solr devs, > > This is my first post here. I work at Salesforce in France, we're > adopting SolrCloud and we need it to scale more than it currently > does. > > I've looked at Overseer and documented my understanding. I'm sharing > the result, it might help others and is a way to get feedback (I might > have misunderstood some things) and/or collaboration on continuing > documenting the implementation. Basically I started writing the doc I > wanted to find. > > In the process, I believe I've identified what may be a few bugs > (there's a section listing them at the beginning). I've found these by > reading code (not running code), so take with a grain of salt. > I plan to file Jiras for those bugs that do seem real and are > important enough, and then also start working on some to help > fix/improve. > > > https://docs.google.com/document/d/1KTHq3noZBVUQ7QNuBGEhujZ_duwTVpAsvN3Nz5anQUY/ > > This is WIP. Please do not hesitate to provide feedback/leave comments. > > Thanks, > Ilan > > - > 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 Eric Pugh as a Lucene/Solr committer
Congratulations and welcome Eric! On Mon, Apr 6, 2020 at 5:51 PM 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 > > -- Regards, Shalin Shekhar Mangar.
Re: Welcome Alessandro Benedetti as a Lucene/Solr committer
Congratulations and welcome Alessandro! On Wed, Mar 18, 2020 at 6:31 PM 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 > -- Regards, Shalin Shekhar Mangar.
Re: 8.5 release
+1 On Tue, Feb 18, 2020 at 7:58 AM Alan Woodward wrote: > Hi all, > > It’s been a while since we released lucene-solr 8.4, and we’ve accumulated > quite a few nice new features since then. I’d like to volunteer to be a > release manager for an 8.5 release. If there's agreement, then I plan to > cut the release branch two weeks today, on Tuesday 3rd March. > > - Alan > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > > -- Regards, Shalin Shekhar Mangar.
Re: Odd error in testing
I saw this as well on a Ubuntu Linux box running openjdk 11.0.6. The failures were 100% reproducible. I followed https://github.com/AdoptOpenJDK/openjdk-build/issues/682 and see that a suggestion is to install fontconfig package. Unfortunately this box is running an old version and I must upgrade to install fontconfig so I'll try that later. Putting this here just in case someone runs into it again. java -version openjdk version "11.0.6" 2020-01-14 OpenJDK Runtime Environment AdoptOpenJDK (build 11.0.6+10) OpenJDK 64-Bit Server VM AdoptOpenJDK (build 11.0.6+10, mixed mode) On Tue, Dec 11, 2018 at 11:45 PM David Smiley wrote: > I wonder why RRD4J is doing any AWT stuff at all. I thought we were just > using it to *hold* data, not to visualize. ab? > > On Sun, Dec 9, 2018 at 3:27 AM Erick Erickson > wrote: > >> I reformatted the entire disk on my old machine and installed Mojave >> fresh then ran tests. >> >> MetricsHistoryIntegrationTest.testGet fails on my old (reformatted, >> freshly installed Mojave) with the bits below. It does _not_ fail on >> any other machine. >> >> Weird bits about: >> >> Caused by: java.lang.RuntimeException: java.io.IOException: Problem >> reading font data. >> >> Unfortunately it doesn't really say _which_ font. >> >> Anyone seen this before? I've seen a couple of references on the web >> to permissions in the tmp dir and downloading a particular font, but >> those have been fruitless. The tmp dir has the same permissions on >> both machines and the machine that succeeds doesn't even have the >> dejavu fonts suggested by StackOverflow. >> >> Any clues? >> >> [junit4]> Caused by: java.lang.RuntimeException: >> java.io.IOException: Problem reading font data. >>[junit4]> at >> >> org.rrd4j.graph.RrdGraphConstants$FontConstructor.getFont(RrdGraphConstants.java:287) >>[junit4]> at >> org.rrd4j.graph.RrdGraphConstants.(RrdGraphConstants.java:304) >>[junit4]> ... 11 more >>[junit4]> Caused by: java.io.IOException: Problem reading font >> data. >>[junit4]> at java.awt.Font.createFont0(Font.java:1000) >>[junit4]> at java.awt.Font.createFont(Font.java:877) >>[junit4]> at >> >> org.rrd4j.graph.RrdGraphConstants$FontConstructor.getFont(RrdGraphConstants.java:283) >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >> For additional commands, e-mail: dev-h...@lucene.apache.org >> >> -- > Lucene/Solr Search Committer (PMC), Developer, Author, Speaker > LinkedIn: http://linkedin.com/in/davidwsmiley | Book: > http://www.solrenterprisesearchserver.com > -- Regards, Shalin Shekhar Mangar.
Re: Congratulations to the new Lucene/Solr PMC Chair, Anshum Gupta!
Congratulations Anshum! On Thu, Jan 16, 2020 at 2:45 AM Cassandra Targett wrote: > 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 > > -- Regards, Shalin Shekhar Mangar.
Re: [VOTE] Release Lucene/Solr 8.4.0 RC2
+1 SUCCESS! [0:48:58.719194] On Fri, Dec 20, 2019 at 4:53 AM Adrien Grand wrote: > 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 > -- Regards, Shalin Shekhar Mangar.
Re: [VOTE] Release Lucene/Solr 8.4.0 RC1
+1 SUCCESS! [0:50:00.981792] On Tue, Dec 17, 2019 at 11:53 PM Adrien Grand wrote: > Please vote for release candidate 1 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-RC1-revc91d36f50efb62e55bcc3a1adc0442b207018670 > > 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-RC1-revc91d36f50efb62e55bcc3a1adc0442b207018670 > > The vote will be open for at least 3 working days, i.e. until 2019-12-20 > 19:00 UTC. > > [ ] +1 approve > [ ] +0 no opinion > [ ] -1 disapprove (and reason why) > > Here is my +1 > > -- > Adrien > -- Regards, Shalin Shekhar Mangar.
Re: [VOTE] Release Lucene/Solr 8.3.1 RC2
+1 SUCCESS! [0:49:22.229435] On Fri, Nov 29, 2019 at 2:38 PM Ishan Chattopadhyaya < ichattopadhy...@gmail.com> wrote: > Please vote for release candidate 2 for Lucene/Solr 8.3.1 > > The artifacts can be downloaded from: > > https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.3.1-RC2-reva3d456fba2cd1b9892defbcf46a0eb4d4bb4d01f > > 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.1-RC2-reva3d456fba2cd1b9892defbcf46a0eb4d4bb4d01f > > The vote will be open for at least 72 hours from now. > > [x] +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: [VOTE] Release Lucene/Solr 8.3.1 RC1
Ishan, the smoke tester fails with the following error:
Test Solr...
test basics...
check changes HTML...
Traceback (most recent call last):
File "dev-tools/scripts/smokeTestRelease.py", line 1485, in
main()
File "dev-tools/scripts/smokeTestRelease.py", line 1411, in main
downloadOnly=c.download_only)
File "dev-tools/scripts/smokeTestRelease.py", line 1469, in smokeTest
checkSigs('solr', solrPath, version, tmpDir, isSigned, keysFile)
File "dev-tools/scripts/smokeTestRelease.py", line 321, in checkSigs
testChanges(project, version, changesURL)
File "dev-tools/scripts/smokeTestRelease.py", line 369, in testChanges
checkChangesContent(s, version, changesURL, project, True)
File "dev-tools/scripts/smokeTestRelease.py", line 428, in
checkChangesContent
raise RuntimeError('%s has duplicate section "%s" under release "%s"' %
(name, text, release))
RuntimeError:
https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.3.1-RC1-rev049d53ebd6e0b2eba3f9c516f3645c821ba97bc1/solr/changes/Changes.html
has duplicate section "Release 8.3.1 " under release "8.3.1"
On Fri, Nov 29, 2019 at 5:17 AM Ishan Chattopadhyaya <
ichattopadhy...@gmail.com> wrote:
> Please vote for release candidate 1 for Lucene/Solr 8.3.1
>
> The artifacts can be downloaded from:
>
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.3.1-RC1-rev049d53ebd6e0b2eba3f9c516f3645c821ba97bc1
>
> 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.1-RC1-rev049d53ebd6e0b2eba3f9c516f3645c821ba97bc1
>
> The vote will be open for 72 hours from now.
>
> [x] +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: 8.3.1 release
+1 On Mon, Nov 25, 2019 at 11:20 AM Noble Paul wrote: > +1 > > On Mon, Nov 25, 2019 at 4:49 PM Ishan Chattopadhyaya > wrote: > > > > Hi, > > Recently, Colvin has reported > > https://issues.apache.org/jira/browse/SOLR-13963. Effect of this is > > that Solr 8.3 must not be used out of the box due to the reported data > > loss. I propose we fix this as soon as possible and release 8.3.1. I > > am volunteering as RM for this. > > Any thoughts? > > Regards, > > Ishan > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > > For additional commands, e-mail: dev-h...@lucene.apache.org > > > > > -- > - > Noble Paul > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > > -- Regards, Shalin Shekhar Mangar.
Re: Lucene/Solr 8.4
+1 On Fri, Nov 22, 2019 at 2:08 PM Adrien Grand wrote: > Hello all, > > With Thanksgiving and then Christmas coming up, this is going to be a > busy time for most of us. I'd like to get a new release before the end > of the year, so I'm proposing the following schedule for Lucene/Solr > 8.4: > - cutting the branch on December 12th > - building the first RC on December 14th > and hopefully we'll have a release in the following week. > > -- > Adrien > > - > 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 Bruno Roustant as Lucene/Solr committer
Congratulations and welcome Bruno! On Sun, Nov 24, 2019 at 3:25 AM Bruno Roustant wrote: > Thank you all for this warm welcome. > > A couple of words about me: > I live in France with my family, in Grenoble near the Alps. Since my very > first work experience (2000), I have been developing around Search and > Java. Federated Search, result clustering, more like this, etc. When I > joined Salesforce in 2013, I had the opportunity to start using > Lucene-Solr. Exploring the beast as a user at the beginning, and then > developing plugins. Since 2016 we had stronger performance goals, for lots > of fields and security constraints, and this gave me again the opportunity > to dive into the mechanics, the APIs, the queries. What a nice surprise to > discover this strong project with refined interfaces, carefully crafted > algorithms, and high test quality bar! Soon another opportunity made me > work with David Smiley, who advocated convincingly the benefits of > open-sourcing. That was a succession of opportunities that led me here, > becoming a committer, part of this projet! > I like data structure and algorithm challenges. I have experience in > performance/memory optimization. I like team work and I’m discovering the > open-source power :) > > Thanks again, I can’t wait to contribute more with you. > > Le sam. 23 nov. 2019 à 21:51, Rahul Yadav a écrit : > >> Apologies , Sure will do. >> >> Regards >> Rahul >> >> On Sat, Nov 23, 2019 at 8:46 PM David Smiley >> wrote: >> >>> Please start a new thread instead of replying to this thread. >>> >>> On Sat, Nov 23, 2019 at 3:14 PM Rahul Yadav >>> wrote: >>> >>>> Hi All , >>>> >>>> I have just joined(new dev) here. >>>> I have had some experience in Information Retrieval and Search and >>>> would like to contribute to the community. >>>> as i am just setting up , it would be helpful if there is any >>>> task/bug/(Starter Level) that i can work on. >>>> >>>> >>>> Regards >>>> Rahul >>>> https://www.linkedin.com/in/rahul-y-26b6b1142/ >>>> >>>> On Sat, Nov 23, 2019 at 6:18 PM Namgyu Kim wrote: >>>> >>>>> Congratulations and welcome, Bruno! :D >>>>> >>>>> On Sun, Nov 24, 2019 at 2:16 AM Ishan Chattopadhyaya < >>>>> ichattopadhy...@gmail.com> wrote: >>>>> >>>>>> Welcome Bruno! >>>>>> >>>>>> On Sat, 23 Nov, 2019, 10:35 PM David Smiley, < >>>>>> david.w.smi...@gmail.com> wrote: >>>>>> >>>>>>> Congratulations and welcome Bruno! We always need more eyes on the >>>>>>> low level Lucene bits. >>>>>>> >>>>>>> ~ David Smiley >>>>>>> Apache Lucene/Solr Search Developer >>>>>>> http://www.linkedin.com/in/davidwsmiley >>>>>>> >>>>>>> >>>>>>> On Sat, Nov 23, 2019 at 3:29 AM Adrien Grand >>>>>>> wrote: >>>>>>> >>>>>>>> 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 >>>>>>>> >>>>>>>> -- >>> Sent from Gmail Mobile >>> >> -- Regards, Shalin Shekhar Mangar.
Re: Welcome Houston Putman as Lucene/Solr committer
Congratulations and welcome Houston! On Thu, Nov 14, 2019 at 12:39 PM Houston Putman wrote: > Thanks everyone! > > As requested, a brief history of me: > > A native Austinite, I went to The University of Texas at Austin. Back in > 2013 I lucked into an internship with Bloomberg working on a new Search > Infrastructure team. There I had my first exposure to Solr and built the > first iteration of the Analytics Component. Since graduating in 2016, > moving up to NYC and starting at Bloomberg full time, I have been working > on Solr in various ways, from rewriting the Analytics Component to adding > some features to various parts of SolrJ and fixing some weirdness in pivot > facets. > > Lately I’ve been working (and presenting) on running Solr on Kubernetes. > We’ve open sourced a Solr Kubernetes operator ( > https://github.com/bloomberg/solr-operator), which is currently being > developed with help from across the community. Our goal is to make this a > standard and flexible way of running Solr in a cloud environment, which > includes making Solr itself run better in the cloud. > > I can’t wait to continue working with y’all and making Solr as great as it > can be! > > > - Houston Putman > > On Thu, Nov 14, 2019 at 2:24 PM Varun Thacker wrote: > >> Congratulations and welcome Houston! >> >> On Thu, Nov 14, 2019 at 9:32 AM Tomás Fernández Löbbe < >> tomasflo...@gmail.com> wrote: >> >>> Welcome Houston! >>> >>> On Thu, Nov 14, 2019 at 9:09 AM Kevin Risden wrote: >>> >>>> 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 >>>>> >>>>> -- Regards, Shalin Shekhar Mangar.
Re: Proposal: Solr Security news-feed
+1 On Mon, Nov 4, 2019 at 2:50 PM Jan Høydahl wrote: > Hi, > > I'm proposing to add security announcements RSS/Atom feed to the web site. > > We're in the process of migrating our web site to Git and in that same > process we also change CMS from an ASF one to Pelican. The new site has > built-in support for news posts as individual files and also RSS feeds of > those. So I propose to add https://lucene.apache.org/solr/security.html > to the site, including a list of newest CVEs and an RSS/Atom feed to go > along with it. This way users have ONE place to visit to check security > announcements and they can monitor RSS to be alerted once we post a new > announcement. > > We could also add RSS feeds for Lucene-core news and Solr-news sections > of course. > > At the same time I propose that the news on the front-page > lucene.apache.org > is replaced with widgets that show the title only of the last 3 > announcements > from Lucene, Solr and PyLucene sub projects. That front page is waaay > too long :) > > -- > 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 > > -- Regards, Shalin Shekhar Mangar.
Re: [VOTE] Release Lucene/Solr 8.3.0 RC2
-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 > > > > -- Regards, Shalin Shekhar Mangar.
Re: [VOTE] Release Lucene/Solr 8.3.0 RC2
+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: 8.3 release
SOLR-13843 has also been committed to master, branch_8x and branch_8_3. Thanks! On Sat, Oct 19, 2019 at 1:33 AM Andrzej Białecki wrote: > SOLR-13677 is done. Thanks for your patience! > > On 18 Oct 2019, at 10:46, Ishan Chattopadhyaya > wrote: > > Sure Shalin, please go ahead. I'm still waiting for SOLR-13677 to be > resolved. > Thanks! > > On Fri, 18 Oct, 2019, 10:24 AM Shalin Shekhar Mangar, < > shalinman...@gmail.com> wrote: > >> Hi Ishan, >> >> Is it okay to push https://issues.apache.org/jira/browse/SOLR-13843 to >> 8.3 release? The patch is ready and tested and all I need is to commit and >> merge it to the various branches. >> >> On Thu, Oct 17, 2019 at 4:37 AM Jan Høydahl >> wrote: >> >>> https://issues.apache.org/jira/browse/SOLR-13835 is merged. >>> >>> -- >>> Jan Høydahl, search solution architect >>> Cominvent AS - www.cominvent.com >>> >>> 16. okt. 2019 kl. 22:15 skrev Cassandra Targett : >>> >>> Done, Ishan, thanks! >>> >>> Cassandra >>> On Oct 16, 2019, 2:37 PM -0500, Ishan Chattopadhyaya < >>> ichattopadhy...@gmail.com>, wrote: >>> >>> +1, Cassandra! Thanks. >>> >>> On Wed, 16 Oct, 2019, 11:41 PM Cassandra Targett, >>> wrote: >>> >>>> Sorry, I meant branch_8_3. >>>> >>>> Cassandra >>>> On Oct 16, 2019, 12:59 PM -0500, Cassandra Targett < >>>> casstarg...@gmail.com>, wrote: >>>> >>>> I just committed to master and branch_8x >>>> https://issues.apache.org/jira/browse/SOLR-12786 to update the >>>> versions of tools we use for building the Ref Guide. I’d like to commit >>>> that into branch_8_x if you don’t mind, Ishan? It’s not urgent, though. >>>> >>>> Cassandra >>>> On Oct 16, 2019, 11:36 AM -0500, Alan Woodward , >>>> wrote: >>>> >>>> LUCENE-9005 is committed. >>>> >>>> On 16 Oct 2019, at 17:12, Jan Høydahl wrote: >>>> >>>> SOLR-13835 <https://issues.apache.org/jira/browse/SOLR-13835> is also >>>> almost there. >>>> >>>> Jan Høydahl >>>> >>>> 16. okt. 2019 kl. 16:53 skrev Adrien Grand : >>>> >>>> Hi Ishan, >>>> >>>> LUCENE-8920 needs more work indeed, but it is not blocking this release. >>>> >>>> On Wed, Oct 16, 2019 at 3:54 PM Ishan Chattopadhyaya >>>> wrote: >>>> >>>> >>>> Hi, >>>> >>>> Here are the issues that remain to be resolved for 8.3. >>>> >>>> >>>> LUCENE-8920: Committed, but not resolved. More work remains? >>>> >>>> LUCENE-9005: Patch available, not committed. >>>> >>>> SOLR-13677: Patch available, not committed. Need another day to >>>> >>>> complete cleanup and tests. >>>> >>>> >>>> I'll wait until all of them are finished and then proceed to build the >>>> RC1. >>>> >>>> Thanks and regards, >>>> >>>> Ishan >>>> >>>> >>>> On Tue, Oct 15, 2019 at 2:58 PM Ishan Chattopadhyaya >>>> >>>> wrote: >>>> >>>> >>>> Sure, Noble, thanks! Next time, please use a single commit to revert >>>> >>>> such features (you just used up 3 commits). branch_8_3's history is >>>> >>>> now littered with SOLR-13821 commits and reverts that shouldn't have >>>> >>>> been there :-) >>>> >>>> >>>> Thanks, Jan! >>>> >>>> >>>> On Tue, Oct 15, 2019 at 12:17 AM Noble Paul >>>> wrote: >>>> >>>> >>>> Hi, >>>> >>>> I'll revert the package store commits related to SOLR-13821 in the 8.3 >>>> >>>> branch. It is supposed to be used by the (SOLR-13822) and it is not a >>>> >>>> part of the 8.3 release. >>>> >>>> --Noble >>>> >>>> >>>> On Tue, Oct 15, 2019 at 5:22 AM Adrien Grand wrote: >>>> >>>> >>>> Hi Ishan, >>>> >>>> >>>> The release is no longer blocked on LUCENE-8920. >>>> >>>> >>>> On Thu, Oct 10, 2019 at 6:18 PM Ishan Chattopadhyaya >>>> >>>>
Re: 8.3 release
complaining about this. I have the feeling it also >> happens from time to time during inter node comm, which uses solrj, too. >> >> >> Uwe >> >> >> Am October 9, 2019 1:38:00 PM UTC schrieb Ishan Chattopadhyaya < >> ichattopadhy...@gmail.com>: >> >> >> +1, Dat! Please go ahead. >> >> >> On Wed, 9 Oct, 2019, 2:33 PM Andrzej Białecki, wrote: >> >> >> It’s marked as Minor in Jira, but after reading the description it sounds >> scary - IMHO it should be at least well investigated before 8.3 in order to >> determine whether it causes real damage (apart from looking scary and >> filling the logs). >> >> >> +1 from me. >> >> >> On 9 Oct 2019, at 10:48, Đạt Cao Mạnh wrote: >> >> >> Hi Ishan, guys >> >> >> I want to include the fix for >> https://issues.apache.org/jira/browse/SOLR-13293 in this release. Hoping >> that is ok! >> >> >> Thanks! >> >> >> On Tue, Oct 8, 2019 at 4:02 PM Uwe Schindler wrote: >> >> >> ASF Jenkins Jobs also reconfigured. >> >> >> I left the 8.2 Refguide job in the queue (I cloned it), not sure if that >> one is still needed. All other jobs are 8.3 now. >> >> >> Uwe >> >> >> - >> >> Uwe Schindler >> >> Achterdiek 19, D-28357 Bremen >> >> https://www.thetaphi.de >> >> eMail: u...@thetaphi.de >> >> >> > >> > -- Regards, Shalin Shekhar Mangar.
Re: Welcome Atri Sharma as Lucene/Solr committer
Congratulations and welcome Atri! 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 > > -- Regards, Shalin Shekhar Mangar.
[jira] [Commented] (SOLR-13737) Lead with SolrCloud
[ https://issues.apache.org/jira/browse/SOLR-13737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16922181#comment-16922181 ] Shalin Shekhar Mangar commented on SOLR-13737: -- PR is at https://github.com/apache/lucene-solr/pull/853 > Lead with SolrCloud > --- > > Key: SOLR-13737 > URL: https://issues.apache.org/jira/browse/SOLR-13737 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: documentation >Affects Versions: master (9.0) >Reporter: Marcus Eagan >Priority: Trivial > Fix For: master (9.0) > > > Based on some of the unnecessary and non-constructive criticism I have heard > that SolrCloud is an after thought in 2019, which is totally not true, I > decided it might be better if we moved it up ahead of standalone Solr in the > README. -- 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-13737) Lead with SolrCloud
[ https://issues.apache.org/jira/browse/SOLR-13737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16921978#comment-16921978 ] Shalin Shekhar Mangar commented on SOLR-13737: -- +1 > Lead with SolrCloud > --- > > Key: SOLR-13737 > URL: https://issues.apache.org/jira/browse/SOLR-13737 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: documentation >Affects Versions: master (9.0) >Reporter: Marcus Eagan >Priority: Trivial > Fix For: master (9.0) > > > Based on some of the unnecessary and non-constructive criticism I have heard > that SolrCloud is an after thought in 2019, which is totally not true, I > decided it might be better if we moved it up ahead of standalone Solr in the > README. -- 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] [Resolved] (SOLR-13649) BasicAuth's 'blockUnknown' param should default to true
[
https://issues.apache.org/jira/browse/SOLR-13649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shalin Shekhar Mangar resolved SOLR-13649.
--
Resolution: Fixed
Thanks Marcus and Jan for all the work!
> BasicAuth's 'blockUnknown' param should default to true
> ---
>
> Key: SOLR-13649
> URL: https://issues.apache.org/jira/browse/SOLR-13649
> Project: Solr
> Issue Type: Improvement
> Components: Admin UI, Authentication, security
>Affects Versions: 7.7.2, 8.1.1
> Environment: All
>Reporter: Marcus Eagan
> Assignee: Shalin Shekhar Mangar
>Priority: Major
> Labels: Authentication
> Fix For: master (9.0)
>
> Time Spent: 9h 10m
> Remaining Estimate: 0h
>
> If someone seeks to enable basic authentication but they do not specify the
> {{blockUnknown}} parameter, the default value is {{false}}. That default
> behavior is a bit counterintuitive because if someone wishes to enable basic
> authentication, you would expect that they would want all unknown users to
> need to authenticate by default. I can imagine cases where you would not, but
> those cases would be less frequent.
--
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-13712) JMX MBeans are not exposed because of race condition between creating platform mbean server and registering mbeans
[
https://issues.apache.org/jira/browse/SOLR-13712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16915477#comment-16915477
]
Shalin Shekhar Mangar commented on SOLR-13712:
--
bq. It sounds like a workaround may be to configure log4j2 to register it's
mbeans earlier.
Yes, that should workaround this bug. I'll be interested to know what you find.
Thanks!
> JMX MBeans are not exposed because of race condition between creating
> platform mbean server and registering mbeans
> --
>
> Key: SOLR-13712
> URL: https://issues.apache.org/jira/browse/SOLR-13712
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: JMX
>Affects Versions: 6.6, 6.6.2, 6.6.5, 7.7.2, 8.2, 8.1.1
> Reporter: Shalin Shekhar Mangar
>Priority: Major
> Attachments: SOLR-13712.patch
>
>
> This is quite easy to reproduce.
> {code}
> wget https://archive.apache.org/dist/lucene/solr/6.6.0/solr-6.6.0.tgz
> tar xvf solr-6.6.0.tgz
> cd solr-6.6.0
> {code}
> Enable jmx reporting by editing the server/solr/solr.xml and adding the
> following under the "" tag:
> {code}
>
> class="org.apache.solr.metrics.reporters.SolrJmxReporter" />
>
> {code}
> Start solr with:
> {code}
> ./bin/solr start -e cloud -noprompt
> {code}
> Open jconsole and inspect mbeans for solr nodes running on port 8983 and
> 7574. You'll find that all mbeans (node, jvm, jetty, solr) are present for
> the solr on port 8983 but completely absent for the solr node running on port
> 7574.
> Same behavior is on 6.6.2 and 6.6.6. However, Solr 7.x and 8.x seem to be
> fine.
--
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-13712) JMX MBeans are not exposed because of race condition between creating platform mbean server and registering mbeans
[
https://issues.apache.org/jira/browse/SOLR-13712?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shalin Shekhar Mangar updated SOLR-13712:
-
Status: Patch Available (was: Open)
> JMX MBeans are not exposed because of race condition between creating
> platform mbean server and registering mbeans
> --
>
> Key: SOLR-13712
> URL: https://issues.apache.org/jira/browse/SOLR-13712
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: JMX
>Affects Versions: 6.6, 6.6.2, 6.6.5, 7.7.2, 8.2, 8.1.1
> Reporter: Shalin Shekhar Mangar
>Priority: Major
> Attachments: SOLR-13712.patch
>
>
> This is quite easy to reproduce.
> {code}
> wget https://archive.apache.org/dist/lucene/solr/6.6.0/solr-6.6.0.tgz
> tar xvf solr-6.6.0.tgz
> cd solr-6.6.0
> {code}
> Enable jmx reporting by editing the server/solr/solr.xml and adding the
> following under the "" tag:
> {code}
>
> class="org.apache.solr.metrics.reporters.SolrJmxReporter" />
>
> {code}
> Start solr with:
> {code}
> ./bin/solr start -e cloud -noprompt
> {code}
> Open jconsole and inspect mbeans for solr nodes running on port 8983 and
> 7574. You'll find that all mbeans (node, jvm, jetty, solr) are present for
> the solr on port 8983 but completely absent for the solr node running on port
> 7574.
> Same behavior is on 6.6.2 and 6.6.6. However, Solr 7.x and 8.x seem to be
> fine.
--
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-13712) JMX MBeans are not exposed because of race condition between creating platform mbean server and registering mbeans
[
https://issues.apache.org/jira/browse/SOLR-13712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16915126#comment-16915126
]
Shalin Shekhar Mangar commented on SOLR-13712:
--
Patch for master which returns {{ManagementFactory.getPlatformMBeanServer()}}
inside JmxUtils.findFirstMBeanServer() if no mbean servers exist.
> JMX MBeans are not exposed because of race condition between creating
> platform mbean server and registering mbeans
> --
>
> Key: SOLR-13712
> URL: https://issues.apache.org/jira/browse/SOLR-13712
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: JMX
>Affects Versions: 6.6, 6.6.2, 6.6.5, 7.7.2, 8.2, 8.1.1
> Reporter: Shalin Shekhar Mangar
>Priority: Major
> Attachments: SOLR-13712.patch
>
>
> This is quite easy to reproduce.
> {code}
> wget https://archive.apache.org/dist/lucene/solr/6.6.0/solr-6.6.0.tgz
> tar xvf solr-6.6.0.tgz
> cd solr-6.6.0
> {code}
> Enable jmx reporting by editing the server/solr/solr.xml and adding the
> following under the "" tag:
> {code}
>
> class="org.apache.solr.metrics.reporters.SolrJmxReporter" />
>
> {code}
> Start solr with:
> {code}
> ./bin/solr start -e cloud -noprompt
> {code}
> Open jconsole and inspect mbeans for solr nodes running on port 8983 and
> 7574. You'll find that all mbeans (node, jvm, jetty, solr) are present for
> the solr on port 8983 but completely absent for the solr node running on port
> 7574.
> Same behavior is on 6.6.2 and 6.6.6. However, Solr 7.x and 8.x seem to be
> fine.
--
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-13712) JMX MBeans are not exposed because of race condition between creating platform mbean server and registering mbeans
[
https://issues.apache.org/jira/browse/SOLR-13712?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shalin Shekhar Mangar updated SOLR-13712:
-
Attachment: SOLR-13712.patch
> JMX MBeans are not exposed because of race condition between creating
> platform mbean server and registering mbeans
> --
>
> Key: SOLR-13712
> URL: https://issues.apache.org/jira/browse/SOLR-13712
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: JMX
>Affects Versions: 6.6, 6.6.2, 6.6.5, 7.7.2, 8.2, 8.1.1
> Reporter: Shalin Shekhar Mangar
>Priority: Major
> Attachments: SOLR-13712.patch
>
>
> This is quite easy to reproduce.
> {code}
> wget https://archive.apache.org/dist/lucene/solr/6.6.0/solr-6.6.0.tgz
> tar xvf solr-6.6.0.tgz
> cd solr-6.6.0
> {code}
> Enable jmx reporting by editing the server/solr/solr.xml and adding the
> following under the "" tag:
> {code}
>
> class="org.apache.solr.metrics.reporters.SolrJmxReporter" />
>
> {code}
> Start solr with:
> {code}
> ./bin/solr start -e cloud -noprompt
> {code}
> Open jconsole and inspect mbeans for solr nodes running on port 8983 and
> 7574. You'll find that all mbeans (node, jvm, jetty, solr) are present for
> the solr on port 8983 but completely absent for the solr node running on port
> 7574.
> Same behavior is on 6.6.2 and 6.6.6. However, Solr 7.x and 8.x seem to be
> fine.
--
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] [Assigned] (SOLR-13649) BasicAuth's 'blockUnknown' param should default to true
[
https://issues.apache.org/jira/browse/SOLR-13649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shalin Shekhar Mangar reassigned SOLR-13649:
Assignee: Shalin Shekhar Mangar
> BasicAuth's 'blockUnknown' param should default to true
> ---
>
> Key: SOLR-13649
> URL: https://issues.apache.org/jira/browse/SOLR-13649
> Project: Solr
> Issue Type: Improvement
> Components: Admin UI, Authentication, security
>Affects Versions: 7.7.2, 8.1.1
> Environment: All
>Reporter: Marcus Eagan
> Assignee: Shalin Shekhar Mangar
>Priority: Major
> Labels: Authentication
> Fix For: master (9.0)
>
> Time Spent: 4h 10m
> Remaining Estimate: 0h
>
> If someone seeks to enable basic authentication but they do not specify the
> {{blockUnknown}} parameter, the default value is {{false}}. That default
> behavior is a bit counterintuitive because if someone wishes to enable basic
> authentication, you would expect that they would want all unknown users to
> need to authenticate by default. I can imagine cases where you would not, but
> those cases would be less frequent.
--
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-13712) JMX MBeans are not exposed because of race condition between creating platform mbean server and registering mbeans
[
https://issues.apache.org/jira/browse/SOLR-13712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16913947#comment-16913947
]
Shalin Shekhar Mangar commented on SOLR-13712:
--
I tracked down the problem to SolrJmxReporter.
In the absence of any agentId or serviceUrl, the platform mbean server is
supposed to be used. The SolrJmxReporter.init (or doInit() method in later
versions) first tries to get the first mbean server and registers mbeans to it.
However, it exits early if no mbean server is found. Attaching a debugger to
the solr processes I found that the platform mbean server is always found for
the solr node running on port 8983 but not for solr on port 7574.
The problem is that the platform mbean server is created on the first
invocation of {{ManagementFactory.getPlatformMBeanServer()}} and
SolrJmxReporter calls this method in JmxMetricsReporter.build() which happens
after the mbean server is looked up. If no mbean server is found then the call
to build() never happens and therefore no mbeans are registered with the mbean
server.
So why does the mbean server exist on 8983? It is because of the embedded
zookeeper which calls {{ManagementFactory.getPlatformMBeanServer()}} before
solr tries to initialize SolrJmxReporter.
The code is virtually unchanged in Solr 7.x and 8.x. Then why do those versions
seem fine? It is because of log4j2 which registers its mbeans with the platform
mbean server before Solr initializes.
> JMX MBeans are not exposed because of race condition between creating
> platform mbean server and registering mbeans
> --
>
> Key: SOLR-13712
> URL: https://issues.apache.org/jira/browse/SOLR-13712
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: JMX
>Affects Versions: 6.6, 6.6.2, 6.6.5, 7.7.2, 8.2, 8.1.1
> Reporter: Shalin Shekhar Mangar
>Priority: Major
>
> This is quite easy to reproduce.
> {code}
> wget https://archive.apache.org/dist/lucene/solr/6.6.0/solr-6.6.0.tgz
> tar xvf solr-6.6.0.tgz
> cd solr-6.6.0
> {code}
> Enable jmx reporting by editing the server/solr/solr.xml and adding the
> following under the "" tag:
> {code}
>
> class="org.apache.solr.metrics.reporters.SolrJmxReporter" />
>
> {code}
> Start solr with:
> {code}
> ./bin/solr start -e cloud -noprompt
> {code}
> Open jconsole and inspect mbeans for solr nodes running on port 8983 and
> 7574. You'll find that all mbeans (node, jvm, jetty, solr) are present for
> the solr on port 8983 but completely absent for the solr node running on port
> 7574.
> Same behavior is on 6.6.2 and 6.6.6. However, Solr 7.x and 8.x seem to be
> fine.
--
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-13712) JMX MBeans are not exposed because of race condition between creating platform mbean server and registering mbeans
[
https://issues.apache.org/jira/browse/SOLR-13712?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shalin Shekhar Mangar updated SOLR-13712:
-
Description:
This is quite easy to reproduce.
{code}
wget https://archive.apache.org/dist/lucene/solr/6.6.0/solr-6.6.0.tgz
tar xvf solr-6.6.0.tgz
cd solr-6.6.0
{code}
Enable jmx reporting by editing the server/solr/solr.xml and adding the
following under the "" tag:
{code}
{code}
Start solr with:
{code}
./bin/solr start -e cloud -noprompt
{code}
Open jconsole and inspect mbeans for solr nodes running on port 8983 and 7574.
You'll find that all mbeans (node, jvm, jetty, solr) are present for the solr
on port 8983 but completely absent for the solr node running on port 7574.
Same behavior is on 6.6.2 and 6.6.6. However, Solr 7.x and 8.x seem to be fine.
was:Details to follow.
> JMX MBeans are not exposed because of race condition between creating
> platform mbean server and registering mbeans
> --
>
> Key: SOLR-13712
> URL: https://issues.apache.org/jira/browse/SOLR-13712
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: JMX
>Affects Versions: 6.6, 6.6.2, 6.6.5, 7.7.2, 8.2, 8.1.1
>Reporter: Shalin Shekhar Mangar
>Priority: Major
>
> This is quite easy to reproduce.
> {code}
> wget https://archive.apache.org/dist/lucene/solr/6.6.0/solr-6.6.0.tgz
> tar xvf solr-6.6.0.tgz
> cd solr-6.6.0
> {code}
> Enable jmx reporting by editing the server/solr/solr.xml and adding the
> following under the "" tag:
> {code}
>
> class="org.apache.solr.metrics.reporters.SolrJmxReporter" />
>
> {code}
> Start solr with:
> {code}
> ./bin/solr start -e cloud -noprompt
> {code}
> Open jconsole and inspect mbeans for solr nodes running on port 8983 and
> 7574. You'll find that all mbeans (node, jvm, jetty, solr) are present for
> the solr on port 8983 but completely absent for the solr node running on port
> 7574.
> Same behavior is on 6.6.2 and 6.6.6. However, Solr 7.x and 8.x seem to be
> fine.
--
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-13712) JMX MBeans are not exposed because of race condition between creating platform mbean server and registering mbeans
Shalin Shekhar Mangar created SOLR-13712: Summary: JMX MBeans are not exposed because of race condition between creating platform mbean server and registering mbeans Key: SOLR-13712 URL: https://issues.apache.org/jira/browse/SOLR-13712 Project: Solr Issue Type: Bug Security Level: Public (Default Security Level. Issues are Public) Components: JMX Affects Versions: 8.1.1, 8.2, 7.7.2, 6.6.5, 6.6.2, 6.6 Reporter: Shalin Shekhar Mangar Details to follow. -- 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-13683) SolrJ 8.1.1 Http2SolrClient should allow customizing HTTP headers
[
https://issues.apache.org/jira/browse/SOLR-13683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16907760#comment-16907760
]
Shalin Shekhar Mangar commented on SOLR-13683:
--
bq. Our use case is indexing documents to Solr; hence, we do not use
SolrRequest APIs. We use SolrClient.add(collectionName,
Collection) API. Do you have any document which shows how to
use SolrRequest API for indexing use cases?
You can use UpdateRequest class which has an add method that accepts a
Collection instead of calling add on CloudHttp2SolrClient
directly.
> SolrJ 8.1.1 Http2SolrClient should allow customizing HTTP headers
> -
>
> Key: SOLR-13683
> URL: https://issues.apache.org/jira/browse/SOLR-13683
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: clients - java
>Affects Versions: 8.1.1
>Reporter: Niranjan Nanda
>Priority: Minor
>
> Currently {{Http2SolrClient}} does not allow configuring custom headers. For
> example, how to pass Basic Auth headers? It should expose some builder APIs
> to pass such headers.
--
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] [Created] (SOLR-13685) Update the leader term in ZK on the condition that the replica is still the leader
Shalin Shekhar Mangar created SOLR-13685: Summary: Update the leader term in ZK on the condition that the replica is still the leader Key: SOLR-13685 URL: https://issues.apache.org/jira/browse/SOLR-13685 Project: Solr Issue Type: Improvement Security Level: Public (Default Security Level. Issues are Public) Components: SolrCloud Reporter: Shalin Shekhar Mangar Fix For: master (9.0), 8.3 While working on SOLR-13141, I realized that the ZkShardTerms.ensureTermIsHigher and related methods do a compare-and-set on the terms but there is no guarantee that the leader is still the leader when the zk update executes. This can potentially lead to race conditions during leader transitions. We should update the term using a zk multi-op conditional on the current replica still being the leader. This will not change any behavior but will only be an additional safety check. -- 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-11724) Cdcr Bootstrapping does not cause "index copying" to follower nodes on Target
[ https://issues.apache.org/jira/browse/SOLR-11724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shalin Shekhar Mangar updated SOLR-11724: - Fix Version/s: (was: 8.0) Status: Resolved (was: Patch Available) This is fixed by SOLR-13141 > Cdcr Bootstrapping does not cause "index copying" to follower nodes on Target > - > > Key: SOLR-11724 > URL: https://issues.apache.org/jira/browse/SOLR-11724 > Project: Solr > Issue Type: Bug > Components: CDCR >Reporter: Amrit Sarkar >Assignee: Varun Thacker >Priority: Major > Fix For: 7.4, 7.3.1 > > Attachments: SOLR-11724.patch, SOLR-11724.patch, SOLR-11724.patch, > SOLR-11724.patch, SOLR-11724.patch > > Time Spent: 10m > Remaining Estimate: 0h > > Please find the discussion on: > http://lucene.472066.n3.nabble.com/Issue-with-CDCR-bootstrapping-in-Solr-7-1-td4365258.html > If we index significant documents in to Source, stop indexing and then start > CDCR; bootstrapping only copies the index to leader node of shards of the > collection, and followers never receive the documents / index until and > unless atleast one document is inserted again on source; which propels to > target and target collection trigger index replication to followers. > This behavior needs to be addressed in proper manner, either at target > collection or while bootstrapping. -- 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] [Resolved] (SOLR-13141) CDCR bootstrap does not replicate index to the replicas of target cluster
[
https://issues.apache.org/jira/browse/SOLR-13141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shalin Shekhar Mangar resolved SOLR-13141.
--
Resolution: Fixed
Thanks to everyone who reported and investigated this problem.
> CDCR bootstrap does not replicate index to the replicas of target cluster
> -
>
> Key: SOLR-13141
> URL: https://issues.apache.org/jira/browse/SOLR-13141
> Project: Solr
> Issue Type: Bug
> Components: CDCR
>Affects Versions: 7.5, 7.6
> Environment: This is system independent problem - exists on windows
> and linux - reproduced by independent developers
>Reporter: Krzysztof Watral
>Assignee: Shalin Shekhar Mangar
>Priority: Critical
> Fix For: master (9.0), 8.3
>
> Attachments: SOLR-13141.patch, SOLR-13141.patch, type 1 - replication
> wasnt working at all.txt, type 2 - only few documents were being
> replicated.txt
>
>
> i have encountered some problems with CDCR that are related to the value of
> {{replicationFactor}} param.
> I ran the solr cloud on two datacenters with 2 nodes on each:
> * dca:
> ** dca_node_1
> ** dca_node_2
> * dcb
> ** dcb_node_1
> ** dcb_node_2
> Then in sequence:
> * I configured the CDCR on copy of *_default* config set named
> *_default_cdcr*
> * I created collection "customer" on both DC from *_default_cdcr* config set
> with the following parameters:
> ** {{numShards}} = 2
> ** {{maxShardsPerNode}} = 2
> ** {{replicationFactor}} = 2
> * I disabled cdcr buffer on collections
> * I ran CDCR on both DC
> CDCR has started without errors in logs. During indexation I have encountered
> problem [^type 2 - only few documents were being replicated.txt], restart
> didn't help (documents has not been synchronized between DC )
> Then:
> * I stopped CDCR on both DC
> * I stopped all solr nodes
> * I restarted zookeepers on both DC
> * I started all solr nodes one by one
> * few minutes later I stared CDCR on both DC
> * CDCR has starded with errors (replication between DC is not working) -
> [^type 1 - replication wasnt working at all.txt]
> {panel}
> I've also discovered that problems appears only in case, when the
> {{replicationFactor}} parameter is higher than one
> {panel}
--
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-13141) CDCR bootstrap does not replicate index to the replicas of target cluster
[
https://issues.apache.org/jira/browse/SOLR-13141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16903512#comment-16903512
]
Shalin Shekhar Mangar commented on SOLR-13141:
--
Latest patch that increments the term only if the bootstrap was successful.
> CDCR bootstrap does not replicate index to the replicas of target cluster
> -
>
> Key: SOLR-13141
> URL: https://issues.apache.org/jira/browse/SOLR-13141
> Project: Solr
> Issue Type: Bug
> Components: CDCR
>Affects Versions: 7.5, 7.6
> Environment: This is system independent problem - exists on windows
> and linux - reproduced by independent developers
>Reporter: Krzysztof Watral
>Assignee: Shalin Shekhar Mangar
>Priority: Critical
> Fix For: master (9.0), 8.3
>
> Attachments: SOLR-13141.patch, SOLR-13141.patch, type 1 - replication
> wasnt working at all.txt, type 2 - only few documents were being
> replicated.txt
>
>
> i have encountered some problems with CDCR that are related to the value of
> {{replicationFactor}} param.
> I ran the solr cloud on two datacenters with 2 nodes on each:
> * dca:
> ** dca_node_1
> ** dca_node_2
> * dcb
> ** dcb_node_1
> ** dcb_node_2
> Then in sequence:
> * I configured the CDCR on copy of *_default* config set named
> *_default_cdcr*
> * I created collection "customer" on both DC from *_default_cdcr* config set
> with the following parameters:
> ** {{numShards}} = 2
> ** {{maxShardsPerNode}} = 2
> ** {{replicationFactor}} = 2
> * I disabled cdcr buffer on collections
> * I ran CDCR on both DC
> CDCR has started without errors in logs. During indexation I have encountered
> problem [^type 2 - only few documents were being replicated.txt], restart
> didn't help (documents has not been synchronized between DC )
> Then:
> * I stopped CDCR on both DC
> * I stopped all solr nodes
> * I restarted zookeepers on both DC
> * I started all solr nodes one by one
> * few minutes later I stared CDCR on both DC
> * CDCR has starded with errors (replication between DC is not working) -
> [^type 1 - replication wasnt working at all.txt]
> {panel}
> I've also discovered that problems appears only in case, when the
> {{replicationFactor}} parameter is higher than one
> {panel}
--
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-13141) CDCR bootstrap does not replicate index to the replicas of target cluster
[
https://issues.apache.org/jira/browse/SOLR-13141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shalin Shekhar Mangar updated SOLR-13141:
-
Attachment: SOLR-13141.patch
> CDCR bootstrap does not replicate index to the replicas of target cluster
> -
>
> Key: SOLR-13141
> URL: https://issues.apache.org/jira/browse/SOLR-13141
> Project: Solr
> Issue Type: Bug
> Components: CDCR
>Affects Versions: 7.5, 7.6
> Environment: This is system independent problem - exists on windows
> and linux - reproduced by independent developers
>Reporter: Krzysztof Watral
>Assignee: Shalin Shekhar Mangar
>Priority: Critical
> Fix For: master (9.0), 8.3
>
> Attachments: SOLR-13141.patch, SOLR-13141.patch, type 1 - replication
> wasnt working at all.txt, type 2 - only few documents were being
> replicated.txt
>
>
> i have encountered some problems with CDCR that are related to the value of
> {{replicationFactor}} param.
> I ran the solr cloud on two datacenters with 2 nodes on each:
> * dca:
> ** dca_node_1
> ** dca_node_2
> * dcb
> ** dcb_node_1
> ** dcb_node_2
> Then in sequence:
> * I configured the CDCR on copy of *_default* config set named
> *_default_cdcr*
> * I created collection "customer" on both DC from *_default_cdcr* config set
> with the following parameters:
> ** {{numShards}} = 2
> ** {{maxShardsPerNode}} = 2
> ** {{replicationFactor}} = 2
> * I disabled cdcr buffer on collections
> * I ran CDCR on both DC
> CDCR has started without errors in logs. During indexation I have encountered
> problem [^type 2 - only few documents were being replicated.txt], restart
> didn't help (documents has not been synchronized between DC )
> Then:
> * I stopped CDCR on both DC
> * I stopped all solr nodes
> * I restarted zookeepers on both DC
> * I started all solr nodes one by one
> * few minutes later I stared CDCR on both DC
> * CDCR has starded with errors (replication between DC is not working) -
> [^type 1 - replication wasnt working at all.txt]
> {panel}
> I've also discovered that problems appears only in case, when the
> {{replicationFactor}} parameter is higher than one
> {panel}
--
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-13141) CDCR bootstrap does not replicate index to the replicas of target cluster
[
https://issues.apache.org/jira/browse/SOLR-13141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shalin Shekhar Mangar updated SOLR-13141:
-
Fix Version/s: 8.3
master (9.0)
> CDCR bootstrap does not replicate index to the replicas of target cluster
> -
>
> Key: SOLR-13141
> URL: https://issues.apache.org/jira/browse/SOLR-13141
> Project: Solr
> Issue Type: Bug
> Components: CDCR
>Affects Versions: 7.5, 7.6
> Environment: This is system independent problem - exists on windows
> and linux - reproduced by independent developers
>Reporter: Krzysztof Watral
>Assignee: Shalin Shekhar Mangar
>Priority: Critical
> Fix For: master (9.0), 8.3
>
> Attachments: SOLR-13141.patch, type 1 - replication wasnt working at
> all.txt, type 2 - only few documents were being replicated.txt
>
>
> i have encountered some problems with CDCR that are related to the value of
> {{replicationFactor}} param.
> I ran the solr cloud on two datacenters with 2 nodes on each:
> * dca:
> ** dca_node_1
> ** dca_node_2
> * dcb
> ** dcb_node_1
> ** dcb_node_2
> Then in sequence:
> * I configured the CDCR on copy of *_default* config set named
> *_default_cdcr*
> * I created collection "customer" on both DC from *_default_cdcr* config set
> with the following parameters:
> ** {{numShards}} = 2
> ** {{maxShardsPerNode}} = 2
> ** {{replicationFactor}} = 2
> * I disabled cdcr buffer on collections
> * I ran CDCR on both DC
> CDCR has started without errors in logs. During indexation I have encountered
> problem [^type 2 - only few documents were being replicated.txt], restart
> didn't help (documents has not been synchronized between DC )
> Then:
> * I stopped CDCR on both DC
> * I stopped all solr nodes
> * I restarted zookeepers on both DC
> * I started all solr nodes one by one
> * few minutes later I stared CDCR on both DC
> * CDCR has starded with errors (replication between DC is not working) -
> [^type 1 - replication wasnt working at all.txt]
> {panel}
> I've also discovered that problems appears only in case, when the
> {{replicationFactor}} parameter is higher than one
> {panel}
--
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-13141) CDCR bootstrap does not replicate index to the replicas of target cluster
[
https://issues.apache.org/jira/browse/SOLR-13141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shalin Shekhar Mangar reassigned SOLR-13141:
Assignee: Shalin Shekhar Mangar
> CDCR bootstrap does not replicate index to the replicas of target cluster
> -
>
> Key: SOLR-13141
> URL: https://issues.apache.org/jira/browse/SOLR-13141
> Project: Solr
> Issue Type: Bug
> Components: CDCR
>Affects Versions: 7.5, 7.6
> Environment: This is system independent problem - exists on windows
> and linux - reproduced by independent developers
>Reporter: Krzysztof Watral
>Assignee: Shalin Shekhar Mangar
>Priority: Critical
> Attachments: SOLR-13141.patch, type 1 - replication wasnt working at
> all.txt, type 2 - only few documents were being replicated.txt
>
>
> i have encountered some problems with CDCR that are related to the value of
> {{replicationFactor}} param.
> I ran the solr cloud on two datacenters with 2 nodes on each:
> * dca:
> ** dca_node_1
> ** dca_node_2
> * dcb
> ** dcb_node_1
> ** dcb_node_2
> Then in sequence:
> * I configured the CDCR on copy of *_default* config set named
> *_default_cdcr*
> * I created collection "customer" on both DC from *_default_cdcr* config set
> with the following parameters:
> ** {{numShards}} = 2
> ** {{maxShardsPerNode}} = 2
> ** {{replicationFactor}} = 2
> * I disabled cdcr buffer on collections
> * I ran CDCR on both DC
> CDCR has started without errors in logs. During indexation I have encountered
> problem [^type 2 - only few documents were being replicated.txt], restart
> didn't help (documents has not been synchronized between DC )
> Then:
> * I stopped CDCR on both DC
> * I stopped all solr nodes
> * I restarted zookeepers on both DC
> * I started all solr nodes one by one
> * few minutes later I stared CDCR on both DC
> * CDCR has starded with errors (replication between DC is not working) -
> [^type 1 - replication wasnt working at all.txt]
> {panel}
> I've also discovered that problems appears only in case, when the
> {{replicationFactor}} parameter is higher than one
> {panel}
--
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-13141) CDCR bootstrap does not replicate index to the replicas of target cluster
[
https://issues.apache.org/jira/browse/SOLR-13141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shalin Shekhar Mangar updated SOLR-13141:
-
Summary: CDCR bootstrap does not replicate index to the replicas of target
cluster (was: replicationFactor param cause problems with CDCR)
> CDCR bootstrap does not replicate index to the replicas of target cluster
> -
>
> Key: SOLR-13141
> URL: https://issues.apache.org/jira/browse/SOLR-13141
> Project: Solr
> Issue Type: Bug
> Components: CDCR
>Affects Versions: 7.5, 7.6
> Environment: This is system independent problem - exists on windows
> and linux - reproduced by independent developers
>Reporter: Krzysztof Watral
>Priority: Critical
> Attachments: SOLR-13141.patch, type 1 - replication wasnt working at
> all.txt, type 2 - only few documents were being replicated.txt
>
>
> i have encountered some problems with CDCR that are related to the value of
> {{replicationFactor}} param.
> I ran the solr cloud on two datacenters with 2 nodes on each:
> * dca:
> ** dca_node_1
> ** dca_node_2
> * dcb
> ** dcb_node_1
> ** dcb_node_2
> Then in sequence:
> * I configured the CDCR on copy of *_default* config set named
> *_default_cdcr*
> * I created collection "customer" on both DC from *_default_cdcr* config set
> with the following parameters:
> ** {{numShards}} = 2
> ** {{maxShardsPerNode}} = 2
> ** {{replicationFactor}} = 2
> * I disabled cdcr buffer on collections
> * I ran CDCR on both DC
> CDCR has started without errors in logs. During indexation I have encountered
> problem [^type 2 - only few documents were being replicated.txt], restart
> didn't help (documents has not been synchronized between DC )
> Then:
> * I stopped CDCR on both DC
> * I stopped all solr nodes
> * I restarted zookeepers on both DC
> * I started all solr nodes one by one
> * few minutes later I stared CDCR on both DC
> * CDCR has starded with errors (replication between DC is not working) -
> [^type 1 - replication wasnt working at all.txt]
> {panel}
> I've also discovered that problems appears only in case, when the
> {{replicationFactor}} parameter is higher than one
> {panel}
--
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-13683) SolrJ 8.1.1 Http2SolrClient should allow customizing HTTP headers
[
https://issues.apache.org/jira/browse/SOLR-13683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16902887#comment-16902887
]
Shalin Shekhar Mangar commented on SOLR-13683:
--
bq. What is the purpose of this method?
Http2SolrClient.Builder().withHttpClient(Http2SolrClient httpClient)? Ideally
this should allow setting Jetty's HttpClient object instead of an instance of
its own type.
This certainly seems like a mistake. It should just directly accept Jetty's
HttpClient instead of {{httpClient = builder.http2SolrClient.httpClient;}} that
it does today in the constructor.
bq. Currently Http2SolrClient does not allow configuring custom headers. For
example, how to pass Basic Auth headers? It should expose some builder APIs to
pass such headers.
Actually none of solrj clients allow custom headers directly but you can use
Apache HttpClient's RequestInterceptors to add custom headers on all requests.
But if you just want to use basic auth then you can use
SolrRequest.setBasicAuthCredentials() method to add the user and password.
These will be base64 encoded and passed to the Authorization header
automatically by Http2SolrClient.
> SolrJ 8.1.1 Http2SolrClient should allow customizing HTTP headers
> -
>
> Key: SOLR-13683
> URL: https://issues.apache.org/jira/browse/SOLR-13683
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: clients - java
>Affects Versions: 8.1.1
>Reporter: Niranjan Nanda
>Priority: Minor
>
> Currently {{Http2SolrClient}} does not allow configuring custom headers. For
> example, how to pass Basic Auth headers? It should expose some builder APIs
> to pass such headers.
--
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-13141) replicationFactor param cause problems with CDCR
[
https://issues.apache.org/jira/browse/SOLR-13141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16902877#comment-16902877
]
Shalin Shekhar Mangar commented on SOLR-13141:
--
Attached patch (originally at SOLR-11724).
A less brittle way than what was proposed for SOLR-11724 would be to update the
term for the leader once bootstrap finishes. This way the replicas will
automatically go to recovery. This latest patch implements this idea.
> replicationFactor param cause problems with CDCR
>
>
> Key: SOLR-13141
> URL: https://issues.apache.org/jira/browse/SOLR-13141
> Project: Solr
> Issue Type: Bug
> Components: CDCR
>Affects Versions: 7.5, 7.6
> Environment: This is system independent problem - exists on windows
> and linux - reproduced by independent developers
>Reporter: Krzysztof Watral
>Priority: Critical
> Attachments: SOLR-13141.patch, type 1 - replication wasnt working at
> all.txt, type 2 - only few documents were being replicated.txt
>
>
> i have encountered some problems with CDCR that are related to the value of
> {{replicationFactor}} param.
> I ran the solr cloud on two datacenters with 2 nodes on each:
> * dca:
> ** dca_node_1
> ** dca_node_2
> * dcb
> ** dcb_node_1
> ** dcb_node_2
> Then in sequence:
> * I configured the CDCR on copy of *_default* config set named
> *_default_cdcr*
> * I created collection "customer" on both DC from *_default_cdcr* config set
> with the following parameters:
> ** {{numShards}} = 2
> ** {{maxShardsPerNode}} = 2
> ** {{replicationFactor}} = 2
> * I disabled cdcr buffer on collections
> * I ran CDCR on both DC
> CDCR has started without errors in logs. During indexation I have encountered
> problem [^type 2 - only few documents were being replicated.txt], restart
> didn't help (documents has not been synchronized between DC )
> Then:
> * I stopped CDCR on both DC
> * I stopped all solr nodes
> * I restarted zookeepers on both DC
> * I started all solr nodes one by one
> * few minutes later I stared CDCR on both DC
> * CDCR has starded with errors (replication between DC is not working) -
> [^type 1 - replication wasnt working at all.txt]
> {panel}
> I've also discovered that problems appears only in case, when the
> {{replicationFactor}} parameter is higher than one
> {panel}
--
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-13141) replicationFactor param cause problems with CDCR
[
https://issues.apache.org/jira/browse/SOLR-13141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shalin Shekhar Mangar updated SOLR-13141:
-
Attachment: SOLR-13141.patch
> replicationFactor param cause problems with CDCR
>
>
> Key: SOLR-13141
> URL: https://issues.apache.org/jira/browse/SOLR-13141
> Project: Solr
> Issue Type: Bug
> Components: CDCR
>Affects Versions: 7.5, 7.6
> Environment: This is system independent problem - exists on windows
> and linux - reproduced by independent developers
>Reporter: Krzysztof Watral
>Priority: Critical
> Attachments: SOLR-13141.patch, type 1 - replication wasnt working at
> all.txt, type 2 - only few documents were being replicated.txt
>
>
> i have encountered some problems with CDCR that are related to the value of
> {{replicationFactor}} param.
> I ran the solr cloud on two datacenters with 2 nodes on each:
> * dca:
> ** dca_node_1
> ** dca_node_2
> * dcb
> ** dcb_node_1
> ** dcb_node_2
> Then in sequence:
> * I configured the CDCR on copy of *_default* config set named
> *_default_cdcr*
> * I created collection "customer" on both DC from *_default_cdcr* config set
> with the following parameters:
> ** {{numShards}} = 2
> ** {{maxShardsPerNode}} = 2
> ** {{replicationFactor}} = 2
> * I disabled cdcr buffer on collections
> * I ran CDCR on both DC
> CDCR has started without errors in logs. During indexation I have encountered
> problem [^type 2 - only few documents were being replicated.txt], restart
> didn't help (documents has not been synchronized between DC )
> Then:
> * I stopped CDCR on both DC
> * I stopped all solr nodes
> * I restarted zookeepers on both DC
> * I started all solr nodes one by one
> * few minutes later I stared CDCR on both DC
> * CDCR has starded with errors (replication between DC is not working) -
> [^type 1 - replication wasnt working at all.txt]
> {panel}
> I've also discovered that problems appears only in case, when the
> {{replicationFactor}} parameter is higher than one
> {panel}
--
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-11724) Cdcr Bootstrapping does not cause "index copying" to follower nodes on Target
[ https://issues.apache.org/jira/browse/SOLR-11724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16902876#comment-16902876 ] Shalin Shekhar Mangar commented on SOLR-11724: -- I just noticed the linked issue SOLR-13141 so we can use that and let this be as it is today. > Cdcr Bootstrapping does not cause "index copying" to follower nodes on Target > - > > Key: SOLR-11724 > URL: https://issues.apache.org/jira/browse/SOLR-11724 > Project: Solr > Issue Type: Bug > Components: CDCR >Reporter: Amrit Sarkar >Assignee: Varun Thacker >Priority: Major > Fix For: 7.3.1, 7.4, 8.0 > > Attachments: SOLR-11724.patch, SOLR-11724.patch, SOLR-11724.patch, > SOLR-11724.patch, SOLR-11724.patch > > Time Spent: 10m > Remaining Estimate: 0h > > Please find the discussion on: > http://lucene.472066.n3.nabble.com/Issue-with-CDCR-bootstrapping-in-Solr-7-1-td4365258.html > If we index significant documents in to Source, stop indexing and then start > CDCR; bootstrapping only copies the index to leader node of shards of the > collection, and followers never receive the documents / index until and > unless atleast one document is inserted again on source; which propels to > target and target collection trigger index replication to followers. > This behavior needs to be addressed in proper manner, either at target > collection or while bootstrapping. -- 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-13674) NodeAddedTrigger does not support configuration of replica type hint
[ https://issues.apache.org/jira/browse/SOLR-13674?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16902874#comment-16902874 ] Shalin Shekhar Mangar commented on SOLR-13674: -- The 7x branch has been made protected to reject any commits. See https://issues.apache.org/jira/browse/INFRA-18192. This is due to back-compat issues that make it almost impossible to release a new minor version from the 7x branch. This change can be back-ported to branch_7_7 (and to branch_8_2) in case a new bug fix release (7.7.3 or 8.2.1) is required but none of them are in plans today. Would it be okay if you cherry-picked the commit to 7x on your private repos instead? > NodeAddedTrigger does not support configuration of replica type hint > > > Key: SOLR-13674 > URL: https://issues.apache.org/jira/browse/SOLR-13674 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: AutoScaling >Affects Versions: 7.6 >Reporter: Irena Shaigorodsky > Assignee: Shalin Shekhar Mangar >Priority: Major > Fix For: master (9.0), 8.3 > > Time Spent: 20m > Remaining Estimate: 0h > > The current code > org.apache.solr.cloud.autoscaling.ComputePlanAction#getNodeAddedSuggester > only sets COLL_SHARD hint, as a result any added replica will be NRT one. > Our current setup has TLOG nodes on physical hardware and PULL nodes on k8s > that are recycled periodically. An attempt to add those will bring the nodes > in the cluster as NRT one. > The root cause is > org.apache.solr.client.solrj.cloud.autoscaling.AddReplicaSuggester#tryEachNode > that expects to find the hint REPLICATYPE and defaults to NRT one. > -- 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-11724) Cdcr Bootstrapping does not cause "index copying" to follower nodes on Target
[ https://issues.apache.org/jira/browse/SOLR-11724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16902868#comment-16902868 ] Shalin Shekhar Mangar commented on SOLR-11724: -- A less brittle way would be to update the term for the leader once bootstrap finishes. This way the replicas will automatically go to recovery. The latest patch implements this idea. Tests pass. What's the best way to fix this issue? This issue was supposed to be fixed in 7.3 but the committed code didn't actually fix it. Should we reopen this issue or create a new one? > Cdcr Bootstrapping does not cause "index copying" to follower nodes on Target > - > > Key: SOLR-11724 > URL: https://issues.apache.org/jira/browse/SOLR-11724 > Project: Solr > Issue Type: Bug > Components: CDCR >Reporter: Amrit Sarkar >Assignee: Varun Thacker >Priority: Major > Fix For: 7.3.1, 7.4, 8.0 > > Attachments: SOLR-11724.patch, SOLR-11724.patch, SOLR-11724.patch, > SOLR-11724.patch, SOLR-11724.patch > > Time Spent: 10m > Remaining Estimate: 0h > > Please find the discussion on: > http://lucene.472066.n3.nabble.com/Issue-with-CDCR-bootstrapping-in-Solr-7-1-td4365258.html > If we index significant documents in to Source, stop indexing and then start > CDCR; bootstrapping only copies the index to leader node of shards of the > collection, and followers never receive the documents / index until and > unless atleast one document is inserted again on source; which propels to > target and target collection trigger index replication to followers. > This behavior needs to be addressed in proper manner, either at target > collection or while bootstrapping. -- 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-11724) Cdcr Bootstrapping does not cause "index copying" to follower nodes on Target
[ https://issues.apache.org/jira/browse/SOLR-11724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shalin Shekhar Mangar updated SOLR-11724: - Attachment: SOLR-11724.patch > Cdcr Bootstrapping does not cause "index copying" to follower nodes on Target > - > > Key: SOLR-11724 > URL: https://issues.apache.org/jira/browse/SOLR-11724 > Project: Solr > Issue Type: Bug > Components: CDCR >Reporter: Amrit Sarkar >Assignee: Varun Thacker >Priority: Major > Fix For: 7.3.1, 7.4, 8.0 > > Attachments: SOLR-11724.patch, SOLR-11724.patch, SOLR-11724.patch, > SOLR-11724.patch, SOLR-11724.patch > > Time Spent: 10m > Remaining Estimate: 0h > > Please find the discussion on: > http://lucene.472066.n3.nabble.com/Issue-with-CDCR-bootstrapping-in-Solr-7-1-td4365258.html > If we index significant documents in to Source, stop indexing and then start > CDCR; bootstrapping only copies the index to leader node of shards of the > collection, and followers never receive the documents / index until and > unless atleast one document is inserted again on source; which propels to > target and target collection trigger index replication to followers. > This behavior needs to be addressed in proper manner, either at target > collection or while bootstrapping. -- 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-13674) NodeAddedTrigger does not support configuration of replica type hint
[ https://issues.apache.org/jira/browse/SOLR-13674?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shalin Shekhar Mangar updated SOLR-13674: - Fix Version/s: 8.3 master (9.0) Component/s: AutoScaling > NodeAddedTrigger does not support configuration of replica type hint > > > Key: SOLR-13674 > URL: https://issues.apache.org/jira/browse/SOLR-13674 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: AutoScaling >Affects Versions: 7.6 >Reporter: Irena Shaigorodsky > Assignee: Shalin Shekhar Mangar >Priority: Major > Fix For: master (9.0), 8.3 > > Time Spent: 20m > Remaining Estimate: 0h > > The current code > org.apache.solr.cloud.autoscaling.ComputePlanAction#getNodeAddedSuggester > only sets COLL_SHARD hint, as a result any added replica will be NRT one. > Our current setup has TLOG nodes on physical hardware and PULL nodes on k8s > that are recycled periodically. An attempt to add those will bring the nodes > in the cluster as NRT one. > The root cause is > org.apache.solr.client.solrj.cloud.autoscaling.AddReplicaSuggester#tryEachNode > that expects to find the hint REPLICATYPE and defaults to NRT one. > -- 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] [Resolved] (SOLR-13674) NodeAddedTrigger does not support configuration of replica type hint
[ https://issues.apache.org/jira/browse/SOLR-13674?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shalin Shekhar Mangar resolved SOLR-13674. -- Resolution: Fixed This is merged into master and branch_8x. Thanks [~ishaigor]! > NodeAddedTrigger does not support configuration of replica type hint > > > Key: SOLR-13674 > URL: https://issues.apache.org/jira/browse/SOLR-13674 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: AutoScaling >Affects Versions: 7.6 >Reporter: Irena Shaigorodsky > Assignee: Shalin Shekhar Mangar >Priority: Major > Fix For: master (9.0), 8.3 > > Time Spent: 20m > Remaining Estimate: 0h > > The current code > org.apache.solr.cloud.autoscaling.ComputePlanAction#getNodeAddedSuggester > only sets COLL_SHARD hint, as a result any added replica will be NRT one. > Our current setup has TLOG nodes on physical hardware and PULL nodes on k8s > that are recycled periodically. An attempt to add those will bring the nodes > in the cluster as NRT one. > The root cause is > org.apache.solr.client.solrj.cloud.autoscaling.AddReplicaSuggester#tryEachNode > that expects to find the hint REPLICATYPE and defaults to NRT one. > -- 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-13674) NodeAddedTrigger does not support configuration of replica type hint
[ https://issues.apache.org/jira/browse/SOLR-13674?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shalin Shekhar Mangar updated SOLR-13674: - Summary: NodeAddedTrigger does not support configuration of replica type hint (was: NodeAddedTrigger does not support configuration of relica type hint) > NodeAddedTrigger does not support configuration of replica type hint > > > Key: SOLR-13674 > URL: https://issues.apache.org/jira/browse/SOLR-13674 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 7.6 >Reporter: Irena Shaigorodsky > Assignee: Shalin Shekhar Mangar >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > The current code > org.apache.solr.cloud.autoscaling.ComputePlanAction#getNodeAddedSuggester > only sets COLL_SHARD hint, as a result any added replica will be NRT one. > Our current setup has TLOG nodes on physical hardware and PULL nodes on k8s > that are recycled periodically. An attempt to add those will bring the nodes > in the cluster as NRT one. > The root cause is > org.apache.solr.client.solrj.cloud.autoscaling.AddReplicaSuggester#tryEachNode > that expects to find the hint REPLICATYPE and defaults to NRT one. > -- 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-13579) Create resource management API
[ https://issues.apache.org/jira/browse/SOLR-13579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16901705#comment-16901705 ] Shalin Shekhar Mangar commented on SOLR-13579: -- Thanks [~ab]. This is looking good. I've done a first pass through the design and code. It took a time to wrap my head around it and your jira comments describing the use-case and how it works really helped. I have some initial comments: # The DefaultResourceManaged has a bug I think. The pool can be created by createPool and it is scheduled immediately and added to the resourcePools map with the key being the name of the resource pool. So presumably we can create multiple pools of the same type which is as per the design. But the #registerComponent() method gets the pool for the given name and checks that there are no other pools with the same type? AIUI, there are no checks to see if the given managed component is actually registered in the other pools of the same type? This can be easily demonstrated by changing the TestDefaultResourceManagerPool.testBasic method and adding another pool with the same type. # The package-info.java for the managed package can benefit from some of the design documentation you have added in this Jira. # There is no v2 api for the /admin/resources? I'm going to do another pass and try it out and get back to you. > Create resource management API > -- > > Key: SOLR-13579 > URL: https://issues.apache.org/jira/browse/SOLR-13579 > Project: Solr > Issue Type: New Feature >Reporter: Andrzej Bialecki >Assignee: Andrzej Bialecki >Priority: Major > Attachments: SOLR-13579.patch, SOLR-13579.patch, SOLR-13579.patch, > SOLR-13579.patch, SOLR-13579.patch, SOLR-13579.patch, SOLR-13579.patch > > > Resource management framework API supporting the goals outlined in SOLR-13578. -- 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-13674) NodeAddedTrigger does not support configuration of relica type hint
[
https://issues.apache.org/jira/browse/SOLR-13674?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16899877#comment-16899877
]
Shalin Shekhar Mangar commented on SOLR-13674:
--
Thank you [~ishaigor] for the PR. The changes look good except that the new
test fails with:
{code}
82359 ERROR
(OverseerThreadFactory-437-thread-4-processing-n:127.0.0.1:43511_solr)
[n:127.0.0.1:43511_solr ] o.a.s.c.a.c.OverseerCollectionMessageHandler
Collection: testNodeAddedTriggerWithAddReplicaPreferredOpReplicaType_1Shard_0
operation: create failed:org.apache.solr.common.SolrException: Error getting
replica locations : No node can satisfy the rules "[{replica=#ALL, type=PULL,
sysprop.solrNodeType=PULL,
collection=testNodeAddedTriggerWithAddReplicaPreferredOpReplicaType_1Shard_0},
{replica=#ALL, type=TLOG, sysprop.solrNodeType=TLOG,
collection=testNodeAddedTriggerWithAddReplicaPreferredOpReplicaType_1Shard_0},
{replica=#ALL, type=NRT, sysprop.solrNodeType=NRT,
collection=testNodeAddedTriggerWithAddReplicaPreferredOpReplicaType_1Shard_0},
{nodeRole=overseer, replica=0,
collection=testNodeAddedTriggerWithAddReplicaPreferredOpReplicaType_1Shard_0},
{cores=<6, node=#ANY}, {replica=<2, shard=#EACH, node=#ANY,
collection=testNodeAddedTriggerWithAddReplicaPreferredOpReplicaType_1Shard_0}]
More details from logs in node : 127.0.0.1:43511_solr, errorId :
AutoScaling.error.diagnostics.14915037535846"
at
org.apache.solr.cloud.api.collections.CreateCollectionCmd.call(CreateCollectionCmd.java:195)
at
org.apache.solr.cloud.api.collections.OverseerCollectionMessageHandler.processMessage(OverseerCollectionMessageHandler.java:263)
at
org.apache.solr.cloud.OverseerTaskProcessor$Runner.run(OverseerTaskProcessor.java:505)
at
org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:209)
at
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.base/java.lang.Thread.run(Thread.java:834)
Caused by: org.apache.solr.common.SolrException: No node can satisfy the rules
"[{replica=#ALL, type=PULL, sysprop.solrNodeType=PULL,
collection=testNodeAddedTriggerWithAddReplicaPreferredOpReplicaType_1Shard_0},
{replica=#ALL, type=TLOG, sysprop.solrNodeType=TLOG,
collection=testNodeAddedTriggerWithAddReplicaPreferredOpReplicaType_1Shard_0},
{replica=#ALL, type=NRT, sysprop.solrNodeType=NRT,
collection=testNodeAddedTriggerWithAddReplicaPreferredOpReplicaType_1Shard_0},
{nodeRole=overseer, replica=0,
collection=testNodeAddedTriggerWithAddReplicaPreferredOpReplicaType_1Shard_0},
{cores=<6, node=#ANY}, {replica=<2, shard=#EACH, node=#ANY,
collection=testNodeAddedTriggerWithAddReplicaPreferredOpReplicaType_1Shard_0}]
More details from logs in node : 127.0.0.1:43511_solr, errorId :
AutoScaling.error.diagnostics.14915037535846"
at
org.apache.solr.client.solrj.cloud.autoscaling.PolicyHelper.getReplicaLocations(PolicyHelper.java:185)
at
org.apache.solr.cloud.api.collections.Assign.getPositionsUsingPolicy(Assign.java:382)
at
org.apache.solr.cloud.api.collections.Assign$PolicyBasedAssignStrategy.assign(Assign.java:630)
at
org.apache.solr.cloud.api.collections.CreateCollectionCmd.buildReplicaPositions(CreateCollectionCmd.java:410)
at
org.apache.solr.cloud.api.collections.CreateCollectionCmd.call(CreateCollectionCmd.java:190)
... 6 more
NOTE: reproduce with: ant test -Dtestcase=ComputePlanActionTest
-Dtests.method=testNodeAddedTriggerWithAddReplicaPreferredOpReplicaType_1Shard
-Dtests.seed=1363057E7AA562F7 -Dtests.slow=true -Dtests.badapples=true
-Dtests.locale=brx-IN -Dtests.timezone=Antarctica/Rothera -Dtests.asserts=true
-Dtests.file.encoding=UTF-8
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error
from server at http://127.0.0.1:43511/solr: Error getting replica locations :
No node can satisfy the rules "[{replica=#ALL, type=PULL,
sysprop.solrNodeType=PULL,
collection=testNodeAddedTriggerWithAddReplicaPreferredOpReplicaType_1Shard_0},
{replica=#ALL, type=TLOG, sysprop.solrNodeType=TLOG,
collection=testNodeAddedTriggerWithAddReplicaPreferredOpReplicaType_1Shard_0},
{replica=#ALL, type=NRT, sysprop.solrNodeType=NRT,
collection=testNodeAddedTriggerWithAddReplicaPreferredOpReplicaType_1Shard_0},
{nodeRole=overseer, replica=0,
collection=testNodeAddedTriggerWithAddReplicaPreferredOpReplicaType_1Shard_0},
{cores=<6, node=#ANY}, {replica=<2, shard=#EACH, node=#ANY,
collection=testNodeAddedTriggerWithAddReplicaPreferredOpReplicaType_1Shard_0}]
More details from logs in node : 127.0.0.1:43511_solr, errorId :
AutoScaling.error.diagnostics.14915037535846"
{code}
Can you
[jira] [Assigned] (SOLR-13674) NodeAddedTrigger does not support configuration of relica type hint
[ https://issues.apache.org/jira/browse/SOLR-13674?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shalin Shekhar Mangar reassigned SOLR-13674: Assignee: Shalin Shekhar Mangar > NodeAddedTrigger does not support configuration of relica type hint > --- > > Key: SOLR-13674 > URL: https://issues.apache.org/jira/browse/SOLR-13674 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 7.6 >Reporter: Irena Shaigorodsky > Assignee: Shalin Shekhar Mangar >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > The current code > org.apache.solr.cloud.autoscaling.ComputePlanAction#getNodeAddedSuggester > only sets COLL_SHARD hint, as a result any added replica will be NRT one. > Our current setup has TLOG nodes on physical hardware and PULL nodes on k8s > that are recycled periodically. An attempt to add those will bring the nodes > in the cluster as NRT one. > The root cause is > org.apache.solr.client.solrj.cloud.autoscaling.AddReplicaSuggester#tryEachNode > that expects to find the hint REPLICATYPE and defaults to NRT one. > -- 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-13616) Possible racecondition/deadlock between collection DELETE and PrepRecovery ? (TestPolicyCloud failures)
[ https://issues.apache.org/jira/browse/SOLR-13616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16881858#comment-16881858 ] Shalin Shekhar Mangar commented on SOLR-13616: -- Hoss and Dat -- thank you for investigating this! All usages of CollectionStateWatcher or LiveNodesWatcher will suffer from this problem i.e. the thread that runs the watcher swallows the exception so we should audit all their usages regardless of what solution we go for. > Possible racecondition/deadlock between collection DELETE and PrepRecovery ? > (TestPolicyCloud failures) > --- > > Key: SOLR-13616 > URL: https://issues.apache.org/jira/browse/SOLR-13616 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Hoss Man >Priority: Major > Attachments: SOLR-13616.test-incomplete.patch, > thetaphi_Lucene-Solr-master-Linux_24358.log.txt > > > Based on some recent jenkins failures in TestPolicyCloud, I suspect there is > a possible deadlock condition when attempting to delete a collection while > recovery is in progress. > I haven't been able to identify exactly where/why/how the problem occurs, but > it does not appear to be a test specific problem, and seems like it could > potentially affect anyone unlucky enough to issue poorly timed DELETE. > Details to follow in comments... -- 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
.14.v20181114.jar:9.4.14.v20181114]
> at org.eclipse.jetty.client.HttpClient$1.succeeded(HttpClient.java:589)
> ~[jetty-client-9.4.14.v20181114.jar:9.4.14.v20181114]
> at
> org.eclipse.jetty.util.SocketAddressResolver$Async.lambda$resolve$1(SocketAddressResolver.java:181)
> ~[jetty-util-9.4.14.v20181114.jar:9.4.14.v20181114]
> ... 4 more
> Caused by: java.net.ConnectException: Connection refused
> at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method) ~[?:1.8.0_191]
> at sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:717)
> ~[?:1.8.0_191]
> at sun.nio.ch.SocketAdaptor.connect(SocketAdaptor.java:111) ~[?:1.8.0_191]
> at
> org.eclipse.jetty.http2.client.HTTP2Client.connect(HTTP2Client.java:397)
> ~[http2-client-9.4.14.v20181114.jar:9.4.14.v20181114]
> at
> org.eclipse.jetty.http2.client.http.HttpClientTransportOverHTTP2.connect(HttpClientTransportOverHTTP2.java:146)
> ~[http2-http-client-transport-9.4.19.v20190610.jar:9.4.19.v20190610]
> at
> org.eclipse.jetty.http2.client.http.HttpClientTransportOverHTTP2.connect(HttpClientTransportOverHTTP2.java:141)
> ~[http2-http-client-transport-9.4.19.v20190610.jar:9.4.19.v20190610]
> at org.eclipse.jetty.client.HttpClient$1.connect(HttpClient.java:619)
> ~[jetty-client-9.4.14.v20181114.jar:9.4.14.v20181114]
> at org.eclipse.jetty.client.HttpClient$1.succeeded(HttpClient.java:596)
> ~[jetty-client-9.4.14.v20181114.jar:9.4.14.v20181114]
> at org.eclipse.jetty.client.HttpClient$1.succeeded(HttpClient.java:589)
> ~[jetty-client-9.4.14.v20181114.jar:9.4.14.v20181114]
> at
> org.eclipse.jetty.util.SocketAddressResolver$Async.lambda$resolve$1(SocketAddressResolver.java:181)
> ~[jetty-util-9.4.14.v20181114.jar:9.4.14.v20181114]
> ... 4 more
> 215690 ERROR (qtp175924403-2361) [n:127.0.0.1:55000_t_ayt%2Fs
> c:collDoRecoveryOnRestart s:shard1 r:core_node3
> x:collDoRecoveryOnRestart_shard1_replica_t1]
> o.a.s.u.p.DistributedZkUpdateProcessor Setting up to try to start recovery
> on replica core_node4 with url
> http://127.0.0.1:54997/t_ayt/s/collDoRecoveryOnRestart_shard1_replica_t2/
> by increasing leader term
> => java.net.ConnectException: Connection refused
> at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method)
> java.net.ConnectException: Connection refused
> at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method) ~[?:1.8.0_191]
> at sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:717)
> ~[?:1.8.0_191]
> at sun.nio.ch.SocketAdaptor.connect(SocketAdaptor.java:111) ~[?:1.8.0_191]
> at
> org.eclipse.jetty.http2.client.HTTP2Client.connect(HTTP2Client.java:397)
> ~[http2-client-9.4.14.v20181114.jar:9.4.14.v20181114]
> at
> org.eclipse.jetty.http2.client.http.HttpClientTransportOverHTTP2.connect(HttpClientTransportOverHTTP2.java:146)
> ~[http2-http-client-transport-9.4.19.v20190610.jar:9.4.19.v20190610]
> at
> org.eclipse.jetty.http2.client.http.HttpClientTransportOverHTTP2.connect(HttpClientTransportOverHTTP2.java:141)
> ~[http2-http-client-transport-9.4.19.v20190610.jar:9.4.19.v20190610]
> at org.eclipse.jetty.client.HttpClient$1.connect(HttpClient.java:619)
> ~[jetty-client-9.4.14.v20181114.jar:9.4.14.v20181114]
> at org.eclipse.jetty.client.HttpClient$1.succeeded(HttpClient.java:596)
> ~[jetty-client-9.4.14.v20181114.jar:9.4.14.v20181114]
> at org.eclipse.jetty.client.HttpClient$1.succeeded(HttpClient.java:589)
> ~[jetty-client-9.4.14.v20181114.jar:9.4.14.v20181114]
> at
> org.eclipse.jetty.util.SocketAddressResolver$Async.lambda$resolve$1(SocketAddressResolver.java:181)
> ~[jetty-util-9.4.14.v20181114.jar:9.4.14.v20181114]
> at
> org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:209)
> ~[java/:?]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> ~[?:1.8.0_191]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> ~[?:1.8.0_191]
> at java.lang.Thread.run(Thread.java:748) [?:1.8.0_191]
> 215690 INFO (qtp175924403-2361) [n:127.0.0.1:55000_t_ayt%2Fs
> c:collDoRecoveryOnRestart s:shard1 r:core_node3
> x:collDoRecoveryOnRestart_shard1_replica_t1] o.a.s.c.ZkShardTerms
> Successful update of terms at
> /collections/collDoRecoveryOnRestart/terms/shard1 to
> Terms{values={core_node3=2, core_node4=1}, version=3}
>
> This seems relates to the fix for SOLR-13413 when only
> http2-http-client-transport
> get upgraded to 9.4.19. The similar failure does not happen in branch_8x
> or master. I tried to switch back http2-http-client-transport 9.4.14 and
> the problem seems go away. So there are 2 solutions now for 8.1.2
>
>1. 8.1.2 will be released without SOLR-13413.
>2. upgrade Jetty to 9.4.19 for 8.1.2 release.
>
> I personally prefer the second option since there are no (or I think so)
> suspicious failures on master and branch_8x. What do you guys think?
>
> Thanks!
>
> On Thu, Jul 4, 2019 at 12:48 PM Uwe Schindler wrote:
>
>> No,
>>
>> Running with Java 9 is optional. You have to tell smoker to do this,
>> otherwise it enforces Java 8 only.
>>
>> Uwe
>>
>> Am July 4, 2019 2:22:40 AM UTC schrieb "Đạt Cao Mạnh" <
>> caomanhdat...@gmail.com>:
>>>
>>> Thanks Uwe, Steve
>>>
>>> I'm not familiar with the pipeline of smoker-release but I assumpt that
>>> the same pipeline will be run during release process in my machine and
>>> anyone who do the vote. So It won't be a blocker for this release and I can
>>> continue with the release process, is that correct?
>>>
>>
>> --
>> Uwe Schindler
>> Achterdiek 19, 28357 Bremen
>> https://www.thetaphi.de
>>
>
>
> --
> *Best regards,*
> *Cao Mạnh Đạt*
> *E-mail: caomanhdat...@gmail.com *
>
--
Regards,
Shalin Shekhar Mangar.
Re: Welcome Kevin Risden to the PMC
Welcome Kevin! On Thu, Jun 27, 2019 at 5:34 PM Jan Høydahl wrote: > 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 > > -- Regards, Shalin Shekhar Mangar.
Re: Welcome Munendra S N as Lucene/Solr committer
Congratulations and welcome Munendra! On Fri, Jun 21, 2019 at 3:12 PM Ishan Chattopadhyaya < ichattopadhy...@gmail.com> wrote: > 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 > > -- Regards, Shalin Shekhar Mangar.
Re: Welcome Namgyu Kim as Lucene/Solr committer
Congratulations and welcome Namgyu! On Mon, Jun 3, 2019 at 11:22 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 > > -- Regards, Shalin Shekhar Mangar.
Re: [VOTE] Release Lucene/Solr 7.7.2 RC1
+1 SUCCESS! [0:51:25.880324] On Wed, May 29, 2019 at 5:24 AM 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 > > -- Regards, Shalin Shekhar Mangar.
Re: [VOTE] Release Lucene/Solr 8.1.1 RC1
+1 SUCCESS! [0:58:36.297350] On Wed, May 22, 2019 at 11:23 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 > > -- Regards, Shalin Shekhar Mangar.
Re: Welcome Michael Sokolov as Lucene/ Solr committer
Congratulations and welcome Michael! On Tue, May 14, 2019 at 12:42 AM 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 > > -- Regards, Shalin Shekhar Mangar.
[jira] [Commented] (SOLR-13445) Preferred replicas on nodes with same system properties as the query master
[
https://issues.apache.org/jira/browse/SOLR-13445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16834405#comment-16834405
]
Shalin Shekhar Mangar commented on SOLR-13445:
--
Thanks Dat. A few comments:
# Minor nit: Rename HttpShardHandlerFactory#sameMetric to hasSameMetric
# Can you do an exponential backoff in NodesSysPropsCacher#fetchRemoteProps?
# The RoutingToNodesWithPropertiesTest needs a better check than comparing
shardAddress. The reason is that shardAddress is set by the GET_TOP_IDS phase
but not by other phases such as GET_FIELDS. Use TrackingShardHandlerFactory
instead.
# I agree with Andrzej that the fix to SolrClientNodeStateProvider should go to
a separate issue so that it can be backported to 7_7 if needed.
> Preferred replicas on nodes with same system properties as the query master
> ---
>
> Key: SOLR-13445
> URL: https://issues.apache.org/jira/browse/SOLR-13445
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Cao Manh Dat
>Assignee: Cao Manh Dat
>Priority: Major
> Attachments: SOLR-13445.patch
>
>
> Currently, Solr chooses a random replica for each shard to fan out the query
> request. However, this presents a problem when running Solr in multiple
> availability zones.
> If one availability zone fails then it affects all Solr nodes because they
> will try to connect to Solr nodes in the failed availability zone until the
> request times out. This can lead to a build up of threads on each Solr node
> until the node goes out of memory. This results in a cascading failure.
> This issue try to solve this problem by adding
> * another shardPreference param named {{node.sysprop}}, so the query will be
> routed to nodes with same defined system properties as the current one.
> * default shardPreferences on the whole cluster, which will be stored in
> {{/clusterprops.json}}.
> * a cacher for fetching other nodes system properties whenever /live_nodes
> get changed.
--
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-13266) /update/json/docs should support the JSON record format
[ https://issues.apache.org/jira/browse/SOLR-13266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16830903#comment-16830903 ] Shalin Shekhar Mangar commented on SOLR-13266: -- How about we move noggit to solr and make the required changes? I've seen multiple attempts to reach Yonik on noggit related changes but no traction on any requests. > /update/json/docs should support the JSON record format > --- > > Key: SOLR-13266 > URL: https://issues.apache.org/jira/browse/SOLR-13266 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Noble Paul >Priority: Major > > This is a standard [JSON format |https://tools.ietf.org/html/rfc7464]that > Solr does not support -- 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] [Created] (SOLR-13434) OpenTracing support for Solr
Shalin Shekhar Mangar created SOLR-13434: Summary: 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 Fix For: 8.1, master (9.0) [OpenTracing|https://opentracing.io/] is a vendor neutral API and infrastructure for distributed tracing. Many OSS tracers just as Jaeger, OpenZipkin 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] [Updated] (SOLR-13434) OpenTracing support for Solr
[ https://issues.apache.org/jira/browse/SOLR-13434?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shalin Shekhar Mangar updated SOLR-13434: - Description: [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. was: [OpenTracing|https://opentracing.io/] is a vendor neutral API and infrastructure for distributed tracing. Many OSS tracers just as Jaeger, OpenZipkin 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. > 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 >Priority: Major > Fix For: 8.1, master (9.0) > > > [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] [Resolved] (SOLR-13432) Add .toString methods to BitDocSet and SortedIntDocSet
[ https://issues.apache.org/jira/browse/SOLR-13432?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shalin Shekhar Mangar resolved SOLR-13432. -- Resolution: Fixed > Add .toString methods to BitDocSet and SortedIntDocSet > -- > > Key: SOLR-13432 > URL: https://issues.apache.org/jira/browse/SOLR-13432 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Reporter: Shalin Shekhar Mangar > Assignee: Shalin Shekhar Mangar >Priority: Major > Fix For: 8.1, master (9.0) > > Attachments: SOLR-13432.patch, SOLR-13432.patch > > > Add .toString methods to BitDocSet and SortedIntDocSet. The motivation here > is that the "showItems" property on FastLRUCache tries to show the items > inside the cache. But the output is not useful because these two classes > (used as values for filter cache) do not implement toString so the > Object.toString is called. -- 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-13433) Optionally track and expose ram usage for filter and query result caches
[
https://issues.apache.org/jira/browse/SOLR-13433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shalin Shekhar Mangar updated SOLR-13433:
-
Description:
One can enable maxRamMB on filter and query result caches and in that case the
ram usage of the caches is maintained and exposed as well as the entries are
evicted according to overall ram usage. However, the two features need not be
coupled together i.e. tracking and exposing ram usage can be a separate feature
from evicting by ram usage.
I propose to add an optional {{showRamUsage}} to filter and query result caches
that can be enabled to expose ram size of the cache. The default will be off
but if {{maxRamMB}} is set then {{showRamUsage}} is automatically set to true.
was:
One can enable maxRamMB on filter and query result caches and in that case the
ram usage of the caches is maintained and exposed as well as the entries are
evicted according to overall ram usage. However, the two features need not be
coupled together i.e. tracking and exposing ram usage can be a separate feature
from evicting by ram usage.
I propose to add an optional {{showRamUsage}} to filter and query result caches
that can be enabled to expose ram size of the cache. The default will be off
but if {{maxRamMB} is set then {{showRamUsage}} is automatically set to true.
> Optionally track and expose ram usage for filter and query result caches
>
>
> Key: SOLR-13433
> URL: https://issues.apache.org/jira/browse/SOLR-13433
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: Shalin Shekhar Mangar
> Assignee: Shalin Shekhar Mangar
>Priority: Major
> Fix For: 8.1, master (9.0)
>
>
> One can enable maxRamMB on filter and query result caches and in that case
> the ram usage of the caches is maintained and exposed as well as the entries
> are evicted according to overall ram usage. However, the two features need
> not be coupled together i.e. tracking and exposing ram usage can be a
> separate feature from evicting by ram usage.
> I propose to add an optional {{showRamUsage}} to filter and query result
> caches that can be enabled to expose ram size of the cache. The default will
> be off but if {{maxRamMB}} is set then {{showRamUsage}} is automatically set
> to true.
--
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] [Created] (SOLR-13433) Optionally track and expose ram usage for filter and query result caches
Shalin Shekhar Mangar created SOLR-13433:
Summary: Optionally track and expose ram usage for filter and
query result caches
Key: SOLR-13433
URL: https://issues.apache.org/jira/browse/SOLR-13433
Project: Solr
Issue Type: Improvement
Security Level: Public (Default Security Level. Issues are Public)
Reporter: Shalin Shekhar Mangar
Assignee: Shalin Shekhar Mangar
Fix For: 8.1, master (9.0)
One can enable maxRamMB on filter and query result caches and in that case the
ram usage of the caches is maintained and exposed as well as the entries are
evicted according to overall ram usage. However, the two features need not be
coupled together i.e. tracking and exposing ram usage can be a separate feature
from evicting by ram usage.
I propose to add an optional {{showRamUsage}} to filter and query result caches
that can be enabled to expose ram size of the cache. The default will be off
but if {{maxRamMB} is set then {{showRamUsage}} is automatically set to true.
--
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=16828937#comment-16828937
]
Shalin Shekhar Mangar commented on SOLR-13394:
--
[~ichattopadhyaya] - a few comments:
# G1GC is recommended for large heaps. This patch enables G1GC regardless of
the size of the heap.
# The default region size is very large at 16MB. G1GC recommends ~2048 regions
which would make this setting appropriate only for 32GB heaps or more. Can we
remove this explicit setting and let G1 choose the default.
# {{-XX:InitiatingHeapOccupancyPercent=45}} is redundant because the default is
already 45.
# Also if we are going to enable large pages, then adding
{{-XX:+AlwaysPreTouch}} is also a good idea to move the defrag costs to startup.
> 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] [Commented] (SOLR-13432) Add .toString methods to BitDocSet and SortedIntDocSet
[ https://issues.apache.org/jira/browse/SOLR-13432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16828896#comment-16828896 ] Shalin Shekhar Mangar commented on SOLR-13432: -- Slight modifications to use size() instead of size in both classes because the cached size value in BitDocSet may not be correct in case it is backed by a FixedBitSet. > Add .toString methods to BitDocSet and SortedIntDocSet > -- > > Key: SOLR-13432 > URL: https://issues.apache.org/jira/browse/SOLR-13432 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Reporter: Shalin Shekhar Mangar > Assignee: Shalin Shekhar Mangar >Priority: Major > Fix For: 8.1, master (9.0) > > Attachments: SOLR-13432.patch, SOLR-13432.patch > > > Add .toString methods to BitDocSet and SortedIntDocSet. The motivation here > is that the "showItems" property on FastLRUCache tries to show the items > inside the cache. But the output is not useful because these two classes > (used as values for filter cache) do not implement toString so the > Object.toString is called. -- 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-13432) Add .toString methods to BitDocSet and SortedIntDocSet
[ https://issues.apache.org/jira/browse/SOLR-13432?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shalin Shekhar Mangar updated SOLR-13432: - Attachment: SOLR-13432.patch > Add .toString methods to BitDocSet and SortedIntDocSet > -- > > Key: SOLR-13432 > URL: https://issues.apache.org/jira/browse/SOLR-13432 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Reporter: Shalin Shekhar Mangar > Assignee: Shalin Shekhar Mangar >Priority: Major > Fix For: 8.1, master (9.0) > > Attachments: SOLR-13432.patch, SOLR-13432.patch > > > Add .toString methods to BitDocSet and SortedIntDocSet. The motivation here > is that the "showItems" property on FastLRUCache tries to show the items > inside the cache. But the output is not useful because these two classes > (used as values for filter cache) do not implement toString so the > Object.toString is called. -- 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-13432) Add .toString methods to BitDocSet and SortedIntDocSet
[ https://issues.apache.org/jira/browse/SOLR-13432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16828894#comment-16828894 ] Shalin Shekhar Mangar commented on SOLR-13432: -- Here's a simple patch that adds toString method to both classes with size (number of docs) and ramUsed (human readable value of ramBytesUsed()). > Add .toString methods to BitDocSet and SortedIntDocSet > -- > > Key: SOLR-13432 > URL: https://issues.apache.org/jira/browse/SOLR-13432 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Reporter: Shalin Shekhar Mangar > Assignee: Shalin Shekhar Mangar >Priority: Major > Fix For: 8.1, master (9.0) > > Attachments: SOLR-13432.patch > > > Add .toString methods to BitDocSet and SortedIntDocSet. The motivation here > is that the "showItems" property on FastLRUCache tries to show the items > inside the cache. But the output is not useful because these two classes > (used as values for filter cache) do not implement toString so the > Object.toString is called. -- 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] [Created] (SOLR-13432) Add .toString methods to BitDocSet and SortedIntDocSet
Shalin Shekhar Mangar created SOLR-13432: Summary: Add .toString methods to BitDocSet and SortedIntDocSet Key: SOLR-13432 URL: https://issues.apache.org/jira/browse/SOLR-13432 Project: Solr Issue Type: Improvement Security Level: Public (Default Security Level. Issues are Public) Reporter: Shalin Shekhar Mangar Assignee: Shalin Shekhar Mangar Fix For: 8.1, master (9.0) Add .toString methods to BitDocSet and SortedIntDocSet. The motivation here is that the "showItems" property on FastLRUCache tries to show the items inside the cache. But the output is not useful because these two classes (used as values for filter cache) do not implement toString so the Object.toString is called. -- 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-13432) Add .toString methods to BitDocSet and SortedIntDocSet
[ https://issues.apache.org/jira/browse/SOLR-13432?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shalin Shekhar Mangar updated SOLR-13432: - Attachment: SOLR-13432.patch > Add .toString methods to BitDocSet and SortedIntDocSet > -- > > Key: SOLR-13432 > URL: https://issues.apache.org/jira/browse/SOLR-13432 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Reporter: Shalin Shekhar Mangar > Assignee: Shalin Shekhar Mangar >Priority: Major > Fix For: 8.1, master (9.0) > > Attachments: SOLR-13432.patch > > > Add .toString methods to BitDocSet and SortedIntDocSet. The motivation here > is that the "showItems" property on FastLRUCache tries to show the items > inside the cache. But the output is not useful because these two classes > (used as values for filter cache) do not implement toString so the > Object.toString is called. -- 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-13320) add a param ignoreDuplicates=true to updates to not overwrite existing docs
[
https://issues.apache.org/jira/browse/SOLR-13320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16825968#comment-16825968
]
Shalin Shekhar Mangar commented on SOLR-13320:
--
Thanks [~dragonsinth] for explaining the use-case and the problem.
These are conflicts -- a document was not the version we wanted it to be. Here
{{-1}} is just a special version that means the document should not have
existed. So I think {{ignoreConflicts}} or {{ignoreVersionConflicts}} is more
appropriate than {{ignoreDuplicates}}. Regardless of what we call the param,
returning a list of docs IDs that were skipped would be nice to have as Gus
noted. {{haltBatchOnError}} is definitely too broad and it is not always
possible to recover from errors e.g. if there is malformed JSON in the middle
of a batch.
> add a param ignoreDuplicates=true to updates to not overwrite existing docs
> ---
>
> Key: SOLR-13320
> URL: https://issues.apache.org/jira/browse/SOLR-13320
> Project: Solr
> Issue Type: New Feature
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
>
> Updates should have an option to ignore duplicate documents and drop them if
> an option {{ignoreDuplicates=true}} is specified
--
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] branch branch_7x updated: SOLR-13392: Add all solr dependencies to prometheus exporter classpath to make sure that it can start.
Sorry, I just searched the archives and saw the discussion about disallowing commits to 7x. I'll take care in future. On Mon, Apr 22, 2019 at 3:59 PM Uwe Schindler wrote: > Didn't we have a limitation added so one can't push to 7.x? > > Adrien how was the status there? > > Uwe > > Am April 22, 2019 6:50:58 AM UTC schrieb sha...@apache.org: >> >> This is an automated email from the ASF dual-hosted git repository. >> >> shalin pushed a commit to branch branch_7x >> in repository https://gitbox.apache.org/repos/asf/lucene-solr.git >> >> >> The following commit(s) were added to refs/heads/branch_7x by this push: >> new a5f75c6 SOLR-13392: Add all solr dependencies to prometheus >> exporter classpath to make sure that it can start. >> a5f75c6 is described below >> >> commit a5f75c62c33738bfbbabb439ebbfc1b143b0c4b9 >> Author: Shalin Shekhar Mangar >> AuthorDate: Mon Apr 22 12:18:56 2019 +0530 >> >> SOLR-13392: Add all solr dependencies to prometheus exporter classpath >> to make sure that it can start. >> >> SOLR-13234 broke prometheus exporter startup from the startup scripts >> because there was a mismatch between the dependency list in ant/ivy and >> those actually added to the classpath by the script. This commit changes the >> script to add all solr dependencies to the classpath. >> >> (cherry picked from commit 4571a2d66687cca6670885a94414c7a8c02c0bbc) >> -- >> solr/contrib/prometheus-exporter/bin/solr-exporter | 4 + >> .../prometheus-exporter/bin/solr-exporter.cmd | 208 >> ++--- >> 2 files changed, 108 insertions(+), 104 deletions(-) >> >> diff --git a/solr/contrib/prometheus-exporter/bin/solr-exporter >> b/solr/contrib/prometheus-exporter/bin/solr-exporter >> index 834e83e..ea34960 100755 >> --- a/solr/contrib/prometheus-exporter/bin/solr-exporter >> +++ b/solr/contrib/prometheus-exporter/bin/solr-exporter >> @@ -99,6 +99,10 @@ for JAR in $(find "$BASEDIR"/lucene-libs -name '*.jar') >> do >>CLASSPATH="$CLASSPATH":"$JAR" >> done >> +for JAR in $(find "$BASEDIR"/../../server/solr-webapp/webapp/WEB-INF/lib >> -name '*.jar') >> +do >> + CLASSPATH="$CLASSPATH":"$JAR" >> +done >> >> EXTRA_JVM_ARGUMENTS="-Xmx512m >> -Dlog4j.configurationFile=file:"$BASEDIR"/../../server/resources/log4j2-console.xml" >> >> diff --git a/solr/contrib/prometheus-exporter/bin/solr-exporter.cmd >> b/solr/contrib/prometheus-exporter/bin/solr-exporter.cmd >> index f51cfa8..4ff47cf 100644 >> --- a/solr/contrib/prometheus-exporter/bin/solr-exporter.cmd >> +++ b/solr/contrib/prometheus-exporter/bin/solr-exporter.cmd >> @@ -1,104 +1,104 @@ >> -@REM >> -@REM Licensed to the Apache Software Foundation (ASF) under one or more >> -@REM contributor license agreements. See the NOTICE file distributed with >> -@REM this work for additional information regarding copyright ownership. >> -@REM The ASF licenses this file to You under the Apache License, Version >> 2.0 >> -@REM (the "License"); you may not use this file except in compliance with >> -@REM the License. You may obtain a copy of the License at >> -@REM >> -@REM http://www.apache.org/licenses/LICENSE-2.0 >> -@REM >> -@REM Unless required by applicable law or agreed to in writing, software >> -@REM distributed under the License is distributed on an "AS IS" BASIS, >> -@REM WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or >> implied. >> -@REM See the License for the specific language governing permissions and >> -@REM limitations under the License. >> - >> -@echo off >> - >> -set ERROR_CODE=0 >> - >> -:init >> -@REM Decide how to startup depending on the version of windows >> - >> -@REM -- Win98ME >> -if NOT "%OS%"=="Windows_NT" goto Win9xArg >> - >> -@REM set local scope for the variables with windows NT shell >> -if "%OS%"=="Windows_NT" @setlocal >> - >> -@REM -- 4NT shell >> -if "%eval[2+2]" == "4" goto 4NTArgs >> - >> -@REM -- Regular WinNT shell >> -set CMD_LINE_ARGS=%* >> -goto WinNTGetScriptDir >> - >> -@REM The 4NT Shell from jp software >> -:4NTArgs >> -set CMD_LINE_ARGS=%$ >> -goto WinNTGetScriptDir >> - >> -:Win9xArg >> -@REM Slurp the command line arguments. This loop allows
[jira] [Resolved] (SOLR-13392) Unable to start prometheus-exporter in 7x branch
[ https://issues.apache.org/jira/browse/SOLR-13392?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shalin Shekhar Mangar resolved SOLR-13392. -- Resolution: Fixed Fix Version/s: master (9.0) 8.1 7.7.2 I've committed the patch in master, 8x, 7x and 7_7 so that the next 8.1 or 7.7.2 release have this fix. SOLR-13234 hasn't been released yet so no separate entry in CHANGES.txt is needed. > Unable to start prometheus-exporter in 7x branch > > > Key: SOLR-13392 > URL: https://issues.apache.org/jira/browse/SOLR-13392 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: metrics >Affects Versions: 7.7.2 >Reporter: Karl Stoney > Assignee: Shalin Shekhar Mangar >Priority: Major > Fix For: 7.7.2, 8.1, master (9.0) > > Attachments: SOLR-13392.patch > > > Hi, > prometheus-exporter doesn't start in branch 7x on commit > 7dfe1c093b65f77407c2df4c2a1120a213aef166, it does work on > 26b498d0a9d25626a15e25b0cf97c8339114263a so something has changed between > those two commits causing this. > I am presuming it is > https://github.com/apache/lucene-solr/commit/e1eeafb5dc077976646b06f4cba4d77534963fa9#diff-3f7b27f0f087632739effa2aa508d77eR34 > Exception in thread "main" java.lang.NoClassDefFoundError: > org/apache/lucene/util/IOUtils > at > org.apache.solr.core.SolrResourceLoader.close(SolrResourceLoader.java:881) > at > org.apache.solr.prometheus.exporter.SolrExporter.loadMetricsConfiguration(SolrExporter.java:221) > at > org.apache.solr.prometheus.exporter.SolrExporter.main(SolrExporter.java:205) > Caused by: java.lang.ClassNotFoundException: org.apache.lucene.util.IOUtils > at java.net.URLClassLoader.findClass(URLClassLoader.java:382) > at java.lang.ClassLoader.loadClass(ClassLoader.java:424) > at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:349) > at java.lang.ClassLoader.loadClass(ClassLoader.java:357) > ... 3 more -- 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-13392) Unable to start prometheus-exporter in 7x branch
[ https://issues.apache.org/jira/browse/SOLR-13392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16819748#comment-16819748 ] Shalin Shekhar Mangar commented on SOLR-13392: -- I've attached a trivial patch that adds all jars in solr-webapp/webapp/WEB-INF/lib to the classpath in the exporter's bin scripts. > Unable to start prometheus-exporter in 7x branch > > > Key: SOLR-13392 > URL: https://issues.apache.org/jira/browse/SOLR-13392 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: metrics >Affects Versions: 7.7.2 >Reporter: Karl Stoney > Assignee: Shalin Shekhar Mangar >Priority: Major > Attachments: SOLR-13392.patch > > > Hi, > prometheus-exporter doesn't start in branch 7x on commit > 7dfe1c093b65f77407c2df4c2a1120a213aef166, it does work on > 26b498d0a9d25626a15e25b0cf97c8339114263a so something has changed between > those two commits causing this. > I am presuming it is > https://github.com/apache/lucene-solr/commit/e1eeafb5dc077976646b06f4cba4d77534963fa9#diff-3f7b27f0f087632739effa2aa508d77eR34 > Exception in thread "main" java.lang.NoClassDefFoundError: > org/apache/lucene/util/IOUtils > at > org.apache.solr.core.SolrResourceLoader.close(SolrResourceLoader.java:881) > at > org.apache.solr.prometheus.exporter.SolrExporter.loadMetricsConfiguration(SolrExporter.java:221) > at > org.apache.solr.prometheus.exporter.SolrExporter.main(SolrExporter.java:205) > Caused by: java.lang.ClassNotFoundException: org.apache.lucene.util.IOUtils > at java.net.URLClassLoader.findClass(URLClassLoader.java:382) > at java.lang.ClassLoader.loadClass(ClassLoader.java:424) > at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:349) > at java.lang.ClassLoader.loadClass(ClassLoader.java:357) > ... 3 more -- 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-13392) Unable to start prometheus-exporter in 7x branch
[
https://issues.apache.org/jira/browse/SOLR-13392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16819747#comment-16819747
]
Shalin Shekhar Mangar commented on SOLR-13392:
--
Okay, so it is a little more tricky.
The exporter adds solr core as a dependency in its build and adds lucene's
analysis jar in the distribution so that it can access the lucene's
ResourceLoader (transitively from the SolrResourceLoader). This is why ant test
does not catch the problem. The resource loader calls IOUtils.close (which is
in lucene-core).
Before SOLR-13234, the loader's close method was never called(?) which is why
this dependency miss was not spotted. But the rabbit hole goes deeper, after
SOLR-13234, the exporter uses more of Solr core's dependencies such as guava
cache so it is not sufficient to just add lucene-core.jar. It is quite a mess,
I admit. It is easy to just add all of solr runtime dependencies on the class
path by adding {{server/solr-webapp/webapp/WEB-INF/lib}} to the classpath.
Other scripts such as zkCli do the same. Are there any objections on doing that?
> Unable to start prometheus-exporter in 7x branch
>
>
> Key: SOLR-13392
> URL: https://issues.apache.org/jira/browse/SOLR-13392
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: metrics
>Affects Versions: 7.7.2
>Reporter: Karl Stoney
> Assignee: Shalin Shekhar Mangar
>Priority: Major
> Attachments: SOLR-13392.patch
>
>
> Hi,
> prometheus-exporter doesn't start in branch 7x on commit
> 7dfe1c093b65f77407c2df4c2a1120a213aef166, it does work on
> 26b498d0a9d25626a15e25b0cf97c8339114263a so something has changed between
> those two commits causing this.
> I am presuming it is
> https://github.com/apache/lucene-solr/commit/e1eeafb5dc077976646b06f4cba4d77534963fa9#diff-3f7b27f0f087632739effa2aa508d77eR34
> Exception in thread "main" java.lang.NoClassDefFoundError:
> org/apache/lucene/util/IOUtils
> at
> org.apache.solr.core.SolrResourceLoader.close(SolrResourceLoader.java:881)
> at
> org.apache.solr.prometheus.exporter.SolrExporter.loadMetricsConfiguration(SolrExporter.java:221)
> at
> org.apache.solr.prometheus.exporter.SolrExporter.main(SolrExporter.java:205)
> Caused by: java.lang.ClassNotFoundException: org.apache.lucene.util.IOUtils
> at java.net.URLClassLoader.findClass(URLClassLoader.java:382)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:349)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> ... 3 more
--
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-13392) Unable to start prometheus-exporter in 7x branch
[ https://issues.apache.org/jira/browse/SOLR-13392?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shalin Shekhar Mangar updated SOLR-13392: - Attachment: SOLR-13392.patch > Unable to start prometheus-exporter in 7x branch > > > Key: SOLR-13392 > URL: https://issues.apache.org/jira/browse/SOLR-13392 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: metrics >Affects Versions: 7.7.2 >Reporter: Karl Stoney > Assignee: Shalin Shekhar Mangar >Priority: Major > Attachments: SOLR-13392.patch > > > Hi, > prometheus-exporter doesn't start in branch 7x on commit > 7dfe1c093b65f77407c2df4c2a1120a213aef166, it does work on > 26b498d0a9d25626a15e25b0cf97c8339114263a so something has changed between > those two commits causing this. > I am presuming it is > https://github.com/apache/lucene-solr/commit/e1eeafb5dc077976646b06f4cba4d77534963fa9#diff-3f7b27f0f087632739effa2aa508d77eR34 > Exception in thread "main" java.lang.NoClassDefFoundError: > org/apache/lucene/util/IOUtils > at > org.apache.solr.core.SolrResourceLoader.close(SolrResourceLoader.java:881) > at > org.apache.solr.prometheus.exporter.SolrExporter.loadMetricsConfiguration(SolrExporter.java:221) > at > org.apache.solr.prometheus.exporter.SolrExporter.main(SolrExporter.java:205) > Caused by: java.lang.ClassNotFoundException: org.apache.lucene.util.IOUtils > at java.net.URLClassLoader.findClass(URLClassLoader.java:382) > at java.lang.ClassLoader.loadClass(ClassLoader.java:424) > at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:349) > at java.lang.ClassLoader.loadClass(ClassLoader.java:357) > ... 3 more -- 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-13392) Unable to start prometheus-exporter in 7x branch
[ https://issues.apache.org/jira/browse/SOLR-13392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16819716#comment-16819716 ] Shalin Shekhar Mangar commented on SOLR-13392: -- Ok I can reproduce this easily. For some reason, our ivy and build.xml configurations add lucene-core as a dependency (perhaps transitively) to the prometheus-exporter contrib. But the runtime does not include that jar. I'll try to see if I can get the builds to fail because of this dependency and fix that first and then remove the lucene dependency from prometheus as it does not need it. > Unable to start prometheus-exporter in 7x branch > > > Key: SOLR-13392 > URL: https://issues.apache.org/jira/browse/SOLR-13392 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: metrics >Affects Versions: 7.7.2 >Reporter: Karl Stoney > Assignee: Shalin Shekhar Mangar >Priority: Major > > Hi, > prometheus-exporter doesn't start in branch 7x on commit > 7dfe1c093b65f77407c2df4c2a1120a213aef166, it does work on > 26b498d0a9d25626a15e25b0cf97c8339114263a so something has changed between > those two commits causing this. > I am presuming it is > https://github.com/apache/lucene-solr/commit/e1eeafb5dc077976646b06f4cba4d77534963fa9#diff-3f7b27f0f087632739effa2aa508d77eR34 > Exception in thread "main" java.lang.NoClassDefFoundError: > org/apache/lucene/util/IOUtils > at > org.apache.solr.core.SolrResourceLoader.close(SolrResourceLoader.java:881) > at > org.apache.solr.prometheus.exporter.SolrExporter.loadMetricsConfiguration(SolrExporter.java:221) > at > org.apache.solr.prometheus.exporter.SolrExporter.main(SolrExporter.java:205) > Caused by: java.lang.ClassNotFoundException: org.apache.lucene.util.IOUtils > at java.net.URLClassLoader.findClass(URLClassLoader.java:382) > at java.lang.ClassLoader.loadClass(ClassLoader.java:424) > at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:349) > at java.lang.ClassLoader.loadClass(ClassLoader.java:357) > ... 3 more -- 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] [Assigned] (SOLR-13392) Unable to start prometheus-exporter in 7x branch
[ https://issues.apache.org/jira/browse/SOLR-13392?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shalin Shekhar Mangar reassigned SOLR-13392: Assignee: Shalin Shekhar Mangar > Unable to start prometheus-exporter in 7x branch > > > Key: SOLR-13392 > URL: https://issues.apache.org/jira/browse/SOLR-13392 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: metrics >Affects Versions: 7.7.2 >Reporter: Karl Stoney > Assignee: Shalin Shekhar Mangar >Priority: Major > > Hi, > prometheus-exporter doesn't start in branch 7x on commit > 7dfe1c093b65f77407c2df4c2a1120a213aef166, it does work on > 26b498d0a9d25626a15e25b0cf97c8339114263a so something has changed between > those two commits causing this. > I am presuming it is > https://github.com/apache/lucene-solr/commit/e1eeafb5dc077976646b06f4cba4d77534963fa9#diff-3f7b27f0f087632739effa2aa508d77eR34 > Exception in thread "main" java.lang.NoClassDefFoundError: > org/apache/lucene/util/IOUtils > at > org.apache.solr.core.SolrResourceLoader.close(SolrResourceLoader.java:881) > at > org.apache.solr.prometheus.exporter.SolrExporter.loadMetricsConfiguration(SolrExporter.java:221) > at > org.apache.solr.prometheus.exporter.SolrExporter.main(SolrExporter.java:205) > Caused by: java.lang.ClassNotFoundException: org.apache.lucene.util.IOUtils > at java.net.URLClassLoader.findClass(URLClassLoader.java:382) > at java.lang.ClassLoader.loadClass(ClassLoader.java:424) > at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:349) > at java.lang.ClassLoader.loadClass(ClassLoader.java:357) > ... 3 more -- 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
