[ 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/3605, part of ARTEMIS-3327, has introduced a blocking logic while checking for record's presence on both delete and update operations, regardless the configured {{sync}} parameter. Before the mentioned change, the journal was using {{checkKnownRecordID}} to check for record presence that can save blocking in the happy (and most common) path: {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} There are 3 solutions to this issue: # reintroduce {{checkKnownRecordID}} and save blocking in the common & happy path # introduce a smaller semantic change that don't report any error with no sync and no callback specified # introduce a bigger semantic change that don't report any error due to missing record ID to delete/update Just as a side note, the {{try}} version of the same method already take care of ignoring existence of the record to delete, but the change proposed here would help to give the same semantic guarantees if user explicitly declare to NOT have any interest in the outcome of the operation ie no IO callbacks and no sync. was: https://github.com/apache/activemq-artemis/pull/3605, part of ARTEMIS-3327, has introduced a blocking logic while checking for record's presence on both delete and update operations, regardless the configured {{sync}} parameter. Before the mentioned change, the journal was using {{checkKnownRecordID}} to check for record presence that can save blocking in the happy (and most common) path: {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} There are 3 solutions to this issue: # reintroduce {{checkKnownRecordID}} and save blocking in the common & happy path # introduce a smaller semantic change that don't report any error with no sync and no callback specified # introduce a bigger semantic change that don't report any error due to missing record ID to delete/update > Journal blocking delete/update record with no sync > --------------------------------------------------- > > Key: ARTEMIS-3620 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3620 > Project: ActiveMQ Artemis > Issue Type: Bug > Reporter: Francesco Nigro > Assignee: Francesco Nigro > Priority: Minor > Time Spent: 1.5h > Remaining Estimate: 0h > > https://github.com/apache/activemq-artemis/pull/3605, part of ARTEMIS-3327, > has introduced a blocking logic while checking for record's presence on both > delete and update operations, regardless the configured {{sync}} parameter. > Before the mentioned change, the journal was using {{checkKnownRecordID}} to > check for record presence that can save blocking in the happy (and most > common) path: > {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} > There are 3 solutions to this issue: > # reintroduce {{checkKnownRecordID}} and save blocking in the common & happy > path > # introduce a smaller semantic change that don't report any error with no > sync and no callback specified > # introduce a bigger semantic change that don't report any error due to > missing record ID to delete/update > > Just as a side note, the {{try}} version of the same method already take care > of ignoring existence of the record to delete, but the change proposed here > would help to give the same semantic guarantees if user explicitly declare to > NOT have any interest in the outcome of the operation ie no IO callbacks and > no sync. -- This message was sent by Atlassian Jira (v8.20.1#820001)