Подключение к Azure служебной шине с использованием приложения Java Spring - Тайм-аут

Question

Я написал клиент, который пытается подключиться к сервисной шине Azure. Как только сервер запускается, я получаю следующие ошибки и не получаю сообщений в очереди. Я попытался заменить протокол sb на amqpwss, но это не помогло.

2020-05-25 21:23:11 [ReactorThreadeebf108d-444b-4acd-935f-c2c2c135451d] INFO  c.m.a.s.p.RequestResponseLink - Internal send link 'RequestResponseLink-Sender_0480eb_c31e1cc239bf471e811e53a30adc6488_G51' of requestresponselink to '$cbs' encountered error.
com.microsoft.azure.servicebus.primitives.ServiceBusException: com.microsoft.azure.servicebus.amqp.AmqpException: The connection was inactive for more than the allowed 60000 milliseconds and is closed by container 'LinkTracker'. TrackingId:c31e1cc239bf471e811e53a30adc6488_G51, SystemTracker:gateway7, Timestamp:2020-05-25T21:23:10
at com.microsoft.azure.servicebus.primitives.ExceptionUtil.toException(ExceptionUtil.java:55)
at com.microsoft.azure.servicebus.primitives.RequestResponseLink$InternalSender.onClose(RequestResponseLink.java:759)
at com.microsoft.azure.servicebus.amqp.BaseLinkHandler.processOnClose(BaseLinkHandler.java:66)
at com.microsoft.azure.servicebus.amqp.BaseLinkHandler.onLinkRemoteClose(BaseLinkHandler.java:42)
at org.apache.qpid.proton.engine.BaseHandler.handle(BaseHandler.java:176)
at org.apache.qpid.proton.engine.impl.EventImpl.dispatch(EventImpl.java:108)
at org.apache.qpid.proton.reactor.impl.ReactorImpl.dispatch(ReactorImpl.java:324)
at org.apache.qpid.proton.reactor.impl.ReactorImpl.process(ReactorImpl.java:291)
at com.microsoft.azure.servicebus.primitives.MessagingFactory$RunReactor.run(MessagingFactory.java:491)
at java.lang.Thread.run(Thread.java:748)
Caused by: com.microsoft.azure.servicebus.amqp.AmqpException: The connection was inactive for more than the allowed 60000 milliseconds and is closed by container 'LinkTracker'. TrackingId:c31e1cc239bf471e811e53a30adc6488_G51, SystemTracker:gateway7, Timestamp:2020-05-25T21:23:10
... 10 common frames omitted

Answer 1

Аналогичная проблема открыта в GitHub

то, что вы разместили здесь, является следом, а не ошибкой. Да, служба закрывает неактивные соединения через 10 минут. Клиент отслеживает его и повторно открывает соединение. Он работает без проблем, не вызывает никаких исключений в приложении. Это не может быть твоей проблемой. Если ваши отправления не работают, это означает, что может быть другая проблема, но не эта.

Как я вижу, во второй строке речь идет о тайм-ауте в 6 секунд, можете ли вы проверить страницу устранения неполадок если поможет. Также this .

мы рекомендуем добавить «syn c -publish = true» к URL-адресу подключения