[jira] [Commented] (SOLR-15190) Create a release repo for Solr
[ https://issues.apache.org/jira/browse/SOLR-15190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17294015#comment-17294015 ] Anshum Gupta commented on SOLR-15190: - Yes, looks like we'll need some bootstrapping as part of the first operator release. Shouldn't require someone but we certainly need to document what's needed. > Create a release repo for Solr > -- > > Key: SOLR-15190 > URL: https://issues.apache.org/jira/browse/SOLR-15190 > Project: Solr > Issue Type: Sub-task >Reporter: Jan Høydahl >Priority: Major > > I think this will be created as we do the first release, i.e. nothing > explicit to do here until then? -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-15195) Onboard committers who are not on PMC
[ https://issues.apache.org/jira/browse/SOLR-15195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17291864#comment-17291864 ] Anshum Gupta commented on SOLR-15195: - [~janhoy] - guess we should do this sooner so the committers have access to the code, but also to other spaces e.g. Confluence ? > Onboard committers who are not on PMC > - > > Key: SOLR-15195 > URL: https://issues.apache.org/jira/browse/SOLR-15195 > Project: Solr > Issue Type: Sub-task >Reporter: Jan Høydahl >Assignee: Jan Høydahl >Priority: Major > > TLP was started with the PMC only. Now we need to give commit bit to the > existing Lucene committers, as decided by VOTE when establishing the project. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9802) Switch to new logo
[ https://issues.apache.org/jira/browse/LUCENE-9802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17290205#comment-17290205 ] Anshum Gupta commented on LUCENE-9802: -- Thanks Ryan! We might also need to provide this to ASF Infra or someone too, so that the logo is update on the ASF website too. Don't remember where all it might be used, but places like ApacheCon etc. certainly will need this. > Switch to new logo > -- > > Key: LUCENE-9802 > URL: https://issues.apache.org/jira/browse/LUCENE-9802 > Project: Lucene - Core > Issue Type: Task >Reporter: Ryan Ernst >Priority: Trivial > Attachments: Lucene Logo.zip > > > Last year we held a competition to create a new logo for Lucene. The vote was > [tallied|http://mail-archives.apache.org/mod_mbox/lucene-dev/202009.mbox/%3cca+dixd68cwx1-qmm4mdq5ybfbqwwt8gyy8wvyxbmcgmfrrj...@mail.gmail.com%3e], > and culminated in [this > submission|https://issues.apache.org/jira/browse/LUCENE-9221?focusedCommentId=17080525&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17080525] > winning. This issue is to actually deploy the logo where relevant. > The following is a non-exhaustive list of places that need to be handled: > * Lucene website > ** Top left on all pages > ** Banner > ** Documentation (just for new releases) > * Wikipedia > I'm also not sure where the assets should live permanently. I don't believe > there is a dedicated place the current logo lives, where one could simply > download it, other than just saving the image from site navigation. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14499) New Solr TLP site
[ https://issues.apache.org/jira/browse/SOLR-14499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17290203#comment-17290203 ] Anshum Gupta commented on SOLR-14499: - This is beautiful, thanks Jan! :) I agree with Houston too. > New Solr TLP site > - > > Key: SOLR-14499 > URL: https://issues.apache.org/jira/browse/SOLR-14499 > Project: Solr > Issue Type: Sub-task >Reporter: Jan Høydahl >Assignee: Jan Høydahl >Priority: Major > Attachments: Paletton-color-palette.html, only-yellow.png, > solr-new-site-screenshot.png, solr-security-and-news.png, > solr-site-green.png, solr-site-green.png, solr-site-yellow.png, > solr-site-yellow.png, stacked.png > > > # Get setup solr-site repo (start from lucene-site repo) > # Setup a temporary "work in progress" page on solr.apache.org > # Remove all lucene TLP, lucene-core and pylucene content, including > templates and css etc > # Move Solr index.html as main index file > # Simplify folder structure for Pelican > # Publish the new site -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14762) Fork the git repo into two new 'lucene' and 'solr'
[ https://issues.apache.org/jira/browse/SOLR-14762?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17290200#comment-17290200 ] Anshum Gupta commented on SOLR-14762: - Would it make sense to split the repos closer to when we can move forward with a Lucene 9.0 release? That would allow the new Solr branch to just rely on Lucene 9.0 as a dependency instead of dealing with the complexity. This might cover more than what's been discussed but just writing down everything that I've been thinking about and talking to a bunch of other folks too. 1. Make all changes to lucene-solr repo (features and fixes) that need to be done for a 9.0 release - Get to about 90% done. 2. Create branches as [~dweiss] suggested - suggesting we delay this so that there are fewer cherry-picks required. 3. Work on the build and release systems off those branches 4. Fork and clean up in the new repos 5. Release Lucene 9.0 6. Add Lucene 9.0 as a dependency for Solr 9.0, and ensure things work 7. Release Solr 9.0 > Fork the git repo into two new 'lucene' and 'solr' > -- > > Key: SOLR-14762 > URL: https://issues.apache.org/jira/browse/SOLR-14762 > Project: Solr > Issue Type: Sub-task >Reporter: Jan Høydahl >Priority: Major > > Existing git repo (and GitHub project) will be frozen and two new repos used > # Announce on all lists a date when the lucene-solr git repo will be frozen > This date should be e.g. 14 days in the future to allow in-flight commits and > PRs to be pushed > # At the freeze date, make a last commit adding a big announcement to > README.md about the location of the new repositories, then make both asf-git > and github R/O > # Clone 'lucene-solr' into new 'lucene' and 'solr' git repos > Then continue with separate LUCENE and SOLR jiras to prepare the new repos, > builds etc -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14760) Order new Solr mailing lists
[ https://issues.apache.org/jira/browse/SOLR-14760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17288980#comment-17288980 ] Anshum Gupta commented on SOLR-14760: - Totally forgot about the reporting, but that's a great point Jan. I was just waiting as Ishan had brought up his idea and I asked him to share it with the rest of the folks. I'll send out the notice first thing tomorrow morning my time i.e. in a few hours. > Order new Solr mailing lists > > > Key: SOLR-14760 > URL: https://issues.apache.org/jira/browse/SOLR-14760 > Project: Solr > Issue Type: Sub-task >Reporter: Jan Høydahl >Assignee: Anshum Gupta >Priority: Major > > 1. Use self-service tool > [https://selfserve.apache.org|https://selfserve.apache.org/] to create > mailing lists > (x) user@solr > (x) dev@solr > (x) issues@solr > (x) build@solr > 2. Send out an email to the old lists, requesting people to sign up for the > new lists. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14760) Order new Solr mailing lists
[ https://issues.apache.org/jira/browse/SOLR-14760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17288612#comment-17288612 ] Anshum Gupta commented on SOLR-14760: - I feel the same way about the clean break, and switching over in terms of long term value. > Order new Solr mailing lists > > > Key: SOLR-14760 > URL: https://issues.apache.org/jira/browse/SOLR-14760 > Project: Solr > Issue Type: Sub-task >Reporter: Jan Høydahl >Assignee: Anshum Gupta >Priority: Major > > 1. Use self-service tool > [https://selfserve.apache.org|https://selfserve.apache.org/] to create > mailing lists > (x) user@solr > (x) dev@solr > (x) issues@solr > (x) build@solr > 2. Send out an email to the old lists, requesting people to sign up for the > new lists. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14760) Order new Solr mailing lists
[ https://issues.apache.org/jira/browse/SOLR-14760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17288519#comment-17288519 ] Anshum Gupta commented on SOLR-14760: - I understand your concern, Ishan. If we create a new list, folks would still need to create a new rule, but we'll have a split history (which is ok for me). We'll also have to ask everyone to resubscribe, and some folks who are away or miss that email might find it strange that there are no new emails coming in. I'm fine either ways, but based on the suggestions on Slack from various folks, I went forward with the migration. P.S: pinged you on slack, in case you want to discuss more as that'd be less back and forth and we can share the summary here. > Order new Solr mailing lists > > > Key: SOLR-14760 > URL: https://issues.apache.org/jira/browse/SOLR-14760 > Project: Solr > Issue Type: Sub-task >Reporter: Jan Høydahl >Assignee: Anshum Gupta >Priority: Major > > 1. Use self-service tool > [https://selfserve.apache.org|https://selfserve.apache.org/] to create > mailing lists > (x) user@solr > (x) dev@solr > (x) issues@solr > (x) build@solr > 2. Send out an email to the old lists, requesting people to sign up for the > new lists. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14760) Order new Solr mailing lists
[ https://issues.apache.org/jira/browse/SOLR-14760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17288510#comment-17288510 ] Anshum Gupta commented on SOLR-14760: - Moving forward with the steps I mentioned in my last comment. Users wouldn't have to migrate but will need to change their client rules etc. so will send an email about the same after putting in the request. > Order new Solr mailing lists > > > Key: SOLR-14760 > URL: https://issues.apache.org/jira/browse/SOLR-14760 > Project: Solr > Issue Type: Sub-task >Reporter: Jan Høydahl >Assignee: Anshum Gupta >Priority: Major > > 1. Use self-service tool > [https://selfserve.apache.org|https://selfserve.apache.org/] to create > mailing lists > (x) user@solr > (x) dev@solr > (x) issues@solr > (x) build@solr > 2. Send out an email to the old lists, requesting people to sign up for the > new lists. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14760) Order new Solr mailing lists
[ https://issues.apache.org/jira/browse/SOLR-14760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17288071#comment-17288071 ] Anshum Gupta commented on SOLR-14760: - Speaking with Infra and some back and forth and figuring out what works best for the community, so far it seems like the following steps for the user list are a good way forward (copied from my discussion on #asfinfra): - Migrate solr-u...@lucene.apache.org to us...@solr.apache.org - Update the community to change their mail client rules - Everything else remains the same for the Solr user community w.r.t. the mailing list They replied with what seems like a +1 on this approach, but just clarifying before I request for the migration. Will also send an update to the user list about this change once we have confirmation on the path. > Order new Solr mailing lists > > > Key: SOLR-14760 > URL: https://issues.apache.org/jira/browse/SOLR-14760 > Project: Solr > Issue Type: Sub-task >Reporter: Jan Høydahl >Assignee: Anshum Gupta >Priority: Major > > 1. Use self-service tool > [https://selfserve.apache.org|https://selfserve.apache.org/] to create > mailing lists > (x) user@solr > (x) dev@solr > (x) issues@solr > (x) build@solr > 2. Send out an email to the old lists, requesting people to sign up for the > new lists. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14760) Order new Solr mailing lists
[ https://issues.apache.org/jira/browse/SOLR-14760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17286796#comment-17286796 ] Anshum Gupta commented on SOLR-14760: - The requests for new lists have been put in. Waiting to hear from other folks about what they feel is a good path w.r.t. repurposing/migrating the old list vs creating a new list and marking the old one as read-only. The following lists should be created in the next 24 Hrs (SLA by Infra) - private (PMC only) - security (PMC only) - builds - commits - dev - issues > Order new Solr mailing lists > > > Key: SOLR-14760 > URL: https://issues.apache.org/jira/browse/SOLR-14760 > Project: Solr > Issue Type: Sub-task >Reporter: Jan Høydahl >Assignee: Anshum Gupta >Priority: Major > > 1. Use self-service tool > [https://selfserve.apache.org|https://selfserve.apache.org/] to create > mailing lists > (x) user@solr > (x) dev@solr > (x) issues@solr > (x) build@solr > 2. Send out an email to the old lists, requesting people to sign up for the > new lists. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Assigned] (SOLR-14760) Order new Solr mailing lists
[ https://issues.apache.org/jira/browse/SOLR-14760?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anshum Gupta reassigned SOLR-14760: --- Assignee: Anshum Gupta (was: Jan Høydahl) > Order new Solr mailing lists > > > Key: SOLR-14760 > URL: https://issues.apache.org/jira/browse/SOLR-14760 > Project: Solr > Issue Type: Sub-task >Reporter: Jan Høydahl >Assignee: Anshum Gupta >Priority: Major > > 1. Use self-service tool > [https://selfserve.apache.org|https://selfserve.apache.org/] to create > mailing lists > (x) user@solr > (x) dev@solr > (x) issues@solr > (x) build@solr > 2. Send out an email to the old lists, requesting people to sign up for the > new lists. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14760) Order new Solr mailing lists
[ https://issues.apache.org/jira/browse/SOLR-14760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17286777#comment-17286777 ] Anshum Gupta commented on SOLR-14760: - I've confirmed with INFRA (via Slack) that a migration of the list should be possible. Migrate: - solr-u...@lucene.apache.org -> u...@solr.apache.org New Lists: - d...@solr.apache.org - iss...@solr.apache.org - comm...@solr.apachr.org - bu...@solr.apache.org - secur...@solr.apache.org > Order new Solr mailing lists > > > Key: SOLR-14760 > URL: https://issues.apache.org/jira/browse/SOLR-14760 > Project: Solr > Issue Type: Sub-task >Reporter: Jan Høydahl >Assignee: Jan Høydahl >Priority: Major > > 1. Use self-service tool > [https://selfserve.apache.org|https://selfserve.apache.org/] to create > mailing lists > (x) user@solr > (x) dev@solr > (x) issues@solr > (x) build@solr > 2. Send out an email to the old lists, requesting people to sign up for the > new lists. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14760) Order new Solr mailing lists
[ https://issues.apache.org/jira/browse/SOLR-14760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17286769#comment-17286769 ] Anshum Gupta commented on SOLR-14760: - We should explore the possibility of renaming or porting over the lists so that people can avoid having to re-register. Perhaps worth checking with INFRA? I can create an INFRA JIRA to get that information. > Order new Solr mailing lists > > > Key: SOLR-14760 > URL: https://issues.apache.org/jira/browse/SOLR-14760 > Project: Solr > Issue Type: Sub-task >Reporter: Jan Høydahl >Assignee: Jan Høydahl >Priority: Major > > 1. Use self-service tool > [https://selfserve.apache.org|https://selfserve.apache.org/] to create > mailing lists > (x) user@solr > (x) dev@solr > (x) issues@solr > (x) build@solr > 2. Send out an email to the old lists, requesting people to sign up for the > new lists. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Created] (SOLR-15163) Merge or delete the old Solr project at projects.apache.org
Anshum Gupta created SOLR-15163: --- Summary: Merge or delete the old Solr project at projects.apache.org Key: SOLR-15163 URL: https://issues.apache.org/jira/browse/SOLR-15163 Project: Solr Issue Type: Sub-task Reporter: Anshum Gupta Assignee: Anshum Gupta Currently two projects exist at projects.apache.org. 1. https://projects.apache.org/project.html?solr (managed by Solr) 2. https://projects.apache.org/project.html?lucene-solr (Managed by Lucene) We need to merge and/or delete the Solr project listed at #2 into #1. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-15145) Older versions of SolrJ (pre-8.8.0) hit an NPE when computing the base_url for core node props
[
https://issues.apache.org/jira/browse/SOLR-15145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17281412#comment-17281412
]
Anshum Gupta commented on SOLR-15145:
-
A system property seems like the obvious way forward here, specially
considering there's not much we can do around the back-compat issue.
I really prefer the idea of defaulting to storing the {{base_url}} as the
intention here is to maintain back-compat. Anything else would break
back-compat and would require users to change their code/deployments.
We'll also need a release in the near future to take care of this as it blocks
rolling restarts.
I can take care of the release if you want.
> Older versions of SolrJ (pre-8.8.0) hit an NPE when computing the base_url
> for core node props
> --
>
> Key: SOLR-15145
> URL: https://issues.apache.org/jira/browse/SOLR-15145
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrJ
>Affects Versions: 8.8
>Reporter: Timothy Potter
>Assignee: Timothy Potter
>Priority: Critical
> Fix For: 8.8.1
>
>
> From the mailing list:
> {code}
> Caused by: java.lang.NullPointerException
> at
> deployment.uleaf.ear//org.apache.solr.common.cloud.ZkCoreNodeProps.getCoreUrl(ZkCoreNodeProps.java:53)
> at
> deployment.uleaf.ear//org.apache.solr.client.solrj.impl.BaseCloudSolrClient.lambda$sendRequest$2(BaseCloudSolrClient.java:1161)
> at java.base/java.util.ArrayList.forEach(ArrayList.java:1540)
> at
> deployment.uleaf.ear//org.apache.solr.client.solrj.impl.BaseCloudSolrClient.sendRequest(BaseCloudSolrClient.java:1159)
> at
> deployment.uleaf.ear//org.apache.solr.client.solrj.impl.BaseCloudSolrClient.requestWithRetryOnStaleState(BaseCloudSolrClient.java:934)
> ... 166 more
> {code}
> see:
> https://lists.apache.org/thread.html/r3d131030f0a7026235451f71fabdae6d6b7c2f955822c75dcad4d41f%40%3Csolr-user.lucene.apache.org%3E
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-15089) Allow backup/restoration to Amazon's S3 blobstore
[ https://issues.apache.org/jira/browse/SOLR-15089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17278294#comment-17278294 ] Anshum Gupta commented on SOLR-15089: - This is really cool, Jason! I don't think there's any way (yet) to get AWS credits via Apache. Anyone who needs something along those lines would have to use free credits or pay for it themselves. As Varun mentioned, I think that mocks is a reasonable way to proceed and there's be enough people who'd want to take this to production and would have access to test and report. I know, not ideal but guess it'll work :) > Allow backup/restoration to Amazon's S3 blobstore > -- > > Key: SOLR-15089 > URL: https://issues.apache.org/jira/browse/SOLR-15089 > Project: Solr > Issue Type: Sub-task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Jason Gerlowski >Priority: Major > > Solr's BackupRepository interface provides an abstraction around the physical > location/format that backups are stored in. This allows plugin writers to > create "repositories" for a variety of storage mediums. It'd be nice if Solr > offered more mediums out of the box though, such as some of the "blobstore" > offerings provided by various cloud providers. > This ticket proposes that a "BackupRepository" implementation for Amazon's > popular 'S3' blobstore, so that Solr users can use it for backups without > needing to write their own code. > Amazon offers a s3 Java client with acceptable licensing, and the required > code is relatively simple. The biggest challenge in supporting this will > likely be procedural - integration testing requires S3 access and S3 access > costs money. We can check with INFRA to see if there is any way to get cloud > credits for an integration test to run in nightly Jenkins runs on the ASF > Jenkins server. Alternatively we can try to stub out the blobstore in some > reliable way. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-15119) Make LINK splitMethod the default for SplitShardCmd
[
https://issues.apache.org/jira/browse/SOLR-15119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17274049#comment-17274049
]
Anshum Gupta commented on SOLR-15119:
-
Also, the IndexSizeTrigger that uses {{LINK}} is supposed to be removed in
9.0, which would be the fix version for this JIRA.
> Make LINK splitMethod the default for SplitShardCmd
> ---
>
> Key: SOLR-15119
> URL: https://issues.apache.org/jira/browse/SOLR-15119
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: master (9.0)
>Reporter: Megan Carey
>Priority: Major
> Labels: easy-fix
> Time Spent: 20m
> Remaining Estimate: 0h
>
> REWRITE splitMethod is still the default in SplitShardCmd [1], despite LINK
> being much faster. IndexSizeTrigger in branch_8x already uses LINK by default
> [2], and we have found LINK to be reliable and performant at scale. This work
> will just update the default in SplitShardCmd to make LINK the default
> overall.
>
>
> [1][https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/cloud/api/collections/SplitShardCmd.java#L88]
>
> [2][https://github.com/apache/lucene-solr/blob/branch_8x/solr/core/src/java/org/apache/solr/cloud/autoscaling/IndexSizeTrigger.java#L186]
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-15119) Make LINK splitMethod the default for SplitShardCmd
[
https://issues.apache.org/jira/browse/SOLR-15119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17274046#comment-17274046
]
Anshum Gupta commented on SOLR-15119:
-
Unless something changed recently, I feel like {{LINK}} just defers the
actual split. In most use cases that I've encountered, where you want to
improve disk usage, achieve the replication factor, and also rebalance the
replicas/shards after the split, in which case this doesn't save much for users.
I understand you might have something else in mind, but can you please
elaborate a little more on why defaulting to this is better?
> Make LINK splitMethod the default for SplitShardCmd
> ---
>
> Key: SOLR-15119
> URL: https://issues.apache.org/jira/browse/SOLR-15119
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: master (9.0)
>Reporter: Megan Carey
>Priority: Major
> Labels: easy-fix
> Time Spent: 20m
> Remaining Estimate: 0h
>
> REWRITE splitMethod is still the default in SplitShardCmd [1], despite LINK
> being much faster. IndexSizeTrigger in branch_8x already uses LINK by default
> [2], and we have found LINK to be reliable and performant at scale. This work
> will just update the default in SplitShardCmd to make LINK the default
> overall.
>
>
> [1][https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/cloud/api/collections/SplitShardCmd.java#L88]
>
> [2][https://github.com/apache/lucene-solr/blob/branch_8x/solr/core/src/java/org/apache/solr/cloud/autoscaling/IndexSizeTrigger.java#L186]
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14216) Exclude HealthCheck from authentication
[
https://issues.apache.org/jira/browse/SOLR-14216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17272456#comment-17272456
]
Anshum Gupta commented on SOLR-14216:
-
After having thought more about this, and realizing the importance of this, I
think this will provide a lot of value to users.
Sorry about the back and forth, [~janhoy] .
> Exclude HealthCheck from authentication
> ---
>
> Key: SOLR-14216
> URL: https://issues.apache.org/jira/browse/SOLR-14216
> Project: Solr
> Issue Type: Improvement
> Components: Authentication
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The {{HealthCheckHandler}} on {{/api/node/health}} and
> {{/solr/admin/info/health}} should by default not be subject to
> authentication, but be open for all. This allows for load balancers and
> various monitoring to probe Solr's health without having to support the auth
> scheme in place. I can't see any reason we need auth on the health endpoint.
> It is possible to achieve the same by setting blockUnknown=false and
> configuring three RBAC permissions: One for v1 endpoint, one for v2 endpoint
> and one "all" catch all at the end of the chain. But this is cumbersome so
> better have this ootb.
> An alternative solution is to create a separate HttpServer for health check,
> listening on a different port, just like embedded ZK and JMX.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-15097) Cluster graph in admin UI is broken
[ https://issues.apache.org/jira/browse/SOLR-15097?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anshum Gupta updated SOLR-15097: Affects Version/s: (was: 8.8) > Cluster graph in admin UI is broken > --- > > Key: SOLR-15097 > URL: https://issues.apache.org/jira/browse/SOLR-15097 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Anshum Gupta >Assignee: Timothy Potter >Priority: Blocker > Fix For: 8.8 > > > Cluster graph is broken in the Admin UI and doesn't reflect any collections. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-15097) Cluster graph in admin UI is broken
[ https://issues.apache.org/jira/browse/SOLR-15097?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17269683#comment-17269683 ] Anshum Gupta commented on SOLR-15097: - Removing 'affects version' as this was never released. > Cluster graph in admin UI is broken > --- > > Key: SOLR-15097 > URL: https://issues.apache.org/jira/browse/SOLR-15097 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Anshum Gupta >Assignee: Timothy Potter >Priority: Blocker > Fix For: 8.8 > > > Cluster graph is broken in the Admin UI and doesn't reflect any collections. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Created] (SOLR-15097) Cluster graph in admin UI is broken
Anshum Gupta created SOLR-15097: --- Summary: Cluster graph in admin UI is broken Key: SOLR-15097 URL: https://issues.apache.org/jira/browse/SOLR-15097 Project: Solr Issue Type: Bug Security Level: Public (Default Security Level. Issues are Public) Reporter: Anshum Gupta Cluster graph is broken in the Admin UI and doesn't reflect any collections. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Created] (SOLR-14994) Bring in Solr Operator into the Lucene project
Anshum Gupta created SOLR-14994: --- Summary: Bring in Solr Operator into the Lucene project Key: SOLR-14994 URL: https://issues.apache.org/jira/browse/SOLR-14994 Project: Solr Issue Type: Task Security Level: Public (Default Security Level. Issues are Public) Reporter: Anshum Gupta Assignee: Anshum Gupta Solr Operator project codebase is currently in the process of being donated to the Apache Lucene project. This is an umbrella JIRA to track the progress and tasks associated. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-12182) Can not switch urlScheme in 7x if there are any cores in the cluster
[ https://issues.apache.org/jira/browse/SOLR-12182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17217998#comment-17217998 ] Anshum Gupta commented on SOLR-12182: - While we can always improve the documentation, I don't think this is really a user facing change. The only part of this that is user facing is currently a bug that stops people from switching between url schemes (http <-> https) even when following the current documentation. > Can not switch urlScheme in 7x if there are any cores in the cluster > > > Key: SOLR-12182 > URL: https://issues.apache.org/jira/browse/SOLR-12182 > Project: Solr > Issue Type: Bug >Affects Versions: 7.0, 7.1, 7.2 >Reporter: Anshum Gupta >Assignee: Timothy Potter >Priority: Major > Fix For: master (9.0) > > Attachments: SOLR-12182.patch, SOLR-12182_20200423.patch > > Time Spent: 1h 20m > Remaining Estimate: 0h > > I was trying to enable TLS on a cluster that was already in use i.e. had > existing collections and ended up with down cores, that wouldn't come up and > the following core init errors in the logs: > *org.apache.solr.common.SolrException:org.apache.solr.common.SolrException: > replica with coreNodeName core_node4 exists but with a different name or > base_url.* > What is happening here is that the core/replica is defined in the > clusterstate with the urlScheme as part of it's base URL e.g. > *"base_url":"http:hostname:port/solr"*. > Switching the urlScheme in Solr breaks this convention as the host now uses > HTTPS instead. > Actually, I ran into this with an older version because I was running with > *legacyCloud=false* and then realized that we switched that to the default > behavior only in 7x i.e while most users did not hit this issue with older > versions, unless they overrode the legacyCloud value explicitly, users > running 7x are bound to run into this more often. > Switching the value of legacyCloud to true, bouncing the cluster so that the > clusterstate gets flushed, and then setting it back to false is a workaround > but a bit risky one if you don't know if you have any old cores lying around. > Ideally, I think we shouldn't prepend the urlScheme to the base_url value and > use the urlScheme on the fly to construct it. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Resolved] (SOLR-14938) Solr 8.6.3
[ https://issues.apache.org/jira/browse/SOLR-14938?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anshum Gupta resolved SOLR-14938. - Resolution: Invalid [~krisgurusamy] - Please ask questions regarding usage on the Solr user mailing list. JIRA is meant for issue tracking purposes. > Solr 8.6.3 > -- > > Key: SOLR-14938 > URL: https://issues.apache.org/jira/browse/SOLR-14938 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: contrib - DataImportHandler >Reporter: Krishnan >Priority: Major > > I've just downloaded solr 8.6.3 and trying to create DIH for loading > structured XML. I found out that DIH will be deprecated soon with version > 9.0. What is the equivalent of DIH in new solr version? How do I import > structured XML data which is very custom and index in Solr new version? Any > help is appreciated. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14759) Separate the Lucene and Solr builds
[ https://issues.apache.org/jira/browse/SOLR-14759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17210433#comment-17210433 ] Anshum Gupta commented on SOLR-14759: - Thanks for doing this, [~dweiss]! This looks promising and a step in the direction we want to move in. Considering this doesn't impact anything but master, I think we should be able to do this prior to 9.0 unless someone has a reason to wait. > Separate the Lucene and Solr builds > --- > > Key: SOLR-14759 > URL: https://issues.apache.org/jira/browse/SOLR-14759 > Project: Solr > Issue Type: Sub-task > Components: Build >Reporter: Jan Høydahl >Assignee: Dawid Weiss >Priority: Major > > While still in same git repo, separate the builds, so Lucene and Solr can be > built independently. > This is a preparation step which will make it easier to prune the new git > repos post-split. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14151) Make schema components load from packages
[
https://issues.apache.org/jira/browse/SOLR-14151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17203744#comment-17203744
]
Anshum Gupta commented on SOLR-14151:
-
Hey [~noble.paul], It'll be really useful for everyone else looking at the
commits if you would merge your commits with a comment that summarizes the
change.
> Make schema components load from packages
> -
>
> Key: SOLR-14151
> URL: https://issues.apache.org/jira/browse/SOLR-14151
> Project: Solr
> Issue Type: Sub-task
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Blocker
> Labels: packagemanager
> Fix For: 8.7
>
> Time Spent: 13.5h
> Remaining Estimate: 0h
>
> Example:
> {code:xml}
>
>
>
>generateNumberParts="0" catenateWords="0"
> catenateNumbers="0" catenateAll="0"/>
>
>
>
>
> {code}
> * When a package is updated, the entire {{IndexSchema}} object is refreshed,
> but the SolrCore object is not reloaded
> * Any component can be prefixed with the package name
> * The semantics of loading plugins remain the same as that of the components
> in {{solrconfig.xml}}
> * Plugins can be registered using schema API
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14828) reduce 'error' logging noise in BaseCloudSolrClient.requestWithRetryOnStaleState
[
https://issues.apache.org/jira/browse/SOLR-14828?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17196582#comment-17196582
]
Anshum Gupta commented on SOLR-14828:
-
+1 on converting this to {{INFO}} and ideally also changing the message to not
say that it 'failed' or at least saying it will be retried.
> reduce 'error' logging noise in
> BaseCloudSolrClient.requestWithRetryOnStaleState
>
>
> Key: SOLR-14828
> URL: https://issues.apache.org/jira/browse/SOLR-14828
> Project: Solr
> Issue Type: Task
> Components: SolrJ
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Currently -- e.g.
> https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.6.2/solr/solrj/src/java/org/apache/solr/client/solrj/impl/BaseCloudSolrClient.java#L960-L961
> -- an error is logged even if request retrying will happen (and hopefully
> succeed).
> This task proposes to 'info' or 'warn' rather than 'error' log if the request
> will be retried.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-13998) Add thread safety annotation to classes
[ https://issues.apache.org/jira/browse/SOLR-13998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17177980#comment-17177980 ] Anshum Gupta commented on SOLR-13998: - +1 on fixing this annotation. SolrThreadSafe/SolrThreadUnsafe is a great suggestion. > Add thread safety annotation to classes > --- > > Key: SOLR-13998 > URL: https://issues.apache.org/jira/browse/SOLR-13998 > Project: Solr > Issue Type: Improvement >Reporter: Anshum Gupta >Assignee: Anshum Gupta >Priority: Major > Fix For: master (9.0), 8.4 > > Time Spent: 1.5h > Remaining Estimate: 0h > > Add annotations that can be used to mark classes as thread safe / single > threaded in Solr. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-5986) Don't allow runaway queries from harming Solr cluster health or search performance
[ https://issues.apache.org/jira/browse/SOLR-5986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17176669#comment-17176669 ] Anshum Gupta commented on SOLR-5986: Not at the time. I think there was some value that the TLC provided in terms of tracking and exiting in a phase that the ExitableDirectoryReader didn't cover. The use case required for both to exist. Ideally, would have loved to have just a clean approach that tracked the time in one place, but that would've required a very different level of plumbing. If the collection really takes most of the time, instead of the query expansion/rewriting I think you would still want TLC as a user. > Don't allow runaway queries from harming Solr cluster health or search > performance > -- > > Key: SOLR-5986 > URL: https://issues.apache.org/jira/browse/SOLR-5986 > Project: Solr > Issue Type: Improvement > Components: search >Reporter: Steve Davids >Assignee: Anshum Gupta >Priority: Critical > Fix For: 5.0 > > Attachments: SOLR-5986-fixtests.patch, SOLR-5986-fixtests.patch, > SOLR-5986-fixtests.patch, SOLR-5986.patch, SOLR-5986.patch, SOLR-5986.patch, > SOLR-5986.patch, SOLR-5986.patch, SOLR-5986.patch, SOLR-5986.patch, > SOLR-5986.patch, SOLR-5986.patch, SOLR-5986.patch, SOLR-5986.patch, > SOLR-5986.patch > > > The intent of this ticket is to have all distributed search requests stop > wasting CPU cycles on requests that have already timed out or are so > complicated that they won't be able to execute. We have come across a case > where a nasty wildcard query within a proximity clause was causing the > cluster to enumerate terms for hours even though the query timeout was set to > minutes. This caused a noticeable slowdown within the system which made us > restart the replicas that happened to service that one request, the worst > case scenario are users with a relatively low zk timeout value will have > nodes start dropping from the cluster due to long GC pauses. > [~amccurry] Built a mechanism into Apache Blur to help with the issue in > BLUR-142 (see commit comment for code, though look at the latest code on the > trunk for newer bug fixes). > Solr should be able to either prevent these problematic queries from running > by some heuristic (possibly estimated size of heap usage) or be able to > execute a thread interrupt on all query threads once the time threshold is > met. This issue mirrors what others have discussed on the mailing list: > http://mail-archives.apache.org/mod_mbox/lucene-solr-user/200903.mbox/%3c856ac15f0903272054q2dbdbd19kea3c5ba9e105b...@mail.gmail.com%3E -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-13998) Add thread safety annotation to classes
[ https://issues.apache.org/jira/browse/SOLR-13998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17176075#comment-17176075 ] Anshum Gupta edited comment on SOLR-13998 at 8/12/20, 6:56 AM: --- [~marcussorealheis] - The idea behind this came from a branch that was shared by Mark, and while I was planning to pick a bunch of those changes to improve a few things in Solr, I didn't get the bandwidth to continue with this effort. The idea here is to have an option that allows to annotate classes in Solr w.r.t. threadsafety. While retrofitting that might be tricky, it can certainly be used for new classes. This mechanism allows other developers to rightfully annotate classes, so others could safely consume/extend those. I agree, in an ideal world, being able to annotate existing classes would have been an awesome plan, and while that was the plan to some extent, it never for there. Hopefully I'll get back to it, or someone else will and make things better for other devs. was (Author: anshumg): [~marcussorealheis] - The idea behind this came from a branch that was shared by Mark, and while I was planning to pick a bunch of those changes to improve a few things in Solr, I didn't get the bandwidth to continue with this effort. I think the idea here is to have an option that allows to annotate classes in Solr w.r.t. threadsafety. While retrofitting that might be tricky, it can certainly be used for new classes. This mechanism allows other developers to rightfully annotate classes, so others could safely consume/extend those. I agree, in an ideal world, being able to annotate existing classes would have been an awesome plan, and while that was the plan to some extent, it never for there. Hopefully I'll get back to it, or someone else will and make things better for other devs. > Add thread safety annotation to classes > --- > > Key: SOLR-13998 > URL: https://issues.apache.org/jira/browse/SOLR-13998 > Project: Solr > Issue Type: Improvement >Reporter: Anshum Gupta >Assignee: Anshum Gupta >Priority: Major > Fix For: master (9.0), 8.4 > > Time Spent: 1.5h > Remaining Estimate: 0h > > Add annotations that can be used to mark classes as thread safe / single > threaded in Solr. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-13998) Add thread safety annotation to classes
[ https://issues.apache.org/jira/browse/SOLR-13998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17176075#comment-17176075 ] Anshum Gupta commented on SOLR-13998: - [~marcussorealheis] - The idea behind this came from a branch that was shared by Mark, and while I was planning to pick a bunch of those changes to improve a few things in Solr, I didn't get the bandwidth to continue with this effort. I think the idea here is to have an option that allows to annotate classes in Solr w.r.t. threadsafety. While retrofitting that might be tricky, it can certainly be used for new classes. This mechanism allows other developers to rightfully annotate classes, so others could safely consume/extend those. I agree, in an ideal world, being able to annotate existing classes would have been an awesome plan, and while that was the plan to some extent, it never for there. Hopefully I'll get back to it, or someone else will and make things better for other devs. > Add thread safety annotation to classes > --- > > Key: SOLR-13998 > URL: https://issues.apache.org/jira/browse/SOLR-13998 > Project: Solr > Issue Type: Improvement >Reporter: Anshum Gupta >Assignee: Anshum Gupta >Priority: Major > Fix For: master (9.0), 8.4 > > Time Spent: 1.5h > Remaining Estimate: 0h > > Add annotations that can be used to mark classes as thread safe / single > threaded in Solr. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14616) Remove CDCR from 9.0
[ https://issues.apache.org/jira/browse/SOLR-14616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17153076#comment-17153076 ] Anshum Gupta commented on SOLR-14616: - We can always remove the code in 9.1. That way we maintain the back-compat, allow people to upgrade to 9.0 without losing any features, and then remove the already deprecated features in the new release. That will also give us time to come up with alternate options. > Remove CDCR from 9.0 > > > Key: SOLR-14616 > URL: https://issues.apache.org/jira/browse/SOLR-14616 > Project: Solr > Issue Type: Sub-task >Affects Versions: master (9.0) >Reporter: Ishan Chattopadhyaya >Assignee: Ishan Chattopadhyaya >Priority: Blocker > Time Spent: 20m > Remaining Estimate: 0h > > This was deprecated in SOLR-14022 and should be removed in 9.0. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14616) Remove CDCR from 9.0
[ https://issues.apache.org/jira/browse/SOLR-14616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17153063#comment-17153063 ] Anshum Gupta commented on SOLR-14616: - +1 [~tflobbe] I don't think we should rush into removing stuff even if it's broken. There are ways people are currently using it, and this is too short a notice for them to move off and find another way of solving this problem. Whatever alternate we come up with, should be allowed to bake and not release for mainstream consumption too. Removing this, would not allow us to do that. > Remove CDCR from 9.0 > > > Key: SOLR-14616 > URL: https://issues.apache.org/jira/browse/SOLR-14616 > Project: Solr > Issue Type: Sub-task >Affects Versions: master (9.0) >Reporter: Ishan Chattopadhyaya >Assignee: Ishan Chattopadhyaya >Priority: Blocker > Time Spent: 20m > Remaining Estimate: 0h > > This was deprecated in SOLR-14022 and should be removed in 9.0. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14497) Move the project to become Apache TLP
[ https://issues.apache.org/jira/browse/SOLR-14497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17118451#comment-17118451 ] Anshum Gupta commented on SOLR-14497: - I'm +1 with [~uschindler] on this. Let's more slow but steadily towards the end goal. I think we might need to officially tell the board about the proposal to split, and then take it from there. I don't think a new project can be created without board approval. If someone has better idea on the rules here, please let me know and I can send out the email. > Move the project to become Apache TLP > - > > Key: SOLR-14497 > URL: https://issues.apache.org/jira/browse/SOLR-14497 > Project: Solr > Issue Type: Task >Reporter: Dawid Weiss >Priority: Major > > This issue is about the process of moving Solr to become an Apache TLP. > Se > [https://cwiki.apache.org/confluence/display/LUCENE/Solr+TLP+needed+changes] > for a tabular view of possible changes. > *TODO*: Add sub tasks. > h4. Preparation > # Figure out formal steps to be taken with Apache Board to set up TLP > project for Solr. > # Figure out the initial committership, PMC members, chair. > # Separate the code (and build) from Lucene so that Solr can be built > independently. This applies to 8.x and master (9.x). > # Determine what happens with mailing lists (and their archives). Are new > mailing lists going to be set up or the existing ones aliased somehow? > # Determine what happens with CI and build servers. > # Determine how to split web site > # [add more here] > h4. Execution > # Code: clone Lucene/Solr git to Solr TLP, add a TLP marking tag. > # Web Site: clone lucene/solr-site Git Repo, add a TLP marking tag > # Send an information about any potential mailing list changes, etc. to > previous addresses. > # Add redirects from old Solr site/ javadoc/ any other addresses to TLP > locations. > # [add more here] > h4. Post-transition > # Proceed with LUCENE-9375. > # [add more here] -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-13289) Support for BlockMax WAND
[
https://issues.apache.org/jira/browse/SOLR-13289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17104977#comment-17104977
]
Anshum Gupta commented on SOLR-13289:
-
I think {{minExactCount}} sounds the best here. It's explanatory but not super
verbose.
I'm personally not a huge fan of very long parameter names.
> Support for BlockMax WAND
> -
>
> Key: SOLR-13289
> URL: https://issues.apache.org/jira/browse/SOLR-13289
> Project: Solr
> Issue Type: New Feature
>Reporter: Ishan Chattopadhyaya
>Assignee: Tomas Eduardo Fernandez Lobbe
>Priority: Major
> Attachments: SOLR-13289.patch, SOLR-13289.patch
>
> Time Spent: 3h 40m
> Remaining Estimate: 0h
>
> LUCENE-8135 introduced BlockMax WAND as a major speed improvement. Need to
> expose this via Solr. When enabled, the numFound returned will not be exact.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-13289) Support for BlockMax WAND
[
https://issues.apache.org/jira/browse/SOLR-13289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17097234#comment-17097234
]
Anshum Gupta commented on SOLR-13289:
-
I'm still reviewing the PR but wanted to weigh in on the use of the term
{{precision}}. I don't have something I strongly feel about but how about how
about \{{numFoundApproximation}} might be a better term.
If I can think of something better while I review this tomorrow, I'll share in
the feedback.
> Support for BlockMax WAND
> -
>
> Key: SOLR-13289
> URL: https://issues.apache.org/jira/browse/SOLR-13289
> Project: Solr
> Issue Type: New Feature
>Reporter: Ishan Chattopadhyaya
>Assignee: Tomas Eduardo Fernandez Lobbe
>Priority: Major
> Attachments: SOLR-13289.patch, SOLR-13289.patch
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> LUCENE-8135 introduced BlockMax WAND as a major speed improvement. Need to
> expose this via Solr. When enabled, the numFound returned will not be exact.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14259) backport SOLR-14013 to Solr 7.7
[ https://issues.apache.org/jira/browse/SOLR-14259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17089150#comment-17089150 ] Anshum Gupta commented on SOLR-14259: - I really think we should never back port commits to release branches without them going through master and corresponding stable branches - of course, unless it is impossible to do so. > backport SOLR-14013 to Solr 7.7 > --- > > Key: SOLR-14259 > URL: https://issues.apache.org/jira/browse/SOLR-14259 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 7.7 >Reporter: Noble Paul >Assignee: Noble Paul >Priority: Major > Fix For: 7.7.3 > > Time Spent: 40m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-14265) Move collections admin API to v2 completely
[ https://issues.apache.org/jira/browse/SOLR-14265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anshum Gupta updated SOLR-14265: Summary: Move collections admin API to v2 completely (was: Move to admin API to v2 completely ) > Move collections admin API to v2 completely > > > Key: SOLR-14265 > URL: https://issues.apache.org/jira/browse/SOLR-14265 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Anshum Gupta >Assignee: Anshum Gupta >Priority: Major > > V2 admin API has been available in Solr for a very long time, making it > difficult for both users and developers to remember and understand which > format to use when. We should move to v2 API completely for all Solr Admin > calls for the following reasons: > # converge code - there are multiple ways of doing the same thing, there's > unwanted back-compat code, and we should get rid of that > # POJO all the way - no more NamedList. I know this would have split > opinions, but I strongly think we should move in this direction. I created > Jira about this specific task in the past and went half way but I think we > should just close this one out now. > # Automatic documentation > # Others > This is just an umbrella Jira for the task. Let's create sub-tasks and split > this up as it would require a bunch of rewriting of the code and it makes a > lot of sense to get this out with 9.0 so we don't have to support v1 forever! > There have been some conversations going on about this and it feels like most > folks are happy to go this route. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14265) Move to admin API to v2 completely
[ https://issues.apache.org/jira/browse/SOLR-14265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17056226#comment-17056226 ] Anshum Gupta commented on SOLR-14265: - Great idea, Cassandra! I was kind of doing that in addition to working through and understanding how the new API is structured. There are more than one ways the v2 stuff is written so trying to converge on the best option there too. Having a list of all the endpoints that we want to support with v2 would be great, and then I plan on moving those APIs over one after the other. If you already have a document or writeup on that mapping/accounting, please feel free to share and that would be a great anchor for this. > Move to admin API to v2 completely > --- > > Key: SOLR-14265 > URL: https://issues.apache.org/jira/browse/SOLR-14265 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Anshum Gupta >Assignee: Anshum Gupta >Priority: Major > > V2 admin API has been available in Solr for a very long time, making it > difficult for both users and developers to remember and understand which > format to use when. We should move to v2 API completely for all Solr Admin > calls for the following reasons: > # converge code - there are multiple ways of doing the same thing, there's > unwanted back-compat code, and we should get rid of that > # POJO all the way - no more NamedList. I know this would have split > opinions, but I strongly think we should move in this direction. I created > Jira about this specific task in the past and went half way but I think we > should just close this one out now. > # Automatic documentation > # Others > This is just an umbrella Jira for the task. Let's create sub-tasks and split > this up as it would require a bunch of rewriting of the code and it makes a > lot of sense to get this out with 9.0 so we don't have to support v1 forever! > There have been some conversations going on about this and it feels like most > folks are happy to go this route. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14216) Exclude HealthCheck from authentication
[
https://issues.apache.org/jira/browse/SOLR-14216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17044758#comment-17044758
]
Anshum Gupta commented on SOLR-14216:
-
I'm still not convinced about opening up the response to "is this node healthy"
to the outside world if auth is enabled. This is just coming from my experience
with security folks (I'm not there yet, no plans either).
I like the idea of documenting this well, and supporting some mechanism that
makes it easy to open up endpoints for such purposes.
> Exclude HealthCheck from authentication
> ---
>
> Key: SOLR-14216
> URL: https://issues.apache.org/jira/browse/SOLR-14216
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Authentication
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The {{HealthCheckHandler}} on {{/api/node/health}} and
> {{/solr/admin/info/health}} should by default not be subject to
> authentication, but be open for all. This allows for load balancers and
> various monitoring to probe Solr's health without having to support the auth
> scheme in place. I can't see any reason we need auth on the health endpoint.
> It is possible to achieve the same by setting blockUnknown=false and
> configuring three RBAC permissions: One for v1 endpoint, one for v2 endpoint
> and one "all" catch all at the end of the chain. But this is cumbersome so
> better have this ootb.
> An alternative solution is to create a separate HttpServer for health check,
> listening on a different port, just like embedded ZK and JMX.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Resolved] (SOLR-14271) Remove duplicate async id check meant for pre Solr 8 versions
[ https://issues.apache.org/jira/browse/SOLR-14271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anshum Gupta resolved SOLR-14271. - Resolution: Fixed Fixed the test. > Remove duplicate async id check meant for pre Solr 8 versions > - > > Key: SOLR-14271 > URL: https://issues.apache.org/jira/browse/SOLR-14271 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Anshum Gupta >Assignee: Anshum Gupta >Priority: Major > Fix For: master (9.0) > > Time Spent: 1h > Remaining Estimate: 0h > > SOLR-11739 changed the way the async IDs are checked for duplicates. For > backward compatibility, we continued to check for duplicates the old way too. > This should be removed in Solr 9. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Resolved] (SOLR-14272) Remove autoReplicaFailoverBadNodeExpiration and autoReplicaFailoverWorkLoopDelay for 9.0 as it was deprecated in 7.1
[ https://issues.apache.org/jira/browse/SOLR-14272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anshum Gupta resolved SOLR-14272. - Resolution: Fixed > Remove autoReplicaFailoverBadNodeExpiration and > autoReplicaFailoverWorkLoopDelay for 9.0 as it was deprecated in 7.1 > > > Key: SOLR-14272 > URL: https://issues.apache.org/jira/browse/SOLR-14272 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Anshum Gupta >Assignee: Anshum Gupta >Priority: Major > Fix For: master (9.0) > > Time Spent: 10m > Remaining Estimate: 0h > > 'autoReplicaFailoverBadNodeExpiration' and 'autoReplicaFailoverWorkLoopDelay' > parameters were deprecated in 7.1 after the 'autoAddReplicas' feature was > ported to autoscaling. > We should remove them from the code to get rid of the cruft. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14271) Remove duplicate async id check meant for pre Solr 8 versions
[ https://issues.apache.org/jira/browse/SOLR-14271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17042058#comment-17042058 ] Anshum Gupta commented on SOLR-14271: - Totally missed that. No idea how/why the test passed for me but thanks for bringing this up. Fix on the way! > Remove duplicate async id check meant for pre Solr 8 versions > - > > Key: SOLR-14271 > URL: https://issues.apache.org/jira/browse/SOLR-14271 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Anshum Gupta >Assignee: Anshum Gupta >Priority: Major > Fix For: master (9.0) > > Time Spent: 40m > Remaining Estimate: 0h > > SOLR-11739 changed the way the async IDs are checked for duplicates. For > backward compatibility, we continued to check for duplicates the old way too. > This should be removed in Solr 9. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Reopened] (SOLR-14271) Remove duplicate async id check meant for pre Solr 8 versions
[ https://issues.apache.org/jira/browse/SOLR-14271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anshum Gupta reopened SOLR-14271: - Reopening to fix the failing test. > Remove duplicate async id check meant for pre Solr 8 versions > - > > Key: SOLR-14271 > URL: https://issues.apache.org/jira/browse/SOLR-14271 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Anshum Gupta >Assignee: Anshum Gupta >Priority: Major > Fix For: master (9.0) > > Time Spent: 40m > Remaining Estimate: 0h > > SOLR-11739 changed the way the async IDs are checked for duplicates. For > backward compatibility, we continued to check for duplicates the old way too. > This should be removed in Solr 9. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14216) Exclude HealthCheck from authentication
[
https://issues.apache.org/jira/browse/SOLR-14216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17041365#comment-17041365
]
Anshum Gupta commented on SOLR-14216:
-
[~janhoy] - I'm not convinced that the health check handlers should escape auth
completely. This endpoint reflects the actual state of the Solr instance. The
last I checked, we only bypass auth for static content i.e. that doesn't change
ever and is available on the internet.
I completely agree that we should consolidate and not check for bypassing auth
in 3 different places but that's another JIRA.
> Exclude HealthCheck from authentication
> ---
>
> Key: SOLR-14216
> URL: https://issues.apache.org/jira/browse/SOLR-14216
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Authentication
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The {{HealthCheckHandler}} on {{/api/node/health}} and
> {{/solr/admin/info/health}} should by default not be subject to
> authentication, but be open for all. This allows for load balancers and
> various monitoring to probe Solr's health without having to support the auth
> scheme in place. I can't see any reason we need auth on the health endpoint.
> It is possible to achieve the same by setting blockUnknown=false and
> configuring three RBAC permissions: One for v1 endpoint, one for v2 endpoint
> and one "all" catch all at the end of the chain. But this is cumbersome so
> better have this ootb.
> An alternative solution is to create a separate HttpServer for health check,
> listening on a different port, just like embedded ZK and JMX.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-14271) Remove duplicate async id check meant for pre Solr 8 versions
[ https://issues.apache.org/jira/browse/SOLR-14271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anshum Gupta updated SOLR-14271: Fix Version/s: master (9.0) > Remove duplicate async id check meant for pre Solr 8 versions > - > > Key: SOLR-14271 > URL: https://issues.apache.org/jira/browse/SOLR-14271 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Anshum Gupta >Assignee: Anshum Gupta >Priority: Major > Fix For: master (9.0) > > Time Spent: 40m > Remaining Estimate: 0h > > SOLR-11739 changed the way the async IDs are checked for duplicates. For > backward compatibility, we continued to check for duplicates the old way too. > This should be removed in Solr 9. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Resolved] (SOLR-14271) Remove duplicate async id check meant for pre Solr 8 versions
[ https://issues.apache.org/jira/browse/SOLR-14271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anshum Gupta resolved SOLR-14271. - Resolution: Fixed > Remove duplicate async id check meant for pre Solr 8 versions > - > > Key: SOLR-14271 > URL: https://issues.apache.org/jira/browse/SOLR-14271 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Anshum Gupta >Assignee: Anshum Gupta >Priority: Major > Fix For: master (9.0) > > Time Spent: 40m > Remaining Estimate: 0h > > SOLR-11739 changed the way the async IDs are checked for duplicates. For > backward compatibility, we continued to check for duplicates the old way too. > This should be removed in Solr 9. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Created] (SOLR-14272) Remove autoReplicaFailoverBadNodeExpiration and autoReplicaFailoverWorkLoopDelay for 9.0 as it was deprecated in 7.1
Anshum Gupta created SOLR-14272: --- Summary: Remove autoReplicaFailoverBadNodeExpiration and autoReplicaFailoverWorkLoopDelay for 9.0 as it was deprecated in 7.1 Key: SOLR-14272 URL: https://issues.apache.org/jira/browse/SOLR-14272 Project: Solr Issue Type: Improvement Security Level: Public (Default Security Level. Issues are Public) Reporter: Anshum Gupta Assignee: Anshum Gupta Fix For: master (9.0) 'autoReplicaFailoverBadNodeExpiration' and 'autoReplicaFailoverWorkLoopDelay' parameters were deprecated in 7.1 after the 'autoAddReplicas' feature was ported to autoscaling. We should remove them from the code to get rid of the cruft. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Created] (SOLR-14271) Remove duplicate async id check meant for pre Solr 8 versions
Anshum Gupta created SOLR-14271: --- Summary: Remove duplicate async id check meant for pre Solr 8 versions Key: SOLR-14271 URL: https://issues.apache.org/jira/browse/SOLR-14271 Project: Solr Issue Type: Improvement Security Level: Public (Default Security Level. Issues are Public) Reporter: Anshum Gupta Assignee: Anshum Gupta SOLR-11739 changed the way the async IDs are checked for duplicates. For backward compatibility, we continued to check for duplicates the old way too. This should be removed in Solr 9. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Created] (SOLR-14265) Move to admin API to v2 completely
Anshum Gupta created SOLR-14265: --- Summary: Move to admin API to v2 completely Key: SOLR-14265 URL: https://issues.apache.org/jira/browse/SOLR-14265 Project: Solr Issue Type: Improvement Security Level: Public (Default Security Level. Issues are Public) Reporter: Anshum Gupta Assignee: Anshum Gupta V2 admin API has been available in Solr for a very long time, making it difficult for both users and developers to remember and understand which format to use when. We should move to v2 API completely for all Solr Admin calls for the following reasons: # converge code - there are multiple ways of doing the same thing, there's unwanted back-compat code, and we should get rid of that # POJO all the way - no more NamedList. I know this would have split opinions, but I strongly think we should move in this direction. I created Jira about this specific task in the past and went half way but I think we should just close this one out now. # Automatic documentation # Others This is just an umbrella Jira for the task. Let's create sub-tasks and split this up as it would require a bunch of rewriting of the code and it makes a lot of sense to get this out with 9.0 so we don't have to support v1 forever! There have been some conversations going on about this and it feels like most folks are happy to go this route. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9146) Switch GitHub PR test from ant precommit to gradle
[ https://issues.apache.org/jira/browse/LUCENE-9146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17032734#comment-17032734 ] Anshum Gupta commented on LUCENE-9146: -- Merged into master. > Switch GitHub PR test from ant precommit to gradle > -- > > Key: LUCENE-9146 > URL: https://issues.apache.org/jira/browse/LUCENE-9146 > Project: Lucene - Core > Issue Type: Sub-task >Reporter: Mike Drob >Assignee: Anshum Gupta >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9146) Switch GitHub PR test from ant precommit to gradle
[ https://issues.apache.org/jira/browse/LUCENE-9146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17032717#comment-17032717 ] Anshum Gupta commented on LUCENE-9146: -- https://github.com/apache/lucene-solr/pull/1245 > Switch GitHub PR test from ant precommit to gradle > -- > > Key: LUCENE-9146 > URL: https://issues.apache.org/jira/browse/LUCENE-9146 > Project: Lucene - Core > Issue Type: Sub-task >Reporter: Mike Drob >Assignee: Anshum Gupta >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Assigned] (LUCENE-9146) Switch GitHub PR test from ant precommit to gradle
[ https://issues.apache.org/jira/browse/LUCENE-9146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anshum Gupta reassigned LUCENE-9146: Assignee: Anshum Gupta > Switch GitHub PR test from ant precommit to gradle > -- > > Key: LUCENE-9146 > URL: https://issues.apache.org/jira/browse/LUCENE-9146 > Project: Lucene - Core > Issue Type: Sub-task >Reporter: Mike Drob >Assignee: Anshum Gupta >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9146) Switch GitHub PR test from ant precommit to gradle
[ https://issues.apache.org/jira/browse/LUCENE-9146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17029683#comment-17029683 ] Anshum Gupta commented on LUCENE-9146: -- Yes. I think it makes sense to leave the ant variant where it is and add the gradle version for a couple of minor releases, or until 9 (whatever is sooner). It doesn't cost anything and would just run in parallel. > Switch GitHub PR test from ant precommit to gradle > -- > > Key: LUCENE-9146 > URL: https://issues.apache.org/jira/browse/LUCENE-9146 > Project: Lucene - Core > Issue Type: Sub-task >Reporter: Mike Drob >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Issue Comment Deleted] (SOLR-11960) Add collection level properties
[ https://issues.apache.org/jira/browse/SOLR-11960?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anshum Gupta updated SOLR-11960: Comment: was deleted (was: Togelrakyat adalah [Daftar Togel|http://www.togelrakyat.host/] Online server [Dewatogel|http://94.237.77.123/] singapura , Hongkong dan Daftar live casino online baccarat , roulette terpercaya terbesar di asia terbesar dan live casino baccarat, roulette. indo togel Sydney, Cambodia, Jakarta , Sing45 toto macau, China Pools, Bullseye, Saigon toto, Pcso. Kualitas dari agen judi online togelrakyat tidak usah diragukan lagi, agen togel terpercaya komunitas SGP HK terbesar di Indonesia. Bermain di togelrakyat adalah pilihan yang tepat bagi para pecinta judi online di Indonesia. Kenyamanan, Keamanan dan Kepuasan pemain merupakan kewajiban togelrakyat sebagai agen / website pasang singapore terbaik dan [Nonton Anime|https://diaboros.blogspot.com/] di Indonesia.) > Add collection level properties > --- > > Key: SOLR-11960 > URL: https://issues.apache.org/jira/browse/SOLR-11960 > Project: Solr > Issue Type: New Feature >Reporter: Peter Rusko >Assignee: Tomas Eduardo Fernandez Lobbe >Priority: Blocker > Fix For: 7.3, 8.0 > > Attachments: SOLR-11960.patch, SOLR-11960.patch, SOLR-11960.patch, > SOLR-11960.patch, SOLR-11960.patch, SOLR-11960_2.patch > > > Solr has cluster properties, but no easy and extendable way of defining > properties that affect a single collection. Collection properties could be > stored in a single zookeeper node per collection, making it possible to > trigger zookeeper watchers for only those Solr nodes that have cores of that > collection. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9198) Remove news section from TLP website
[ https://issues.apache.org/jira/browse/LUCENE-9198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17027692#comment-17027692 ] Anshum Gupta commented on LUCENE-9198: -- +1 > Remove news section from TLP website > > > Key: LUCENE-9198 > URL: https://issues.apache.org/jira/browse/LUCENE-9198 > Project: Lucene - Core > Issue Type: Improvement > Components: general/website >Reporter: Jan Høydahl >Priority: Major > > On the front page [https://lucene.apache.org|https://lucene.apache.org/] we > today show a list of TLP news. > For every release we author one news article for Solr, one news article for > LuceneCore, and one news article for TLP site, combining the two. > In all these years we have never published a news item to TLP that is not a > release announcement, except in 2014 when we announced that OpenRelevance sub > project closed. > I thus propose to remove this news section, and replace it with two widgets > that automatically display the last 5 news headings from LuceneCore, Solr and > PyLucene sub projects. > If we have an important TLP announcement to make at some point, that can be > done right there on the front page, not? -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14206) Annotate classes for thread safety
[ https://issues.apache.org/jira/browse/SOLR-14206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17021427#comment-17021427 ] Anshum Gupta commented on SOLR-14206: - I don't think we need a new JIRA for each class, so will keep this open and continue adding annotations. I personally feel we don't need changelog entry for each of the commits. Feel free to speak up if you think otherwise. > Annotate classes for thread safety > -- > > Key: SOLR-14206 > URL: https://issues.apache.org/jira/browse/SOLR-14206 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Anshum Gupta >Assignee: Anshum Gupta >Priority: Major > > We added options to annotate classes. I'll start to annotate classes that we > know are already thread safe (or not). -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Created] (SOLR-14206) Annotate classes for thread safety
Anshum Gupta created SOLR-14206: --- Summary: Annotate classes for thread safety Key: SOLR-14206 URL: https://issues.apache.org/jira/browse/SOLR-14206 Project: Solr Issue Type: Improvement Security Level: Public (Default Security Level. Issues are Public) Reporter: Anshum Gupta Assignee: Anshum Gupta We added options to annotate classes. I'll start to annotate classes that we know are already thread safe (or not). -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14095) Remove serialization and/or support serialization filtering
[ https://issues.apache.org/jira/browse/SOLR-14095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16999572#comment-16999572 ] Anshum Gupta commented on SOLR-14095: - Thanks for doing this, Tomás. The responses here so unpredictable, that I think it makes sense to just to the basic work right now until we fix the responses themselves. For the purpose of security, I would recommend going with the Javabin approach for now. > Remove serialization and/or support serialization filtering > --- > > Key: SOLR-14095 > URL: https://issues.apache.org/jira/browse/SOLR-14095 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Robert Muir >Priority: Major > Attachments: SOLR-14095-json.patch > > Time Spent: 1h > Remaining Estimate: 0h > > Removing the use of serialization is greatly preferred. > But if serialization over the wire must really happen, then we must use JDK's > serialization filtering capability to prevent havoc. > https://docs.oracle.com/javase/10/core/serialization-filtering1.htm#JSCOR-GUID-3ECB288D-E5BD-4412-892F-E9BB11D4C98A -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14067) Deprecate StatelessScriptUpdateProcessor and disabled by default
[ https://issues.apache.org/jira/browse/SOLR-14067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16998527#comment-16998527 ] Anshum Gupta commented on SOLR-14067: - +1 on the direction in which this is going. SSUP is just scary in every way for users who don't understand it's implications, as well as for people who download and run Solr as is i.e. without disabling this. > Deprecate StatelessScriptUpdateProcessor and disabled by default > > > Key: SOLR-14067 > URL: https://issues.apache.org/jira/browse/SOLR-14067 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Ishan Chattopadhyaya >Priority: Blocker > Fix For: 8.4 > > Time Spent: 10m > Remaining Estimate: 0h > > We should eliminate all scripting capabilities within Solr. Let us start with > the StatelessScriptUpdateProcessor deprecation/removal. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-13990) Switch out woodstox-core-asl with aalto-xml and upgrade woodstox stax-2 API
[
https://issues.apache.org/jira/browse/SOLR-13990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16990818#comment-16990818
]
Anshum Gupta commented on SOLR-13990:
-
Sorry everyone about being MIA and not tracking this down. Also, thanks for
reverting this.
I'm still reading all of this conversation here so catching up on what exactly
happened.
> Switch out woodstox-core-asl with aalto-xml and upgrade woodstox stax-2 API
> ---
>
> Key: SOLR-13990
> URL: https://issues.apache.org/jira/browse/SOLR-13990
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Anshum Gupta
>Assignee: Anshum Gupta
>Priority: Major
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> Switched out woodstox-core-asl with aalto-xml and upgrade woodstax stax-2
> API.
> About aalto-xml:
> Aalto XML processor is an ultra-high performance next generation Stax XML
> processor implementation, implementing both basic Stax API
> ({{javax.xml.stream}}) and Stax2 API extension
> ({{org.codehaus.woodstox.stax2}}). In addition, it also implements SAX2 API.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-13990) Switch out woodstox-core-asl with aalto-xml and upgrade woodstox stax-2 API
[
https://issues.apache.org/jira/browse/SOLR-13990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16987997#comment-16987997
]
Anshum Gupta commented on SOLR-13990:
-
Yes, my guess is that it was for Solr. The comment from [~hgadre] makes me
think so :)
The other justification is that is that Woodstox is more stable, which is true
but then Aalto is ~100% faster.
> Switch out woodstox-core-asl with aalto-xml and upgrade woodstox stax-2 API
> ---
>
> Key: SOLR-13990
> URL: https://issues.apache.org/jira/browse/SOLR-13990
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Anshum Gupta
>Assignee: Anshum Gupta
>Priority: Major
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Switched out woodstox-core-asl with aalto-xml and upgrade woodstax stax-2
> API.
> About aalto-xml:
> Aalto XML processor is an ultra-high performance next generation Stax XML
> processor implementation, implementing both basic Stax API
> ({{javax.xml.stream}}) and Stax2 API extension
> ({{org.codehaus.woodstox.stax2}}). In addition, it also implements SAX2 API.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Created] (SOLR-14005) Umbrella JIRA for adding class level thread safety annotations
Anshum Gupta created SOLR-14005: --- Summary: Umbrella JIRA for adding class level thread safety annotations Key: SOLR-14005 URL: https://issues.apache.org/jira/browse/SOLR-14005 Project: Solr Issue Type: Improvement Security Level: Public (Default Security Level. Issues are Public) Reporter: Anshum Gupta -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Resolved] (SOLR-13998) Add thread safety annotation to classes
[ https://issues.apache.org/jira/browse/SOLR-13998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anshum Gupta resolved SOLR-13998. - Resolution: Fixed > Add thread safety annotation to classes > --- > > Key: SOLR-13998 > URL: https://issues.apache.org/jira/browse/SOLR-13998 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Anshum Gupta >Assignee: Anshum Gupta >Priority: Major > Fix For: master (9.0), 8.4 > > Time Spent: 1.5h > Remaining Estimate: 0h > > Add annotations that can be used to mark classes as thread safe / single > threaded in Solr. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-13998) Add thread safety annotation to classes
[ https://issues.apache.org/jira/browse/SOLR-13998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16987582#comment-16987582 ] Anshum Gupta commented on SOLR-13998: - I'll create a new umbrella Jira for annotating specific classes. > Add thread safety annotation to classes > --- > > Key: SOLR-13998 > URL: https://issues.apache.org/jira/browse/SOLR-13998 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Anshum Gupta >Assignee: Anshum Gupta >Priority: Major > Fix For: master (9.0), 8.4 > > Time Spent: 1.5h > Remaining Estimate: 0h > > Add annotations that can be used to mark classes as thread safe / single > threaded in Solr. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-13998) Add thread safety annotation to classes
[ https://issues.apache.org/jira/browse/SOLR-13998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anshum Gupta updated SOLR-13998: Fix Version/s: 8.4 master (9.0) > Add thread safety annotation to classes > --- > > Key: SOLR-13998 > URL: https://issues.apache.org/jira/browse/SOLR-13998 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Anshum Gupta >Assignee: Anshum Gupta >Priority: Major > Fix For: master (9.0), 8.4 > > Time Spent: 1.5h > Remaining Estimate: 0h > > Add annotations that can be used to mark classes as thread safe / single > threaded in Solr. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-13998) Add thread safety annotation to classes
[ https://issues.apache.org/jira/browse/SOLR-13998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anshum Gupta updated SOLR-13998: Summary: Add thread safety annotation to classes (was: Add thread safe annotation to classes) > Add thread safety annotation to classes > --- > > Key: SOLR-13998 > URL: https://issues.apache.org/jira/browse/SOLR-13998 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Anshum Gupta >Assignee: Anshum Gupta >Priority: Major > > Add annotations that can be used to mark classes as thread safe / single > threaded in Solr. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Created] (SOLR-13998) Add thread safe annotation to classes
Anshum Gupta created SOLR-13998: --- Summary: Add thread safe annotation to classes Key: SOLR-13998 URL: https://issues.apache.org/jira/browse/SOLR-13998 Project: Solr Issue Type: Improvement Security Level: Public (Default Security Level. Issues are Public) Reporter: Anshum Gupta Assignee: Anshum Gupta Add annotations that can be used to mark classes as thread safe / single threaded in Solr. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-13990) Switch out woodstox-core-asl with aalto-xml and upgrade woodstox stax-2 API
[
https://issues.apache.org/jira/browse/SOLR-13990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16986052#comment-16986052
]
Anshum Gupta commented on SOLR-13990:
-
This is missing the sha1 checksum files for the changed/new dependencies. I'll
add those.
> Switch out woodstox-core-asl with aalto-xml and upgrade woodstox stax-2 API
> ---
>
> Key: SOLR-13990
> URL: https://issues.apache.org/jira/browse/SOLR-13990
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Anshum Gupta
>Assignee: Anshum Gupta
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Switched out woodstox-core-asl with aalto-xml and upgrade woodstax stax-2
> API.
> About aalto-xml:
> Aalto XML processor is an ultra-high performance next generation Stax XML
> processor implementation, implementing both basic Stax API
> ({{javax.xml.stream}}) and Stax2 API extension
> ({{org.codehaus.woodstox.stax2}}). In addition, it also implements SAX2 API.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Created] (SOLR-13990) Switch out woodstox-core-asl with aalto-xml and upgrade woodstox stax-2 API
Anshum Gupta created SOLR-13990:
---
Summary: Switch out woodstox-core-asl with aalto-xml and upgrade
woodstox stax-2 API
Key: SOLR-13990
URL: https://issues.apache.org/jira/browse/SOLR-13990
Project: Solr
Issue Type: Improvement
Security Level: Public (Default Security Level. Issues are Public)
Reporter: Anshum Gupta
Assignee: Anshum Gupta
Switched out woodstox-core-asl with aalto-xml and upgrade woodstax stax-2 API.
About aalto-xml:
Aalto XML processor is an ultra-high performance next generation Stax XML
processor implementation, implementing both basic Stax API
({{javax.xml.stream}}) and Stax2 API extension
({{org.codehaus.woodstox.stax2}}). In addition, it also implements SAX2 API.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-13942) /api/cluster/zk/* to fetch raw ZK data
[ https://issues.apache.org/jira/browse/SOLR-13942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16977347#comment-16977347 ] Anshum Gupta commented on SOLR-13942: - Seems like I missed something here, but I'll wait for you to clarify. > /api/cluster/zk/* to fetch raw ZK data > -- > > Key: SOLR-13942 > URL: https://issues.apache.org/jira/browse/SOLR-13942 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Noble Paul >Priority: Major > > If the requested path is a node with children show the list of child nodes > and their meta data -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-13942) /api/cluster/zk/* to fetch raw ZK data
[ https://issues.apache.org/jira/browse/SOLR-13942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16977343#comment-16977343 ] Anshum Gupta commented on SOLR-13942: - If I have the correct understanding here, this is really scary and gives users a very easy way to shoot themselves in the foot. Also, this exposes the "zookeeper" bit as a public API and relies on things like - zk paths being guaranteed to not change. ZK paths should be implementation details and users shouldn't have anything to do with those. The cluster state, overseer status APIs are what still make sense, but this raw API doesn't sound right to me. > /api/cluster/zk/* to fetch raw ZK data > -- > > Key: SOLR-13942 > URL: https://issues.apache.org/jira/browse/SOLR-13942 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Noble Paul >Priority: Major > > If the requested path is a node with children show the list of child nodes > and their meta data -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-13797) SolrResourceLoader produces inconsistent results when given bad arguments
[
https://issues.apache.org/jira/browse/SOLR-13797?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16943033#comment-16943033
]
Anshum Gupta commented on SOLR-13797:
-
[~mdrob] - LGTM.
Just a minor question/suggestion. Can you also annotate clearCache w/
@VisibleForTesting ?
> SolrResourceLoader produces inconsistent results when given bad arguments
> -
>
> Key: SOLR-13797
> URL: https://issues.apache.org/jira/browse/SOLR-13797
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 7.7.2, 8.2
>Reporter: Mike Drob
>Assignee: Mike Drob
>Priority: Major
> Attachments: SOLR-13797.v1.patch, SOLR-13797.v2.patch
>
>
> SolrResourceLoader will attempt to do some magic to infer what the user
> wanted when loading TokenFilter and Tokenizer classes. However, this can end
> up putting the wrong class in the cache such that the request succeeds the
> first time but fails subsequent times. It should either succeed or fail
> consistently on every call.
> This can be triggered in a variety of ways, but the simplest is maybe by
> specifying the wrong element type in an indexing chain. Consider the field
> type definition:
> {code:xml}
>
>
>
> maxGramSize="2"/>
>
>
> {code}
> If loaded by itself (e.g. docker container for standalone validation) then
> the schema will pass and collection will succeed, with Solr actually figuring
> out that it needs an {{NGramTokenFilterFactory}}. However, if this is loaded
> on a cluster with other collections where the {{NGramTokenizerFactory}} has
> been loaded correctly then we get {{ClassCastException}}. Or if this
> collection is loaded first then others using the Tokenizer will fail instead.
> I'd argue that succeeding on both calls is the better approach because it
> does what the user likely wants instead of what the user explicitly asks for,
> and creates a nicer user experience that is marginally less pedantic.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (LUCENE-8984) MoreLikeThis MLT is biased for uncommon fields
[
https://issues.apache.org/jira/browse/LUCENE-8984?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anshum Gupta updated LUCENE-8984:
-
Lucene Fields: (was: New,Patch Available)
Resolution: Fixed
Status: Resolved (was: Patch Available)
> MoreLikeThis MLT is biased for uncommon fields
> --
>
> Key: LUCENE-8984
> URL: https://issues.apache.org/jira/browse/LUCENE-8984
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Andy Hind
>Assignee: Anshum Gupta
>Priority: Major
> Fix For: master (9.0), 8.3
>
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> MLT always uses the total doc count and not the count of docs with the
> specific field
>
> To quote Maria Mestre from the discussion on the mailing list - 29/01/19
>
> {quote}The issue I have is that when retrieving the key scored terms
> (interestingTerms), the code uses the total number of documents in the index,
> not the total number of documents with populated “description” field. This is
> where it’s done in the code:
> [https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_apache_lucene-2Dsolr_blob_master_lucene_queries_src_java_org_apache_lucene_queries_mlt_MoreLikeThis.java-23L651&d=DwIFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=XIYHWqjoenB2nuyYPl8m6c5xBIOD8PZJ4CWx0j6tQjA&m=gYOyL1Msgk2dpzigOsIvXq3CiFF0T7ApMLBVVDKW2dQ&s=v4mgEvgP3HWtMZcL3FTiKeY2nBOPJpTypmCpCBwPkQs&e=]
> The effect of this choice is that the “idf” does not vary much, given that
> numDocs >> number of documents with “description”, so the key terms end up
> being just the terms with the highest term frequencies.
> It is inconsistent because the MLT-search then uses these extracted key terms
> and scores all documents using an idf which is computed only on the subset of
> documents with “description”. So one part of the MLT uses a different numDocs
> than another part. This sounds like an odd choice, and not expected at all,
> and I wonder if I’m missing something.
> {quote}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (LUCENE-8984) MoreLikeThis MLT is biased for uncommon fields
[
https://issues.apache.org/jira/browse/LUCENE-8984?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anshum Gupta updated LUCENE-8984:
-
Fix Version/s: 8.3
> MoreLikeThis MLT is biased for uncommon fields
> --
>
> Key: LUCENE-8984
> URL: https://issues.apache.org/jira/browse/LUCENE-8984
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Andy Hind
>Assignee: Anshum Gupta
>Priority: Major
> Fix For: master (9.0), 8.3
>
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> MLT always uses the total doc count and not the count of docs with the
> specific field
>
> To quote Maria Mestre from the discussion on the mailing list - 29/01/19
>
> {quote}The issue I have is that when retrieving the key scored terms
> (interestingTerms), the code uses the total number of documents in the index,
> not the total number of documents with populated “description” field. This is
> where it’s done in the code:
> [https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_apache_lucene-2Dsolr_blob_master_lucene_queries_src_java_org_apache_lucene_queries_mlt_MoreLikeThis.java-23L651&d=DwIFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=XIYHWqjoenB2nuyYPl8m6c5xBIOD8PZJ4CWx0j6tQjA&m=gYOyL1Msgk2dpzigOsIvXq3CiFF0T7ApMLBVVDKW2dQ&s=v4mgEvgP3HWtMZcL3FTiKeY2nBOPJpTypmCpCBwPkQs&e=]
> The effect of this choice is that the “idf” does not vary much, given that
> numDocs >> number of documents with “description”, so the key terms end up
> being just the terms with the highest term frequencies.
> It is inconsistent because the MLT-search then uses these extracted key terms
> and scores all documents using an idf which is computed only on the subset of
> documents with “description”. So one part of the MLT uses a different numDocs
> than another part. This sounds like an odd choice, and not expected at all,
> and I wonder if I’m missing something.
> {quote}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-13787) An annotation based system to write v2 only APIs
[
https://issues.apache.org/jira/browse/SOLR-13787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16937887#comment-16937887
]
Anshum Gupta commented on SOLR-13787:
-
[~noble.paul] - for the sake of clarity, can you add some more context the
annotations, as well as the spec file? If there's already a sample or document
available outside of this JIRA, a link would do.
Considering that the last time I took a look at and/or did anything with v2
APIs was a while ago, I feel this might be a little complicated for what you
are trying to accomplish. At the same time, I may be wrong here and some
documentation about the annotation/spec file would make things better w.r.t.
understanding this proposal.
> An annotation based system to write v2 only APIs
>
>
> Key: SOLR-13787
> URL: https://issues.apache.org/jira/browse/SOLR-13787
> Project: Solr
> Issue Type: Task
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
>
> example v2 API may look as follows
> {code:java}
> @EndPoint(
> spec = "cluster.package",
> method = POST,
> permission = PKG_EDIT
> )
> static class PkgEdit {
> @Command(name = "add")
> public void add(CallInfo callInfo) throws Exception {
> }
> @Command(name = "update")
> public void update(CallInfo callInfo) throws Exception {
> }
> @Command(name = "delete")
> boolean deletePackage(CallInfo params) throws Exception {
> }
> {code}
> This expects you to already have the API spec json
>
> The annotations are:
>
> {code:java}
> @Retention(RetentionPolicy.RUNTIME)
> @Target({ElementType.TYPE})
> public @interface EndPoint {
> /**name of the API spec file without the '.json' suffix
>*/
> String spec();
> /**Http method
>*/
> SolrRequest.METHOD method();
> /**The well known persmission name if any
>*/
> PermissionNameProvider.Name permission();
> }
> {code}
> {code:java}
> @Retention(RetentionPolicy.RUNTIME)
> @Target(ElementType.METHOD)
> public @interface Command {
> String name() default "";
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8984) MoreLikeThis MLT is biased for uncommon fields
[
https://issues.apache.org/jira/browse/LUCENE-8984?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16937869#comment-16937869
]
Anshum Gupta commented on LUCENE-8984:
--
Thanks [~jim.ferenczi] for fixing the test and build!
I will backport both of these commits to 8x.
> MoreLikeThis MLT is biased for uncommon fields
> --
>
> Key: LUCENE-8984
> URL: https://issues.apache.org/jira/browse/LUCENE-8984
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Andy Hind
>Assignee: Anshum Gupta
>Priority: Major
> Fix For: master (9.0)
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> MLT always uses the total doc count and not the count of docs with the
> specific field
>
> To quote Maria Mestre from the discussion on the mailing list - 29/01/19
>
> {quote}The issue I have is that when retrieving the key scored terms
> (interestingTerms), the code uses the total number of documents in the index,
> not the total number of documents with populated “description” field. This is
> where it’s done in the code:
> [https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_apache_lucene-2Dsolr_blob_master_lucene_queries_src_java_org_apache_lucene_queries_mlt_MoreLikeThis.java-23L651&d=DwIFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=XIYHWqjoenB2nuyYPl8m6c5xBIOD8PZJ4CWx0j6tQjA&m=gYOyL1Msgk2dpzigOsIvXq3CiFF0T7ApMLBVVDKW2dQ&s=v4mgEvgP3HWtMZcL3FTiKeY2nBOPJpTypmCpCBwPkQs&e=]
> The effect of this choice is that the “idf” does not vary much, given that
> numDocs >> number of documents with “description”, so the key terms end up
> being just the terms with the highest term frequencies.
> It is inconsistent because the MLT-search then uses these extracted key terms
> and scores all documents using an idf which is computed only on the subset of
> documents with “description”. So one part of the MLT uses a different numDocs
> than another part. This sounds like an odd choice, and not expected at all,
> and I wonder if I’m missing something.
> {quote}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (LUCENE-8984) MoreLikeThis MLT is biased for uncommon fields
[
https://issues.apache.org/jira/browse/LUCENE-8984?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anshum Gupta updated LUCENE-8984:
-
Fix Version/s: (was: 8.3)
> MoreLikeThis MLT is biased for uncommon fields
> --
>
> Key: LUCENE-8984
> URL: https://issues.apache.org/jira/browse/LUCENE-8984
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Andy Hind
>Assignee: Anshum Gupta
>Priority: Major
> Fix For: master (9.0)
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> MLT always uses the total doc count and not the count of docs with the
> specific field
>
> To quote Maria Mestre from the discussion on the mailing list - 29/01/19
>
> {quote}The issue I have is that when retrieving the key scored terms
> (interestingTerms), the code uses the total number of documents in the index,
> not the total number of documents with populated “description” field. This is
> where it’s done in the code:
> [https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_apache_lucene-2Dsolr_blob_master_lucene_queries_src_java_org_apache_lucene_queries_mlt_MoreLikeThis.java-23L651&d=DwIFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=XIYHWqjoenB2nuyYPl8m6c5xBIOD8PZJ4CWx0j6tQjA&m=gYOyL1Msgk2dpzigOsIvXq3CiFF0T7ApMLBVVDKW2dQ&s=v4mgEvgP3HWtMZcL3FTiKeY2nBOPJpTypmCpCBwPkQs&e=]
> The effect of this choice is that the “idf” does not vary much, given that
> numDocs >> number of documents with “description”, so the key terms end up
> being just the terms with the highest term frequencies.
> It is inconsistent because the MLT-search then uses these extracted key terms
> and scores all documents using an idf which is computed only on the subset of
> documents with “description”. So one part of the MLT uses a different numDocs
> than another part. This sounds like an odd choice, and not expected at all,
> and I wonder if I’m missing something.
> {quote}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (LUCENE-8984) MoreLikeThis MLT is biased for uncommon fields
[
https://issues.apache.org/jira/browse/LUCENE-8984?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anshum Gupta updated LUCENE-8984:
-
Fix Version/s: 8.3
master (9.0)
> MoreLikeThis MLT is biased for uncommon fields
> --
>
> Key: LUCENE-8984
> URL: https://issues.apache.org/jira/browse/LUCENE-8984
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Andy Hind
>Assignee: Anshum Gupta
>Priority: Major
> Fix For: master (9.0), 8.3
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> MLT always uses the total doc count and not the count of docs with the
> specific field
>
> To quote Maria Mestre from the discussion on the mailing list - 29/01/19
>
> {quote}The issue I have is that when retrieving the key scored terms
> (interestingTerms), the code uses the total number of documents in the index,
> not the total number of documents with populated “description” field. This is
> where it’s done in the code:
> [https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_apache_lucene-2Dsolr_blob_master_lucene_queries_src_java_org_apache_lucene_queries_mlt_MoreLikeThis.java-23L651&d=DwIFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=XIYHWqjoenB2nuyYPl8m6c5xBIOD8PZJ4CWx0j6tQjA&m=gYOyL1Msgk2dpzigOsIvXq3CiFF0T7ApMLBVVDKW2dQ&s=v4mgEvgP3HWtMZcL3FTiKeY2nBOPJpTypmCpCBwPkQs&e=]
> The effect of this choice is that the “idf” does not vary much, given that
> numDocs >> number of documents with “description”, so the key terms end up
> being just the terms with the highest term frequencies.
> It is inconsistent because the MLT-search then uses these extracted key terms
> and scores all documents using an idf which is computed only on the subset of
> documents with “description”. So one part of the MLT uses a different numDocs
> than another part. This sounds like an odd choice, and not expected at all,
> and I wonder if I’m missing something.
> {quote}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Moved] (LUCENE-8984) MoreLikeThis MLT is biased for uncommon fields
[
https://issues.apache.org/jira/browse/LUCENE-8984?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anshum Gupta moved SOLR-13752 to LUCENE-8984:
-
Component/s: (was: MoreLikeThis)
Key: LUCENE-8984 (was: SOLR-13752)
Lucene Fields: New,Patch Available
Project: Lucene - Core (was: Solr)
Security: (was: Public)
> MoreLikeThis MLT is biased for uncommon fields
> --
>
> Key: LUCENE-8984
> URL: https://issues.apache.org/jira/browse/LUCENE-8984
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Andy Hind
>Assignee: Anshum Gupta
>Priority: Major
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> MLT always uses the total doc count and not the count of docs with the
> specific field
>
> To quote Maria Mestre from the discussion on the mailing list - 29/01/19
>
> {quote}The issue I have is that when retrieving the key scored terms
> (interestingTerms), the code uses the total number of documents in the index,
> not the total number of documents with populated “description” field. This is
> where it’s done in the code:
> [https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_apache_lucene-2Dsolr_blob_master_lucene_queries_src_java_org_apache_lucene_queries_mlt_MoreLikeThis.java-23L651&d=DwIFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=XIYHWqjoenB2nuyYPl8m6c5xBIOD8PZJ4CWx0j6tQjA&m=gYOyL1Msgk2dpzigOsIvXq3CiFF0T7ApMLBVVDKW2dQ&s=v4mgEvgP3HWtMZcL3FTiKeY2nBOPJpTypmCpCBwPkQs&e=]
> The effect of this choice is that the “idf” does not vary much, given that
> numDocs >> number of documents with “description”, so the key terms end up
> being just the terms with the highest term frequencies.
> It is inconsistent because the MLT-search then uses these extracted key terms
> and scores all documents using an idf which is computed only on the subset of
> documents with “description”. So one part of the MLT uses a different numDocs
> than another part. This sounds like an odd choice, and not expected at all,
> and I wonder if I’m missing something.
> {quote}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Assigned] (SOLR-13752) MoreLikeThis MLT is biased for uncommon fields
[
https://issues.apache.org/jira/browse/SOLR-13752?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anshum Gupta reassigned SOLR-13752:
---
Assignee: Anshum Gupta
> MoreLikeThis MLT is biased for uncommon fields
> --
>
> Key: SOLR-13752
> URL: https://issues.apache.org/jira/browse/SOLR-13752
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: MoreLikeThis
>Reporter: Andy Hind
>Assignee: Anshum Gupta
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> MLT always uses the total doc count and not the count of docs with the
> specific field
>
> To quote Maria Mestre from the discussion on the mailing list - 29/01/19
>
> {quote}The issue I have is that when retrieving the key scored terms
> (interestingTerms), the code uses the total number of documents in the index,
> not the total number of documents with populated “description” field. This is
> where it’s done in the code:
> [https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_apache_lucene-2Dsolr_blob_master_lucene_queries_src_java_org_apache_lucene_queries_mlt_MoreLikeThis.java-23L651&d=DwIFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=XIYHWqjoenB2nuyYPl8m6c5xBIOD8PZJ4CWx0j6tQjA&m=gYOyL1Msgk2dpzigOsIvXq3CiFF0T7ApMLBVVDKW2dQ&s=v4mgEvgP3HWtMZcL3FTiKeY2nBOPJpTypmCpCBwPkQs&e=]
> The effect of this choice is that the “idf” does not vary much, given that
> numDocs >> number of documents with “description”, so the key terms end up
> being just the terms with the highest term frequencies.
> It is inconsistent because the MLT-search then uses these extracted key terms
> and scores all documents using an idf which is computed only on the subset of
> documents with “description”. So one part of the MLT uses a different numDocs
> than another part. This sounds like an odd choice, and not expected at all,
> and I wonder if I’m missing something.
> {quote}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-13773) Add env-var options to prometheus-exporter start script.
[ https://issues.apache.org/jira/browse/SOLR-13773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anshum Gupta updated SOLR-13773: Fix Version/s: 8.3 master (9.0) > Add env-var options to prometheus-exporter start script. > > > Key: SOLR-13773 > URL: https://issues.apache.org/jira/browse/SOLR-13773 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: metrics >Affects Versions: master (9.0), 8.3 >Reporter: Houston Putman >Priority: Minor > Labels: metric-collector > Fix For: master (9.0), 8.3 > > Time Spent: 2h > Remaining Estimate: 0h > > The startup options for the Prometheus Exporter are pretty sparse compared to > what the Solr start script offers. > I've added some options that mirror what Solr offers, such as > * SOLR_HEAP > * SOLR_JAVA_MEM > * GC_TUNE > Having just the memory settings available would let us start the prometheus > exporter with more than 500 Mb of heap, which right now isn't possible as the > max heap is [hard coded > here|https://github.com/apache/lucene-solr/blob/master/solr/contrib/prometheus-exporter/bin/solr-exporter#L107]. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Resolved] (SOLR-13773) Add env-var options to prometheus-exporter start script.
[ https://issues.apache.org/jira/browse/SOLR-13773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anshum Gupta resolved SOLR-13773. - Resolution: Fixed > Add env-var options to prometheus-exporter start script. > > > Key: SOLR-13773 > URL: https://issues.apache.org/jira/browse/SOLR-13773 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: metrics >Affects Versions: master (9.0), 8.3 >Reporter: Houston Putman >Assignee: Anshum Gupta >Priority: Minor > Labels: metric-collector > Fix For: master (9.0), 8.3 > > Time Spent: 2h > Remaining Estimate: 0h > > The startup options for the Prometheus Exporter are pretty sparse compared to > what the Solr start script offers. > I've added some options that mirror what Solr offers, such as > * SOLR_HEAP > * SOLR_JAVA_MEM > * GC_TUNE > Having just the memory settings available would let us start the prometheus > exporter with more than 500 Mb of heap, which right now isn't possible as the > max heap is [hard coded > here|https://github.com/apache/lucene-solr/blob/master/solr/contrib/prometheus-exporter/bin/solr-exporter#L107]. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Assigned] (SOLR-13773) Add env-var options to prometheus-exporter start script.
[ https://issues.apache.org/jira/browse/SOLR-13773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anshum Gupta reassigned SOLR-13773: --- Assignee: Anshum Gupta > Add env-var options to prometheus-exporter start script. > > > Key: SOLR-13773 > URL: https://issues.apache.org/jira/browse/SOLR-13773 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: metrics >Affects Versions: master (9.0), 8.3 >Reporter: Houston Putman >Assignee: Anshum Gupta >Priority: Minor > Labels: metric-collector > Fix For: master (9.0), 8.3 > > Time Spent: 2h > Remaining Estimate: 0h > > The startup options for the Prometheus Exporter are pretty sparse compared to > what the Solr start script offers. > I've added some options that mirror what Solr offers, such as > * SOLR_HEAP > * SOLR_JAVA_MEM > * GC_TUNE > Having just the memory settings available would let us start the prometheus > exporter with more than 500 Mb of heap, which right now isn't possible as the > max heap is [hard coded > here|https://github.com/apache/lucene-solr/blob/master/solr/contrib/prometheus-exporter/bin/solr-exporter#L107]. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
[ https://issues.apache.org/jira/browse/SOLR-13452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16929573#comment-16929573 ] Anshum Gupta commented on SOLR-13452: - or not, said that a little too soon. Continuing to debug this. > Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle. > - > > Key: SOLR-13452 > URL: https://issues.apache.org/jira/browse/SOLR-13452 > Project: Solr > Issue Type: Improvement > Components: Build >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Major > Fix For: master (9.0) > > Attachments: gradle-build.pdf > > Time Spent: 10m > Remaining Estimate: 0h > > I took some things from the great work that Dat did in > [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a > little further. > > When working with gradle in sub modules directly, I recommend > [https://github.com/dougborg/gdub] > This gradle branch uses the following plugin for version locking, version > configuration and version consistency across modules: > [https://github.com/palantir/gradle-consistent-versions] > > https://github.com/apache/lucene-solr/tree/jira/SOLR-13452_gradle_6 -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
[ https://issues.apache.org/jira/browse/SOLR-13452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16929572#comment-16929572 ] Anshum Gupta commented on SOLR-13452: - Scratch my last comment. Something in the gradle cache was messing things up for me. > Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle. > - > > Key: SOLR-13452 > URL: https://issues.apache.org/jira/browse/SOLR-13452 > Project: Solr > Issue Type: Improvement > Components: Build >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Major > Fix For: master (9.0) > > Attachments: gradle-build.pdf > > Time Spent: 10m > Remaining Estimate: 0h > > I took some things from the great work that Dat did in > [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a > little further. > > When working with gradle in sub modules directly, I recommend > [https://github.com/dougborg/gdub] > This gradle branch uses the following plugin for version locking, version > configuration and version consistency across modules: > [https://github.com/palantir/gradle-consistent-versions] > > https://github.com/apache/lucene-solr/tree/jira/SOLR-13452_gradle_6 -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
