phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kadir OZDEMIR (Jira)" <>
Subject [jira] [Created] (PHOENIX-5998) Paged server side operations
Date Fri, 10 Jul 2020 00:48:00 GMT
Kadir OZDEMIR created PHOENIX-5998:

             Summary: Paged server side operations 
                 Key: PHOENIX-5998
             Project: Phoenix
          Issue Type: Improvement
         Environment: Phoenix provides the option of performing upsert select and delete query
operations on the client or server side.  This is decided by the Phoenix optimizer based on
configuration parameters. For the server side option, the table operation (upsert select/delete
query) is parallelized such that multiple table regions are scanned and the mutations derived
from these scans can also be executed in parallel on the server side. However, currently there
is no paging capability and the server side operation can take long enough lead to HBase client
timeouts. When this happens, Phoenix can return failure to its applications and the rest of
the parallel scans and mutations on the server side can still continue since  Phoenix has
no mechanism in place to stop these operations before returning failure to applications. This
can create unexpected race conditions between these left-over operations and the new operations
issued by applications. Putting a limit on the number of rows to be processed within a single
RPC call (i.e., the next operation on the scanner) on the server side using a Phoenix level
paging is highly desirable and a required step to prevent the possible race conditions. This
paging mechanism has been already implemented for index rebuild and verification operations
and proven to be effective to prevent timeouts. This paging can be implemented for all server
side operations including aggregates, upsert selects, delete queries and so on.
            Reporter: Kadir OZDEMIR
             Fix For: 4.x

This message was sent by Atlassian Jira

View raw message