phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Samarth Jain (JIRA)" <>
Subject [jira] [Commented] (PHOENIX-3525) Cap automatic index rebuilding to inactive timestamp.
Date Thu, 20 Jul 2017 21:02:00 GMT


Samarth Jain commented on PHOENIX-3525:

Ah, I didn't know that. The documentation completely tripped me. I will make sure to leave
the lock acquisition as it is then.

The internal code doc does say the following though:

   * Get a row lock for the specified row. All locks are reentrant.
   * Before calling this function make sure that a region operation has already been
   * started (the calling thread has already acquired the region-close-guard lock).
   * @param row The row actions will be performed against
   * @param readLock is the lock reader or writer. True indicates that a non-exlcusive
   *                 lock is requested

So looks like we need to provide another guard with region.startRegionOperation().

> Cap automatic index rebuilding to inactive timestamp.
> -----------------------------------------------------
>                 Key: PHOENIX-3525
>                 URL:
>             Project: Phoenix
>          Issue Type: Improvement
>            Reporter: Ankit Singhal
>         Attachments: PHOENIX-3525_wip.patch
> From [] review comment on 
> For automatic rebuilding ,DISABLED_TIMESTAMP is lower bound but there is no upper bound
so we are going rebuild all the new writes written after DISABLED_TIMESTAMP even though indexes
updated properly. So we can introduce an upper bound of time where we are going to start a
rebuild thread so we can limit the data to rebuild. In case If there are frequent writes then
we can increment the rebuild period exponentially

This message was sent by Atlassian JIRA

View raw message