[ https://issues.apache.org/jira/browse/ARTEMIS-3949?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17583045#comment-17583045 ]
Peter Machon commented on ARTEMIS-3949: --------------------------------------- >From a user perspective I call the acknowledge method that is part of the >ClientMessage. I do not even recognize, that it internally access the session. Let me put it like this: We subscribe by means of {{setMessageHandler. }}The handler is executed on a thread pool, to avoid blocking. The handler can decide when it calls the acknowledge method of the {{ClientMessage,}} e.g. after successfully mapping and republishing the message. This is all part of a library and handlers are configured in user code. Thus, the handler has no clue about the session or the subscribing {{{}Thread{}}}. Even if it had this information, that would force every user to understand the requirement of being single threaded. Yet, I see the point of useless performance penalties in simpler cases. Maybe another idea would be to provide something like a {{{}ConcurrentClientSessionImpl{}}}. This implementation could probably even work without synchronization, similar to or maybe even based on [https://github.com/ben-manes/caffeine] . What do you think? > Internally synchronize methods in ClientSession implementations > --------------------------------------------------------------- > > Key: ARTEMIS-3949 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3949 > Project: ActiveMQ Artemis > Issue Type: Improvement > Affects Versions: 2.24.0 > Reporter: Peter Machon > 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)