Question: is it icorrect that one session per message in an XA transaction is opened?

[turing85]

Hello!

This is no(t yet an) issue, but more of a question.

Technical setup

We are using:

• quarkus (latest LTS, 3.8.3) with
• camel-jms (latest LTS, 4.4.1, which - under the hood - uses spring's JmsTemplate in version 6.1.6)

to write multiple messages to a queue within an XA transaction. Our backing messaging system is an ActiveMQ Artemis. As driver, we use

• quarkus-artemis-jms in version 3.2.1 (which - under the hood - uses artemis in version 3.32.0) and
• quarkus-pooled-jms in version 2.3.1 (which - under the hood - uses messaginghub's pooled-jms version 3.1.5) to pool the connections.

Observed behaviour

We had an issue where the pool started to block after 500 messages have been sent in a singular XA transaction. We were able to prevent this issue by setting quarkus.pooled-jms.max-sessions-per-connection (which defaults to 500) to -1 (which is then used to configure the maxSessionsPerConnection on the JmsPoolConnectionFactory here (github.com)).

This indicates that the pool is opening a separate session per message sent in the XA transaction.

Reproducer

We wrote a reproducer which can be found here (github.com). We can execute

./mvnw clean quarkus:dev

to start the reproducer. It will write 1000 messages to the queue on application startup.

---

Note

To run the reproducer:

• docker or a docker-compatible container runtime - like podman - as well as
• a working testcontainers setup

is needed.

---

Questions

• Is this expected behaviour?
  • If it is: can we somehow enforce that this does not happen, so that only a single session is used?
  • if it is not: how can we fix it? When we take a look at the documentation of JmsTemplate (docs.spring.io) we find the following: "NOTE: The ConnectionFactory used with this template should return pooled Connections (or a single shared Connection) as well as pooled Sessions and MessageProducers. Otherwise, performance of ad-hoc JMS operations is going to suffer." Could this be the root cause?
• What consequences does it have if we set the maxSessionsPerConnection to -1? Especially:
  • Could this lead to massive memory consumption and - in the worst case - to a crash?
  • Could this lead to a noticeable performance degredation?

[tabish121]

This is not something that the JMS pool controls so there isn't much that can be done from this level. I'd recommend contacting the Quarkus support channels for help. The pool simply opens a session when asked and does not open a session itself for sending messages.

[turing85]

What about the other question wrt. maxSessionsPerConnection?

[tabish121]

You basically already answered that for yourself. Allowing unlimited growth in the sessions leads to unlimited growth in memory consumption and likely eventual performance issues. The solution is to figure out why the orchestrating software is doing this. The pool, when asked to create a session, will create a session until the limit is hit. The other thing to look into is why those sessions aren't being closed by the software that asked for them, is it leaking sessions?

[turing85]

I don't think the sessions can be closed as long as the XA-transaction is not committed. I can see in the narayana logs that the sessions are closed when the transaction is committed.

Wrt. the orchestration... camel says "we are just calling spring". Spring says "we are just calling the pool". So... yeah...

[tabish121]

The question would be why are messages piling up in a single transaction, that's not something the pool has control over, nor does it control who can call it to create a session. The source is open, you are free to look at the implementation so see how things work in this area and how simple they are in terms of what the pool does here.