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

Reply via email to