After wondering for months how to best tackle this I am now consistently unable to reproduce the "Session should not be used from more than one thread" warning ....
again, thank you Justin for your replies. /Lewis On Thu, 8 Jul 2021 at 00:35, Justin Bertram <[email protected]> wrote: > That only applies to use-cases involving MessageListener implementations. > Are you using MessageListeners? You hadn't mentioned this so I assumed you > weren't. > > Also, it would clarify your use-case a great deal if you could share some > code. Do you have a GitHub project or something you could provide a link > to? > > > Justin > > On Tue, Jul 6, 2021 at 10:46 PM Lewis Gardner <[email protected]> > wrote: > > > Thanks for the quick response, Justin. > > > > The "session-per-consumer and start() method" relates to this clause from > > the JMS spec ( > https://docs.oracle.com/javaee/7/api/javax/jms/Session.html) > > > > "Once a connection has been started, any session with one or more > > registered message listeners is dedicated to the thread of control that > > delivers messages to it. It is erroneous for client code to use this > > session or any of its constituent objects from another thread of > control." > > > > You cannot call any operations on the Session (except close) from any > > thread other than the broker's message delivery thread once the > connection > > is started, including any "createConsumer" methods. If you attempt to do > so > > Artemis prints the aforementioned warning about single thread usage. > > Consequently, I cannot add consumers to existing Sessions once the > > connection is started, that is why I was asking about alternatives. > > > > regards, > > Lewis > > > > > > On Wed, 7 Jul 2021 at 11:35, Justin Bertram <[email protected]> wrote: > > > > > > All the online examples and those included in Artemis distribution > > > register all sessions, producers and consumers *before* starting the > > > connection. > > > > > > I'm a bit confused by this assertion. A quick look through the examples > > > shipped with the broker reveal quite a few instances where a > > > javax.jms.Session and/or javax.jms.MessageConsumer are created *after* > > > javax.jms.Connection.start() is invoked. > > > > > > In any case, there's no strict rule about when start() must be invoked. > > > It's completely up to the application. > > > > > > It's worth noting that if you're using javax.jms.JMSContext [1] from > JMS > > > 2.0 the underlying connection will be automatically started when you > > create > > > a javax.jms.JMSConsumer. > > > > > > > Create a new session for each new topic consumer or... > > > > > > This is certainly possible, but I don't understand why it would be > > > necessary. Creating a new session does nothing to the flow of messages > > > which is what the start() method controls. > > > > > > > Ignore the "Session should not be used from more than one thread" > > warning > > > when adding a consumer to an existing session or... > > > > > > You certainly shouldn't ignore this no matter what. JMS Session objects > > are > > > not thread-safe and using them concurrently will result in > unpredictable > > > and indeterminate behavior. > > > > > > > Is a "session per consumer" approach OK? > > > > > > Generally speaking this approach is OK. However, I still don't > understand > > > how a session-per-consumer relates to when the start() method is > invoked. > > > > > > > > > Justin > > > > > > [1] https://docs.oracle.com/javaee/7/api/javax/jms/JMSContext.html > > > > > > On Tue, Jul 6, 2021 at 8:06 PM Lewis Gardner <[email protected]> > > > wrote: > > > > > > > All the online examples and those included in Artemis distribution > > > register > > > > all sessions, producers and consumers *before* starting the > > connection. I > > > > have an application where topic consumers can "come and go" so I need > > to > > > > either: > > > > > > > > a) Create a new session for each new topic consumer or > > > > b) Ignore the "Session should not be used from more than one thread" > > > > warning when adding a consumer to an existing session or > > > > c) Anything better than a) or b)??? > > > > > > > > Is a "session per consumer" approach OK? This would end up with ~40 > > > > sessions per application (as I have ~40 topics) and about 20 running > > > > applications so 800 sessions in Artemis ... > > > > > > > > thanks and regards, > > > > Lewis > > > > > > > > > >
