[jira] [Commented] (SOLR-9511) Retire using individual versions to request updates during PeerSync
[ https://issues.apache.org/jira/browse/SOLR-9511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15698111#comment-15698111 ] Noble Paul commented on SOLR-9511: -- The option is to make this changes to trunk and not to branch_6x. The problem with that option is that the trunk diverges from the release branch a lot over time. This gives all of us a headache when applying changes across branches. I would choose to mark the methods as deprecated and remove it on both branches at once > Retire using individual versions to request updates during PeerSync > --- > > Key: SOLR-9511 > URL: https://issues.apache.org/jira/browse/SOLR-9511 > Project: Solr > Issue Type: Wish > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: master (7.0) >Reporter: Pushkar Raste >Priority: Minor > Fix For: master (7.0) > > Attachments: SOLR-9511.patch > > > We started using version ranges to request updates during PeerSync in > [SOLR-9207| https://issues.apache.org/jira/browse/SOLR-9207]. Using version > ranges was also made default. > There is no need to have code that uses individual versions start Solr 7. > Decommission (remove unnecessary code) -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-9511) Retire using individual versions to request updates during PeerSync
[ https://issues.apache.org/jira/browse/SOLR-9511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15696682#comment-15696682 ] Pushkar Raste commented on SOLR-9511: - I don't think individual versions API is being used anywhere. I agree to keep old API around for may be another major version (8.X), but don't see much harm to get rid of it in 8.X itself as old API is there in 6.X and 7.X > Retire using individual versions to request updates during PeerSync > --- > > Key: SOLR-9511 > URL: https://issues.apache.org/jira/browse/SOLR-9511 > Project: Solr > Issue Type: Wish > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: master (7.0) >Reporter: Pushkar Raste >Priority: Minor > Fix For: master (7.0) > > Attachments: SOLR-9511.patch > > > We started using version ranges to request updates during PeerSync in > [SOLR-9207| https://issues.apache.org/jira/browse/SOLR-9207]. Using version > ranges was also made default. > There is no need to have code that uses individual versions start Solr 7. > Decommission (remove unnecessary code) -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-9511) Retire using individual versions to request updates during PeerSync
[ https://issues.apache.org/jira/browse/SOLR-9511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15694774#comment-15694774 ] Noble Paul commented on SOLR-9511: -- Do we have the individual versions API used anywhere? We keep old APIs available for a few extra releases. The reason is when you do a rolling restart after upgrading your solr version, some nodes will expect the old API to be available while the other node may not have it. So, what we need to do is to ensure that 1) No code uses the old APi for the last 2 or 3 releases 2) ensure that the "upgrading from Solrx.x" in CHNAGES.txt has the relevant information > Retire using individual versions to request updates during PeerSync > --- > > Key: SOLR-9511 > URL: https://issues.apache.org/jira/browse/SOLR-9511 > Project: Solr > Issue Type: Wish > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: master (7.0) >Reporter: Pushkar Raste >Priority: Minor > Fix For: master (7.0) > > Attachments: SOLR-9511.patch > > > We started using version ranges to request updates during PeerSync in > [SOLR-9207| https://issues.apache.org/jira/browse/SOLR-9207]. Using version > ranges was also made default. > There is no need to have code that uses individual versions start Solr 7. > Decommission (remove unnecessary code) -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-9511) Retire using individual versions to request updates during PeerSync
[
https://issues.apache.org/jira/browse/SOLR-9511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15542481#comment-15542481
]
Pushkar Raste commented on SOLR-9511:
-
We are planning to set num records in ulog to a very high number. If that
number is too high, leader may run into issues (throw OOM), when replica asks
for high number of updates. In such a case we will have to request updates in
chunks/batches. In preparation of that, we should keep
{{PeerSync.requestVersions()}} logic simple.
This is ticket is to track effort for removing old way of using individual
versions to request updates.
> Retire using individual versions to request updates during PeerSync
> ---
>
> Key: SOLR-9511
> URL: https://issues.apache.org/jira/browse/SOLR-9511
> Project: Solr
> Issue Type: Wish
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: master (7.0)
>Reporter: Pushkar Raste
>Priority: Minor
> Fix For: master (7.0)
>
>
> We started using version ranges to request updates during PeerSync in
> [SOLR-9207| https://issues.apache.org/jira/browse/SOLR-9207]. Using version
> ranges was also made default.
> There is no need to have code that uses individual versions start Solr 7.
> Decommission (remove unnecessary code)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-9511) Retire using individual versions to request updates during PeerSync
[ https://issues.apache.org/jira/browse/SOLR-9511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15542482#comment-15542482 ] ASF GitHub Bot commented on SOLR-9511: -- GitHub user praste opened a pull request: https://github.com/apache/lucene-solr/pull/87 SOLR-9511, removed use of individual versions in PeerSync You can merge this pull request into a Git repository by running: $ git pull https://github.com/praste/lucene-solr SOLR-9511 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/lucene-solr/pull/87.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #87 commit 8e6c96df4363c4c8e187ab7132c26305603d175e Author: Pushkar Raste Date: 2016-09-30T20:53:11Z SOLR-9511, removed use of individual versions in PeerSync > Retire using individual versions to request updates during PeerSync > --- > > Key: SOLR-9511 > URL: https://issues.apache.org/jira/browse/SOLR-9511 > Project: Solr > Issue Type: Wish > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: master (7.0) >Reporter: Pushkar Raste >Priority: Minor > Fix For: master (7.0) > > > We started using version ranges to request updates during PeerSync in > [SOLR-9207| https://issues.apache.org/jira/browse/SOLR-9207]. Using version > ranges was also made default. > There is no need to have code that uses individual versions start Solr 7. > Decommission (remove unnecessary code) -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
