Minor 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:
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; } }
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.
Attachments
Issue Links
- is caused by
-
ARTEMIS-3327 Remove unnecessary block operations on journal
-
- Closed
-
- links to
