[
https://issues.apache.org/jira/browse/SOLR-11069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16087665#comment-16087665
]
Amrit Sarkar commented on SOLR-11069:
-------------------------------------
Continuing with how LPV was never tested robust:
The only bit where the LPV mentioned in the tests is in
{{CdcrRequestHandlerTest}}
{code}
// replication never started, lastProcessedVersion should be -1 for both
shards
rsp =
invokeCdcrAction(shardToLeaderJetty.get(SOURCE_COLLECTION).get(SHARD1),
CdcrParams.CdcrAction.LASTPROCESSEDVERSION);
long lastVersion = (Long) rsp.get(CdcrParams.LAST_PROCESSED_VERSION);
assertEquals(-1l, lastVersion);
rsp =
invokeCdcrAction(shardToLeaderJetty.get(SOURCE_COLLECTION).get(SHARD2),
CdcrParams.CdcrAction.LASTPROCESSEDVERSION);
lastVersion = (Long) rsp.get(CdcrParams.LAST_PROCESSED_VERSION);
assertEquals(-1l, lastVersion);
{code}
LPV > -1 or what LPV value (which should > 1 atleast) can be when leader reads
some entries from tlogs is never tested anywhere or at least I cannot find it.
> LASTPROCESSEDVERSION for CDCR is flawed when buffering is enabled
> -----------------------------------------------------------------
>
> Key: SOLR-11069
> URL: https://issues.apache.org/jira/browse/SOLR-11069
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: CDCR
> Affects Versions: 7.0
> Reporter: Amrit Sarkar
>
> {{LASTPROCESSEDVERSION}} (a.b.v. LPV) action for CDCR breaks down due to
> poorly initialised and maintained buffer log for either source or target
> cluster core nodes.
> If buffer is enabled for cores of either source or target cluster, it return
> {{-1}}, *irrespective of number of entries in tlog read by the {{leader}}*
> node of each shard of respective collection of respective cluster. Once
> disabled, it starts telling us the correct LPV for each core.
> Due to the same flawed behavior, Update Log Synchroniser may doesn't work
> properly as expected, i.e. provides correct seek to the {{non-leader}} nodes
> to advance at. I am not sure whether this is an intended behavior for sync
> but it surely doesn't feel right.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
