Spring Integration - JmsOutboundGatway timeouts

[robertgosz]

Hi,
I have a question regarding JmsOutboundGateway and timeouts. I was using Spring Boot 2.3.12.RELEASE with SpringIntegration and JmsOutboundGateway to send and receive async messages using IBM MQ. In the gateway configuration i used to set receiveTimeout value and if there was no reply on the ReplyDestination queue within this time JmsTimeoutException was thrown and OnFailure callback method was called. That was expected behaviour, nothing to talk about.
After switching to Spring Boot 2.6.6 I have noticed the timeouts not being thrown until the application was shut down. I did some testing and figured out that if I set replyTimeout in the @gatway definition then I can make it "work", but the behaviour is quite misleading for me. For example - when I set replyTimeout to 60s and receiveTimeout to 5s the JmsTimeoutException is thrown with a message: "org.springframework.integration.jms.JmsTimeoutException: No reply in 5000 ms", but it's being thrown after 60s, not 5s. If I set both to 60s then after 60s onSuccess is being called with null payload instead of onFailure. Similar thing happens when I set receiveTimeout to 60s and replyTimeout to 5s - after 5s onSuccess is being called with null payload instead of onFailure with timeout exception. Can anyone explain what happens there and if it's the expected behaviour ? I could not find any reasonable explanation in the documentation. Maybe I have missed or misunderstood something. Thanks in advance!

[artembilan]

Ho @robertgosz !

Thank you for the report!

Any chances that you can share with us a simple project to play with and reproduce?

[robertgosz]

I did some debugging before posting here and I saw the expiry job being successfully scheduled inside createFuture, but I was wondering why the scheduler never executed the task and did not call expire method. I didn't connect the timeout misbehaviour with scheduler itself causing the issue. Now, I think if it's single and synchronous, then it seems as quite a possible behaviour i guess.

[robertgosz]

Well, another way to fix your problem: remove responseChannel altogether. Since you just reply from JMS outbound gateway to the @Gateway in the beginning there is no need in extra channel step. You have it configured as a QueueChannel which essentially is blocked by the poller waiting for reply. And that poller is based on a TaskScheduler as well. That's where you got a dead lock: the thread from TaskScheduler is busy waiting for reply. And we cannot send that reply since, well, thread is busy. Dead lock 😄

Hahaha, that's exactly a thought that came to my mind a few minutes ago - we have scheduled expiry, we are waiting for a reply, we do have some other stuff scheduled, but then - isn't the reply job blocking ? 😄 Cause we're running on one thread 😄

[robertgosz]

Well, another way to fix your problem: remove responseChannel altogether. Since you just reply from JMS outbound gateway to the @Gateway in the beginning there is no need in extra channel step.

I use the gateway to talk to another component on the other side of those two queues and for each request I do expect a reply (or timeout). How could I live without responseChannel ?

[artembilan]

Right. There is a TemporaryReplyChannel in the headers anyway initiated by the @Gateway. So, your JmsOutboundGateway must not have a replyChannel config and the framework will correlate the reply properly with the mentioned replyChannel from headers.

[robertgosz]

And indeed it worked.
Less code, same functionality it seems.
New day, new lesson.
Thanks for your suggestion!