[
https://issues.apache.org/jira/browse/ARTEMIS-3949?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17583234#comment-17583234
]
Peter Machon commented on ARTEMIS-3949:
---------------------------------------
Yeah, I saw the JavaDoc.
However, the ClientSession is not an object, but an interface. Thread-safety
thus depends on the actual implementation. Besides, to my knowledge, the term
single-thread object is not really defined. It sounds like the object is
extending the Thread class, not that all its methods are not thread-safe.
Further, there is nothing said about the methods send() in the
ClientProducerImpl or acknowledge() in the ClientMessageImpl which are not
thread-safe too. Of course they could be implemented thread-safe. It is a
matter of choice not to do so. From the JavaDoc, I cannot clearly see that
decision.
For me personally, it is fine now. I think, I finally got the point. For future
users it might however be easier, if the JavaDoc would be more detailed on that.
Don't get me wrong. I think the Artemis broker and its client are really great
products. Especially the core protocol is designed super clear and straight to
the point. That is, why I want to help improve this awesome project.
> 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#doSend}} method and in the
> {{ClientSessionImpl#acknowledge}} method.
> This forces user code to synchronize the use of the session object. That is a
> pain for two reasons:
> # 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.
> # 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.
> {code:java}
> startCall();
> try {
> sessionContext.sendACK(false, blockOnAcknowledge, consumer, message);
> } finally {
> endCall();
> }{code}
>
> could be replaced with something like
> {code:java}
> synchronized(this) {
> sessionContext.sendACK(false, blockOnAcknowledge, consumer, message);
> }{code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
