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