[
https://issues.apache.org/jira/browse/SOLR-11003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16079183#comment-16079183
]
Amrit Sarkar commented on SOLR-11003:
-------------------------------------
[~varunthacker], thank you for the review and feedback,
{quote}
Can we also test for in place updates ( I didn't see a anything triggering
that code path )
{quote}
I think IN_PLACE updates are not forwarded to target clusters / supported in
CDCR, as those updates are not recognised in CDCRReplicator::processUpdate and
are never forwarded. I still put the boolean flag in place for IN_PLACE updates
for near future. I don't know the reason why it is excluded. See this:
{code}
private UpdateRequest processUpdate(Object o, UpdateRequest req) {
// should currently be a List<Oper,Ver,Doc/Id>
List entry = (List) o;
int operationAndFlags = (Integer) entry.get(0);
int oper = operationAndFlags & UpdateLog.OPERATION_MASK;
long version = (Long) entry.get(1);
// record the operation in the benchmark timer
state.getBenchmarkTimer().incrementCounter(oper);
switch (oper) {
case UpdateLog.ADD: {
// the version is already attached to the document
SolrInputDocument sdoc = (SolrInputDocument) entry.get(entry.size() -
1);
req.add(sdoc);
return req;
}
case UpdateLog.DELETE: {
byte[] idBytes = (byte[]) entry.get(2);
req.deleteById(new String(idBytes, Charset.forName("UTF-8")));
req.setParam(VERSION_FIELD, Long.toString(version));
return req;
}
case UpdateLog.DELETE_BY_QUERY: {
String query = (String) entry.get(2);
req.deleteByQuery(query);
req.setParam(VERSION_FIELD, Long.toString(version));
return req;
}
case UpdateLog.COMMIT: {
return null;
}
default:
throw new SolrException(SolrException.ErrorCode.SERVER_ERROR, "Unknown
Operation! " + oper);
}
}
{code}
{quote}
Also it wouldn't hurt to add atomic updates to the test. Suitable comments.
{quote}
Patch updated. SOLR-11003.patch with the above recommendations.
Also I have uploaded SOLR-11003-tlogutils.patch (NOT TESTED 100%), where we are
eliminating duplicate code and putting the common in TLogCommonUtils. This
solution is much cleaner and effective. I will update once I get {{ant test}}
and {{ant test -Dtests.nightly=true}} run successfully for {{solr}} sub-project.
> Enabling bi-directional CDCR active-active clusters
> ---------------------------------------------------
>
> Key: SOLR-11003
> URL: https://issues.apache.org/jira/browse/SOLR-11003
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: CDCR
> Reporter: Amrit Sarkar
> Assignee: Varun Thacker
> Attachments: sample-configs.zip, SOLR-11003.patch, SOLR-11003.patch
>
>
> The latest version of Solr CDCR across collections / clusters is in
> active-passive format, where we can index into source collection and the
> updates gets forwarded to the passive one and vice-versa is not supported.
> https://lucene.apache.org/solr/guide/6_6/cross-data-center-replication-cdcr.html
> https://issues.apache.org/jira/browse/SOLR-6273
> We are try to get a design ready to index in both collections and the
> updates gets reflected across the collections in real-time.
> ClusterACollectionA => ClusterBCollectionB | ClusterBCollectionB =>
> ClusterACollectionA.
> The best use-case would be to we keep indexing in ClusterACollectionA which
> forwards the updates to ClusterBCollectionB. If ClusterACollectionA gets
> down, we point the indexer and searcher application to ClusterBCollectionB.
> Once ClusterACollectionA is up, depending on updates count, they will be
> bootstrapped or forwarded to ClusterACollectionA from ClusterBCollectionB and
> keep indexing on the ClusterBCollectionB.
--
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
