Сonvert ActiveMQConnectionFactory to SingleConnectionFactory in jms-sender-applicationContext.xml

[therepanic]

I've been thinking about this for a very long time to be honest, and have come to one conclusion, please correct me if I'm drastically wrong.

However, the point is that I believe that when we test sending from TemporaryQueue that is created when each connection is created, it can't be synchronized. The way I understand it is this:

JmsMessageSender creates a TemporaryQueue on its JMS-Connection A

JmsTemplate tries to send a response to the same queue over a new connection B

TemporaryQueue exists only within Connection A and is not available/deleted in B

And then it turns out all tests where we test TemporaryQueue, they should be synchronized. I have made all ChannelFactory in the tests to be SingleConnectionFactory, however I guess this is necessary for tests where we use TemporaryQueue, but it would be easier to do it for all tests.

If I am misunderstanding something, please correct it

Fix: #1539

[snicoll]

Thanks for the PR!

The way I understand it is this

I don't think this is accurate. Temporary queues are created for exactly that purpose. Sender creates a temporary queue in its session, sends a message with a replyTo header with the actual reference to the destination. Then whoever processes the message uses that to reply. As long as the session in the sender is alive, so is the temporary queue. If the queue has been deleted, then the bit that waits for the reply may have died or timed out.

I haven't been able to reproduce the problem reliably so I am not sure what to do for this yet.

[therepanic]

Thanks for digging into this! You’re absolutely right about how TemporaryQueue works. What I found in our tests is that JmsMessageSender and JmsTemplate were each opening their own JMS Connection, so the queue created on Connection A could be closed (and deleted) before Connection B tried to reply. By switching both sides to use a single shared ConnectionFactory (via SingleConnectionFactory), they both reuse the same Connection/Session, so the temp queue stays alive until the reply is sent and the flakiness goes away, I think.

[snicoll]

What I found in our tests is that JmsMessageSender and JmsTemplate were each opening their own JMS Connection, so the queue created on Connection A could be closed (and deleted) before Connection B tried to reply

Yes but that's a problem in the receiver end of things.

By switching both sides to use a single shared ConnectionFactory (via SingleConnectionFactory), they both reuse the same Connection/Session, so the temp queue stays alive until the reply is sent and the flakiness goes away, I think.

You are probably correct but that's hiding the underlying problem. I'd rather make the test more robust rather than hiding the fact the receiver is closing the conection when it shouldn't have.

Thanks for the PR and the convo, in any case!

[snicoll]

As much as I dislike it, I think there's not much else we can do given the timing of the transactions.

[snicoll]

Actually this change makes it worse from what I see on CI. Given it hasn't resolved the problem I am going to revert it.