phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Neha Gupta (Jira)" <>
Subject [jira] [Updated] (PHOENIX-5496) Ensure that we handle all server-side mutation codes on the client
Date Thu, 27 Feb 2020 22:58:00 GMT


Neha Gupta updated PHOENIX-5496:
    Attachment: PHOENIX-5496.4.x-HBase-1.3.v1.patch

> Ensure that we handle all server-side mutation codes on the client
> ------------------------------------------------------------------
>                 Key: PHOENIX-5496
>                 URL:
>             Project: Phoenix
>          Issue Type: Bug
>    Affects Versions: 4.15.0, 5.1.0
>            Reporter: Chinmay Kulkarni
>            Assignee: Neha Gupta
>            Priority: Major
>             Fix For: 4.15.1, 5.1.1
>         Attachments: PHOENIX-5496.4.x-HBase-1.3.patch, PHOENIX-5496.4.x-HBase-1.3.v1.patch,
PHOENIX-5496.master.patch, PHOENIX-5496.patch, PHOENIX-5496.v1.patch, PHOENIX-5496.v2.patch,
>          Time Spent: 3h 50m
>  Remaining Estimate: 0h
> There are many instances throughout wherein we set a certain error mutation code in the
RPC callback, however we do not handle these mutation codes on the client.
> For example: 
> If the metadata rows for a tableKey are no longer in that SYSCAT region, checkTableKeyInRegion()
fails, the metadata for this table is not written to SYSCAT and [the TABLE_NOT_IN_REGION
mutation code is set|].
> This is handled for 1 retry inside [CQSI.metaDataCoprocessorExec|],
but if this happens again, it is returned back to the client where it goes to the default
case and succeeds.
> Apart from the fact that partial metadata updates are possible leading to orphan metadata
rows in system tables, this also wrongly returns success for clients even though there is
no record of that table/view being created inside Phoenix's system tables.

This message was sent by Atlassian Jira

View raw message