[jira] [Updated] (SENTRY-1462) UpdateForwarder handling of failed updates is boken

["Alexander Kolbasov (JIRA)" <ji...@apache.org>]

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

Alexander Kolbasov updated SENTRY-1462:
---------------------------------------
    Description: 
The UpdateFollower class has the following logic:

{code}
  private void spawnInitialUpdater(final Updateable<K> updateable,
      final int initUpdateRetryDelay) {
    K firstFullImage = null;
    try {
      firstFullImage = imageRetreiver.retrieveFullImage(INIT_SEQ_NUM);
    } catch (Exception e) {
      LOGGER.warn("InitialUpdater encountered exception !! ", e);
      firstFullImage = null;
      Thread initUpdater = new Thread() {
        @Override
        public void run() {
           ...
           Retry logic here
        }
  ...
}
{code}

There is no synchronization with this retry thread. More over it isn't clear what is the benefit of such async recovery.

For example, later in the code, handleUpdateNotification{}  accesses  updateable field without checking whether it is null or not, but even if it would, we may get inconsistency due to async nature of updates.



  was:
The UpdateFollower class has the following logic:

{code}
  private void spawnInitialUpdater(final Updateable<K> updateable,
      final int initUpdateRetryDelay) {
    K firstFullImage = null;
    try {
      firstFullImage = imageRetreiver.retrieveFullImage(INIT_SEQ_NUM);
    } catch (Exception e) {
      LOGGER.warn("InitialUpdater encountered exception !! ", e);
      firstFullImage = null;
      Thread initUpdater = new Thread() {
        @Override
        public void run() {
           ...
           Retry logic here
        }
  ...
}
{code}

There is no synchronization with this retry thread. More over it isn't clear what is the benefit of such async recovery.

For example, later in the code, {code}handleUpdateNotification{} {code} accesses {code} updateable {code} field without checking whether it is null or not, but even if it would, we may get inconsistency due to async nature of updates.




> UpdateForwarder handling of failed updates is boken
> ---------------------------------------------------
>
>                 Key: SENTRY-1462
>                 URL: https://issues.apache.org/jira/browse/SENTRY-1462
>             Project: Sentry
>          Issue Type: Bug
>          Components: Hdfs Plugin
>    Affects Versions: 1.7.0, sentry-ha-redesign
>            Reporter: Alexander Kolbasov
>            Priority: Minor
>
> The UpdateFollower class has the following logic:
> {code}
>   private void spawnInitialUpdater(final Updateable<K> updateable,
>       final int initUpdateRetryDelay) {
>     K firstFullImage = null;
>     try {
>       firstFullImage = imageRetreiver.retrieveFullImage(INIT_SEQ_NUM);
>     } catch (Exception e) {
>       LOGGER.warn("InitialUpdater encountered exception !! ", e);
>       firstFullImage = null;
>       Thread initUpdater = new Thread() {
>         @Override
>         public void run() {
>            ...
>            Retry logic here
>         }
>   ...
> }
> {code}
> There is no synchronization with this retry thread. More over it isn't clear what is the benefit of such async recovery.
> For example, later in the code, handleUpdateNotification{}  accesses  updateable field without checking whether it is null or not, but even if it would, we may get inconsistency due to async nature of updates.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)