[ https://issues.apache.org/jira/browse/PHOENIX-5998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kadir OZDEMIR reassigned PHOENIX-5998: -------------------------------------- Assignee: Kadir OZDEMIR > Paged server side operations > ----------------------------- > > Key: PHOENIX-5998 > URL: https://issues.apache.org/jira/browse/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 > Assignee: Kadir OZDEMIR > Priority: Major > Fix For: 4.x > > > 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. -- This message was sent by Atlassian Jira (v8.3.4#803005)