The documentation you referenced is for an older and completely separate client (for AMQP 0-x, rather than AMQP 1.0 as used by the newer client and Service Bus), so the details and options contained are not applicable in this case.
The docs for the client you are using are at: https://qpid.apache.org/releases/qpid-jms-2.5.0/docs/ The send call timeout, which is indeed not set by default, can be controlled with the jms.sendTimeout URI option: https://qpid.apache.org/releases/qpid-jms-2.5.0/docs/index.html#jms-configuration-options Attachments dont make it to the list. ServiceBus has its own particular handling of idle that will e.g close a producer if not actually sending messages for a certain short period, which could be interacting with your caching, though in general I'd expect the client to handle a producer being closed like that and kill the send call, something we do test and I'm not aware of specific issue with (and hasnt changed in years). On Mon, 17 Jun 2024 at 10:58, RAISSI Laabidi - FREELANCE.COM <laabidi.rai...@loreal.com> wrote: > > Hi, > > We are using Azure Service Bus with QPID JMS version: 2.5.0. > > Frequently we are having threads that get stuck in WAITING state when sending > messages, for indefinite time. Frequently, but not deterministically. > > I attached a picture of relevant stack trace. > > As I understood from this page: > https://qpid.apache.org/releases/qpid-jms-amqp-0-x-6.4.0/jms-amqp-0-8-book/JMS-Client-0-8-Appendix-ProducerFlowControl-Impact.html > > Producer may block if queue is overfull (or other issues), and it will > timeout after “qpid.flow_control_wait_failure” which we are keeping at > default value (60000ms). But no timeout is happening. > > > > Curiously, when investigating heap dump, I see that the value of attribute > “sendTimeout” of connectionInfo (class: JmsConnectionInfo) inside the > JmsConnection is set to -1 (INFINITE). > > Can this be the reason for not timeouting ? And if possible to indicate the > configuration that is responsible for it. > > > > Finally, we are calling the client via Spring JmsTemplate. And we are using > Spring’s CachingConnectionFactory to cache producers. > > Unfortunately we can not enable all traces because we are having millions of > messages and the issue is quite “random” (at least we can not a pattern). > > > > Please let me know if I can add further details. > > > > Thanks in advance. > > > > Kindly yours, > > Laabidi > > > > > This message and any attachments are confidential and intended solely for the > addressees. > If you receive this message in error, please delete it and immediately notify > the sender. If the reader of this message is not the intended recipient, you > are hereby notified that any unauthorized use, copying or dissemination is > prohibited. E-mails are susceptible to alteration. Neither LOREAL nor any of > its subsidiaries or affiliates shall be liable for the message if altered, > changed or falsified. > > > C1 - Internal use > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org > For additional commands, e-mail: users-h...@qpid.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
