Jelmer Marinus created ARTEMIS-4197:
---------------------------------------
Summary: AbstractJournalStorageManager address-settings not
thread-safe
Key: ARTEMIS-4197
URL: https://issues.apache.org/jira/browse/ARTEMIS-4197
Project: ActiveMQ Artemis
Issue Type: Bug
Reporter: Jelmer Marinus
The `AbstractJournalStorageManager` contains the following code.
{code:java}
@Override
public void storeAddressSetting(PersistedAddressSetting addressSetting) throws
Exception {
deleteAddressSetting(addressSetting.getAddressMatch());
try (ArtemisCloseable lock = closeableReadLock()) {
long id = idGenerator.generateID();
addressSetting.setStoreId(id);
bindingsJournal.appendAddRecord(id,
JournalRecordIds.ADDRESS_SETTING_RECORD, addressSetting, true);
mapPersistedAddressSettings.put(addressSetting.getAddressMatch(),
addressSetting);
}
}{code}
This code is used to update the AddressSettings through, i.e., the Artemis
management API.
is also contains the following code
{code:java}
@Override
public List<PersistedAddressSetting> recoverAddressSettings() throws Exception {
try (ArtemisCloseable lock = closeableReadLock()) {
return new ArrayList<>(mapPersistedAddressSettings.values());
}
} {code}
This code is called during, i.e., a config. reload when i.e. the broker.xml
gets changed.
When a first thread and executes the first code fragement and a second thread
executes the second fragment there is a possibility of the following:
# The first thread executes the deleteAddressSettings for address MY_ADDRESS;
# The second thread runs the whole recoverAddressSettings method
# The first thread runs the remainder of the storeAddressSetting-method for
MY_ADDRESS.
According to the second thread there where no addressSettings for the address
MY_ADDRESS. Because it ran in between the delete and put of the
storeAddressSetting-method.
I think this can be fixed using read-/write-locks from the storageManagerLock.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
