hive-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sushanth Sowmyan (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (HIVE-16642) New Events created as part of replv2 potentially break replv1
Date Thu, 11 May 2017 08:40:04 GMT

     [ https://issues.apache.org/jira/browse/HIVE-16642?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Sushanth Sowmyan updated HIVE-16642:
------------------------------------
    Description: 
We have a couple of new events introduced, such as \{CREATE,DROP\}\{INDEX,FUNCTION\} since
the introduction of replv1, but those which do not have a replv1 ReplicationTask associated
with them.

Thus, for users like Falcon, we potentially wind up throwing a IllegalStateException if replv1
based HiveDR is running on a cluster with these updated events.

Thus, we should be more graceful when encountering them, returning a NoopReplicationTask equivalent
that they can make use of, or ignore, for such newer events.

In addition, we should add additional test cases so that we track whether or not the creation
of these events leads to any backward incompatibility we introduce. To this end, if any of
the events should change so that we introduce a backward incompatibility, we should have these
tests fail, and alert us to that possibility.

  was:
We have a couple of new events introduced, such as {CREATE,DROP}{INDEX,FUNCTION} since the
introduction of replv1, but those which do not have a replv1 ReplicationTask associated with
them.

Thus, for users like Falcon, we potentially wind up throwing a IllegalStateException if replv1
based HiveDR is running on a cluster with these updated events.

Thus, we should be more graceful when encountering them, returning a NoopReplicationTask equivalent
that they can make use of, or ignore, for such newer events.

In addition, we should add additional test cases so that we track whether or not the creation
of these events leads to any backward incompatibility we introduce. To this end, if any of
the events should change so that we introduce a backward incompatibility, we should have these
tests fail, and alert us to that possibility.


> New Events created as part of replv2 potentially break replv1
> -------------------------------------------------------------
>
>                 Key: HIVE-16642
>                 URL: https://issues.apache.org/jira/browse/HIVE-16642
>             Project: Hive
>          Issue Type: Sub-task
>          Components: repl
>            Reporter: Sushanth Sowmyan
>            Assignee: Sushanth Sowmyan
>         Attachments: HIVE-16642.1.patch
>
>
> We have a couple of new events introduced, such as \{CREATE,DROP\}\{INDEX,FUNCTION\}
since the introduction of replv1, but those which do not have a replv1 ReplicationTask associated
with them.
> Thus, for users like Falcon, we potentially wind up throwing a IllegalStateException
if replv1 based HiveDR is running on a cluster with these updated events.
> Thus, we should be more graceful when encountering them, returning a NoopReplicationTask
equivalent that they can make use of, or ignore, for such newer events.
> In addition, we should add additional test cases so that we track whether or not the
creation of these events leads to any backward incompatibility we introduce. To this end,
if any of the events should change so that we introduce a backward incompatibility, we should
have these tests fail, and alert us to that possibility.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Mime
View raw message