You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@activemq.apache.org by "Peter Machon (Jira)" <ji...@apache.org> on 2022/08/22 09:58:00 UTC

[jira] [Created] (ARTEMIS-3949) Internally synchronize methods in ClientSession implementations

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)