[jira] [Updated] (ARTEMIS-3620) Appending delete records can save waiting it to happen if sync is false

["Francesco Nigro (Jira)" <ji...@apache.org>]

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

Francesco Nigro updated ARTEMIS-3620:
-------------------------------------
    Description: 
[https://github.com/apache/activemq-artemis/pull/3647] has re-introduced checking of presence of a record while deleting it;  this check will be always performed, causing a caller that has specified `sync == false` to block await the check (and the operation) to succeed making a not sync delete record to slow down.

Before the mentioned change, the journal was using {{checkKnownRecordID}} to check for record presence (without blocking)

 
{code:java}
  private boolean checkKnownRecordID(final long id, boolean strict) throws Exception {
      if (records.containsKey(id) || pendingRecords.contains(id) || (compactor != null && compactor.containsRecord(id))) {
         return true;
      }

      final SimpleFuture<Boolean> known = new SimpleFutureImpl<>();

      // retry on the append thread. maybe the appender thread is not keeping up.
      appendExecutor.execute(new Runnable() {
         @Override
         public void run() {
            journalLock.readLock().lock();
            try {

               known.set(records.containsKey(id)
                  || pendingRecords.contains(id)
                  || (compactor != null && compactor.containsRecord(id)));
            } finally {
               journalLock.readLock().unlock();
            }
         }
      });

      if (!known.get()) {
         if (strict) {
            throw new IllegalStateException("Cannot find add info " + id + " on compactor or current records");
         }
         return false;
      } else {
         return true;
      }
   }
{code}
 
This method was useful to check in a non-blocking way record's presence, if possible, by using an additional map to track known records.
2 solutions to this issue (that will likely impact other methods with sync == false that was using {{checkKnownRecordID}}) are:
# reintroduce {{checkKnownRecordID}}
# introduce a semantic change that won't check for record presence in case of sync == false and no callback specified
 

> Appending delete records can save waiting it to happen if sync is false
> -----------------------------------------------------------------------
>
>                 Key: ARTEMIS-3620
>                 URL: https://issues.apache.org/jira/browse/ARTEMIS-3620
>             Project: ActiveMQ Artemis
>          Issue Type: Improvement
>            Reporter: Francesco Nigro
>            Priority: Minor
>          Time Spent: 10m
>  Remaining Estimate: 0h
>
> [https://github.com/apache/activemq-artemis/pull/3647] has re-introduced checking of presence of a record while deleting it;  this check will be always performed, causing a caller that has specified `sync == false` to block await the check (and the operation) to succeed making a not sync delete record to slow down.
> Before the mentioned change, the journal was using {{checkKnownRecordID}} to check for record presence (without blocking)
>  
> {code:java}
>   private boolean checkKnownRecordID(final long id, boolean strict) throws Exception {
>       if (records.containsKey(id) || pendingRecords.contains(id) || (compactor != null && compactor.containsRecord(id))) {
>          return true;
>       }
>       final SimpleFuture<Boolean> known = new SimpleFutureImpl<>();
>       // retry on the append thread. maybe the appender thread is not keeping up.
>       appendExecutor.execute(new Runnable() {
>          @Override
>          public void run() {
>             journalLock.readLock().lock();
>             try {
>                known.set(records.containsKey(id)
>                   || pendingRecords.contains(id)
>                   || (compactor != null && compactor.containsRecord(id)));
>             } finally {
>                journalLock.readLock().unlock();
>             }
>          }
>       });
>       if (!known.get()) {
>          if (strict) {
>             throw new IllegalStateException("Cannot find add info " + id + " on compactor or current records");
>          }
>          return false;
>       } else {
>          return true;
>       }
>    }
> {code}
>  
> This method was useful to check in a non-blocking way record's presence, if possible, by using an additional map to track known records.
> 2 solutions to this issue (that will likely impact other methods with sync == false that was using {{checkKnownRecordID}}) are:
> # reintroduce {{checkKnownRecordID}}
> # introduce a semantic change that won't check for record presence in case of sync == false and no callback specified
>  



--
This message was sent by Atlassian Jira
(v8.20.1#820001)