[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=16398107#comment-16398107
]
Varun Thacker edited comment on SOLR-12083 at 3/14/18 5:21 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?
Also when uploading a patch with the changes folded in can you please call the
patch SOLR-12083.patch
> 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-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[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=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-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
