search

ibm-messaging / mq-jms-spring

Components to assist MQ JMS integration with Spring frameworks
Apache License 2.0
189 stars 102 forks source link

Clarification for the Usage of 30s as the defaultRecieveTimeout on @JMSListner #71

Closed smpby closed 3 years ago

smpby commented 3 years ago

Hi IBM Team,

with version 2.2.0 you introduced an individual recieveTimeout of 30s, replacing the spring default of 1s for @JMSListener. Implemented here: https://github.com/ibm-messaging/mq-jms-spring/commit/7a5915d929db070186ed6d831d3de3d0d785df40#diff-c7545a38c92f0e206494dbcf06bd67f9ff383b68d32e9f95ecbfe47336b86bf1

Why 30 seconds?
Is there any reason to not increase it to a much bigger interval? (e.g. 24h)

This can be achieved by using setReceiveTimeout(24*60*60*1000L); inside an Application.
I haven't noticed any adverse effect ... But is this a good idea?

I hope you can help me with these questions.

Thanks in advance 😄

Simon

ibmmqmet commented 3 years ago

As I wrote in https://marketaylor.synology.me/?p=668 there might be other things that need to be done by the surrounding framework on each loop - for example checking for a shutdown event. Making the delay too long might block that activity. 30s seemed a reasonable compromise but that's why it can now be tuned without needing code changes - in case you find it's too long or too short.

smpby commented 3 years ago

Thank you - that article helps alot 👍