[ 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 was: [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)