[ https://issues.apache.org/jira/browse/ARTEMIS-3949?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17582937#comment-17582937 ]
Peter Machon commented on ARTEMIS-3949: --------------------------------------- Why is it clearly not meant to be? Is synchronization even required? If not, why is there such a warning? We use the core protocol, not JMS. We wrap the client logic into reactive publishers, which are thread agnostic. Thus, we cannot just store the session as a thread local. Since we use reactor we can of course put the session into the context. But actually that seems wrong. The ClientMessage offers a method acknowledge. I think, this method must care for any kind of required synchronization internally. At the moment I can only guess, where synchronization is required, to which extend. > 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)