[
https://issues.apache.org/jira/browse/SOLR-14641?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17174241#comment-17174241
]
Cao Manh Dat commented on SOLR-14641:
-------------------------------------
But that quite non-sense to me from the point of who did the commit to do
performance test for this one since this change just basically remove
deprecated code rather than optimization. Basically what we used to do here is
* asking nodes wether they support versionRanges or not
* if true (this is the default value since 7.0) go with versionRanges handling
(instead of concerte versions).
Changes made by this issue is
* always go with verisionRanges since we know that all other nodes can support
that so it quite wasteful to ask first.
So if there are any performance regression it already happen long time ago.
Anyway I'm ok with revert the change and letting your benchmark work finish if
that makes thing easier.
> PeerSync, remove canHandleVersionRanges check
> ---------------------------------------------
>
> Key: SOLR-14641
> URL: https://issues.apache.org/jira/browse/SOLR-14641
> Project: Solr
> Issue Type: Improvement
> Reporter: Cao Manh Dat
> Assignee: Cao Manh Dat
> Priority: Major
> Fix For: 8.7
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> SOLR-9207 introduces PeerSync with updates range which committed in 6.2 and
> 7.0. To maintain backward compatibility at the time we introduce an endpoint
> in RealTimeGetComponent to check whether a node support that feature or not.
> It served well its purpose and it should be removed to reduce complexity and
> a request-response trip for asking that.
--
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
