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

["Robbie Gemmell (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/ARTEMIS-3949?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17582915#comment-17582915 ] 

Robbie Gemmell commented on ARTEMIS-3949:
-----------------------------------------

What you are asking for is for the session+children implementation to actually be made safe for use from multiple threads, which it isnt currently and is clearly not meant to be. What is in place with the counter is a form of helper/warning system to potentially advise that you are using multiple threads where you should not be doing so.

I would expect the current behaviour stems directly from or was influenced by the explicit JMS threading model where a given Session and its child producers/consumers are expressly single threaded (even such that using a MessageListener on a MessageConsumer renders the parent Session to be dedicated to the session-wide listener thread). Applications do have to know which thread of theirs is using a Session and its related objects, including for acknowledgement (which operates on the session). If you are handing messages from one session out to multiple other threads for processing, you do need to similarly coordinate things back the way for acknowledgement. Nothing is forced to synchronise on the session object itself however vs using some external means for coordination. There are other alternatives to doing any such thread coordination like use of multiple sessions, of if lengthy parallel processing isnt an issue perhaps just use of multiple listeners on a single session.

> 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
>            Priority: Major
>
> {{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)