If the only things you're doing with the ClientSession are creating an address or/and queue and publishing messages and you close the corresponding ClientProducer before returning the session to the pool then I expect it will be safe.
That said, ClientSession objects were designed to be light weight so I'd recommend simply using a session-per-thread model. It will be simpler to implement & maintain and unlikely to have any kind of performance penalty. Justin P.S. I put the same response over on your corresponding Stack Overflow question - https://stackoverflow.com/questions/79773976. On Wed, Sep 24, 2025 at 12:04 PM Victoriya Bordyug <[email protected]> wrote: > Documentation for ClientSession class claims the following. > > A ClientSession is a *single-threaded* parent object required for producing > and consuming messages. *Only a single thread* may be used to operate on > the session and its child producers and consumers, other than close() > methods which may be called from another thread. Setting a MessageHandler > on a consumer renders the session, and all its child producers and > consumers, to be dedicated to the session-wide handler delivery thread of > control. > > Does stated above mean ClienSession cannot be used in multi-threaded > environment at all, even exclusively by single thread *at a time*? > ------------------------------ > > *Example* > > I have a pool of N threads and pool of M sessions. For sessions > BasePooledObjectFactory<ClientSession> is used. > > Thread T1 borrows session S1 from sessions pool, task executed by T1 > operates > on session S1 (creates address or/and queue id needed and publishes message > to ActiveMQ broker), and returns session S1 to sessions pool. On ANY > failures session S1 is also returned to sessions pool. > > So in general Sj is used only by Ti *at a period of time*. > > *Is described behaviour safe?* > *What possible culprits does this approach conceal?* > *What is the proper way to use ClientSession if any in multithread setup?* > > Thanks in advance! >
