You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Varun Thacker (JIRA)" <ji...@apache.org> on 2018/03/14 05:08:00 UTC

[jira] [Comment Edited] (SOLR-12083) RealTimeGetComponent fails for INPLACE_UPDATE when Cdcr enabled

    [ https://issues.apache.org/jira/browse/SOLR-12083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16398107#comment-16398107 ] 

Varun Thacker edited comment on SOLR-12083 at 3/14/18 5:07 AM:
---------------------------------------------------------------

Thanks Amrit for working on this!

I kind of like the SOLR-12083-A-within-test-framework.patch approach better

Couple of things about the SOLR-12083-A-within-test-framework.patch patch
 * Any reason why we don't randomzie the update log in TestInPlaceUpdatesDistrib like we do in the other approach?
 * Can we log in randomizeUpdateLogClsProp which update log is being used
 * A small refactor could be instead of using a sysprop and then reading the sysprop in SolrTestCaseJ4 to call randomizeUpdateLogClsProp , why not just make randomizeUpdateLogClsProp and clearUpdateLogClsProp public and call them directly in the beforeClass/afterClass method of TestInPlaceUpdatesDistrib / UpdateLogTest . What do you think?

Also when uploading a patch with the changes folded in can you please call the patch SOLR-12083.patch


was (Author: varunthacker):
Thanks Amrit for working on this!

I kind of like the SOLR-12083-A-within-test-framework.patch approach better

Couple of things about the SOLR-12083-A-within-test-framework.patch patch
 * Any reason why we don't randomzie the update log in TestInPlaceUpdatesDistrib like we do in the other approach?
 * Can we log in randomizeUpdateLogClsProp which update log is being used
 * A small refactor could be instead of using a sysprop and then reading the sysprop in SolrTestCaseJ4 to call randomizeUpdateLogClsProp , why not just make randomizeUpdateLogClsProp and clearUpdateLogClsProp public and call them directly in the beforeClass/afterClass method of TestInPlaceUpdatesDistrib / UpdateLogTest . What do you think?

> RealTimeGetComponent fails for INPLACE_UPDATE when Cdcr enabled 
> ----------------------------------------------------------------
>
>                 Key: SOLR-12083
>                 URL: https://issues.apache.org/jira/browse/SOLR-12083
>             Project: Solr
>          Issue Type: Bug
>      Security Level: Public(Default Security Level. Issues are Public) 
>          Components: CDCR
>    Affects Versions: 7.2, 7.2.1, 7.3
>            Reporter: Amrit Sarkar
>            Assignee: Varun Thacker
>            Priority: Major
>         Attachments: SOLR-12083-A-within-test-framework.patch, SOLR-12083-B-wo-test-framework.patch, SOLR-12083.patch, SOLR-12083.patch, add_support_for_random_ulog_in_tests.patch
>
>
> When we were adding bi-directional sync support in CDCR ( SOLR-11003 ) we changed the CDCR Update Log codec to write an extra bits. 
> When we use the RealTimeGet component on a cluster running CDCR and have in-place updates in the update log we will falsely trip an assert thus causing the request to fail
> Here's the proposed change
> {code:java}
> -                 assert entry.size() == 5;
> +                 if (ulog instanceof CdcrUpdateLog) {
> +                   assert entry.size() == 6;
> +                 }
> +                 else {
> +                   assert entry.size() == 5;
> +                 }{code}
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org