Peter Machon created ARTEMIS-3949:
-------------------------------------
Summary: Internally synchronize methods in ClientSession
implementations
Key: ARTEMIS-3949
URL: https://issues.apache.org/jira/browse/ARTEMIS-3949
Project: ActiveMQ Artemis
Issue Type: Improvement
Components: ActiveMQ-Artemis-Native
Affects Versions: 2.24.0
Reporter: Peter Machon
Assignee: Clebert Suconic
{{ClientSessionImpl}} has two internal functions i.e. {{startCall}} and
{{{}endCall{}}}. These function count concurrent access and throw in case of
concurrent access.
They are used e.g. in {{{}ClientProducerImpl{}}}s {{doSend}} method and in the
{{ClientSessionImpls}} {{acknowledge}} method.
This forces user code to synchronize the use of the session object. That is a
pain for two reasons:
1. From a user perspective it is not even clear, which methods are internally
counting concurrent access. E.g. the `doSend` method does not even belong to
the session.
2. The session object is not accessible from the user code at any time. E.g.
the {{ClientMessageImpl}} internally uses the {{{}ClientSession{}}}s
{{acknowledge}} method. From user code it is not necessarily clear which
session the `ClientMessage` belongs to.
Thus, it would require user code to e.g. implement their own message store just
to be able to synchronize the right session.
Solution:
The {{ClientSessionImpl}} and all other internal objects like
{{{}ClientProducerImpl, ClientMessageImpl{}}}, and similar have full access and
knowledge about their synchronization needs.
I thus suggest to implement synchronization where needed instead of leaving the
user alone with this issue, where the solution actually means to reimplement a
lot of functionality of the client.
E.g.
{{startCall();}}
{{try {}}
{{sessionContext.sendACK(false, blockOnAcknowledge, consumer, message);}}
{{} finally {}}
{{endCall();}}
could be replaced with something like
{{synchronized(this) {}}
{{sessionContext.sendACK(false, blockOnAcknowledge, consumer, message);}}
{{} }}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
