[
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)
