2016-10-10 3 views
0

Мой потребитель прекрасно работали в течение одной недели, то потребитель нить умер и вошел ошибку ниже:Ошибка аутентификации пружинно-AMQP таймаут

It seems the Authentication failure is caused by BufferedInputStream.read timeout, and I want to know if there is a way to treat the Authentication failure as a non-fatal and do not kill the consumer thread. and I think the timeout issue is just caused by network issue not the Authentication failure, since this consumer already worked for one week.

org.springframework.amqp.rabbit.listener.exception.FatalListenerStartupException: Authentication failure 
at org.springframework.amqp.rabbit.listener.BlockingQueueConsumer.start(BlockingQueueConsumer.java:460) 
at org.springframework.amqp.rabbit.listener.SimpleMessageListenerContainer$AsyncMessageProcessingConsumer.run(SimpleMessageListenerContainer.java:1171) 
at java.lang.Thread.run(Thread.java:745) 
Caused by: org.springframework.amqp.AmqpAuthenticationException: com.rabbitmq.client.PossibleAuthenticationFailureException: Possibly caused by authentication failure 
at org.springframework.amqp.rabbit.support.RabbitExceptionTranslator.convertRabbitAccessException(RabbitExceptionTranslator.java:61) 
at org.springframework.amqp.rabbit.connection.AbstractConnectionFactory.createBareConnection(AbstractConnectionFactory.java:296) 
at org.springframework.amqp.rabbit.connection.CachingConnectionFactory.createConnection(CachingConnectionFactory.java:524) 
at org.springframework.amqp.rabbit.connection.ConnectionFactoryUtils$1.createConnection(ConnectionFactoryUtils.java:85) 
at org.springframework.amqp.rabbit.connection.ConnectionFactoryUtils.doGetTransactionalResourceHolder(ConnectionFactoryUtils.java:135) 
at org.springframework.amqp.rabbit.connection.ConnectionFactoryUtils.getTransactionalResourceHolder(ConnectionFactoryUtils.java:71) 
at org.springframework.amqp.rabbit.listener.BlockingQueueConsumer.start(BlockingQueueConsumer.java:456) 
... 2 more 
Caused by: com.rabbitmq.client.PossibleAuthenticationFailureException: Possibly caused by authentication failure 
at com.rabbitmq.client.impl.AMQConnection.start(AMQConnection.java:341) 
at com.rabbitmq.client.ConnectionFactory.newConnection(ConnectionFactory.java:824) 
at com.rabbitmq.client.ConnectionFactory.newConnection(ConnectionFactory.java:736) 
at org.springframework.amqp.rabbit.connection.AbstractConnectionFactory.createBareConnection(AbstractConnectionFactory.java:283) 
... 7 more 
Caused by: com.rabbitmq.client.ShutdownSignalException: connection error at com.rabbitmq.utility.ValueOrException.getValue(ValueOrExcept‌​ion.java:66) at com.rabbitmq.utility.BlockingValueOrException.uninterruptibl‌​eGetValue(BlockingVa‌​lueOrException.java:‌​36) at com.rabbitmq.client.impl.AMQChannel$BlockingRpcContinuation.‌​getReply(AMQChannel.‌​java:366) at com.rabbitmq.client.impl.AMQChannel.privateRpc(AMQChannel.ja‌​va:233) at com.rabbitmq.client.impl.AMQChannel.rpc(AMQChannel.java:211) at com.rabbitmq.client.impl.AMQConnection.start(AMQConnection.j‌​ava:326) 
+0

Вызванный: com.rabbitmq.client.ShutdownSignalException: ошибка соединения в com.rabbitmq.utility.ValueOrException.getValue (ValueOrException.java:66) на com.rabbitmq.utility.BlockingValueOrException.uninterruptibleGetValue (BlockingValueOrException.java: 36) в com.rabbitmq.client.impl.AMQChannel $ BlockingRpcContinuation.getReply (AMQChannel.java:366) в com.rabbitmq.client.impl.AMQChannel.privateRpc (AMQChannel.java:233) в com.rabbitmq. client.impl.AMQChannel.rpc (AMQChannel.java:211) at com.rabbitmq.client.impl.AMQConnection.start (AMQConnection.java:326) –

+0

Вызвано: java.net.SocketException: время ожидания подключения в java .net.SocketInputStream.socketRead0 (Нативный метод) на java.net.SocketInputStream.read (SocketInputStream.java:152) на java.net.SocketInputStream.read (SocketInputStream.java:122) на java.io.BufferedInputStream.fill (BufferedInputStream.java:235) at java.io.BufferedInputStream.read (BufferedInputStream.java:254) at java.io.DataInputStream.readUnsignedByte (DataInputStream.java:288) at com.rabbitmq.client.impl.Frame.readFrom (Frame.java : 94) at com.rabbitmq.client.impl.SocketFrameHandler.readFrame (SocketFrameHandler.java:138) –

+0

первый раз, чтобы задать вопрос здесь и всегда получил. Ваше сообщение содержит код, который не был правильно отформатирован как код. Пожалуйста, отпечатайте весь код на 4 пробела, используя кнопку панели инструментов кода или сочетание клавиш CTRL + K. Для получения дополнительной помощи по редактированию щелкните панель инструментов [?] Ico. поэтому я добавляю некоторые комментарии, чтобы опубликовать свой вопрос –

ответ

0

Мишень код выглядит как:

} catch (ShutdownSignalException e) { 
... 
    throw new PossibleAuthenticationFailureException(e); 
} 

Так что, действительно, не обязательно, чтобы проблема с подключением была связана с аутентификацией.

Существует только ShutdownSignalException по причине Connection timed out.

Итак, вы должны просто попытаться увеличить время ожидания соединения, то есть 60000 по умолчанию.

Но, скорее всего, есть проблема с ресурсами брокера, так как мы просто не можем подключиться.

Мы не можем рассматривать такие ошибки (ShutdownSignalException) как нефатальные, так как ваша проблема происходит именно на start().

РЕДАКТИРОВАТЬ

В случае фатального сбоя контейнер излучает ListenerContainerConsumerFailedEvent: http://docs.spring.io/spring-amqp/reference/html/_reference.html#consumer-events. Вы можете справиться с этим и перезапустить контейнер.

+0

, но эта ошибка не произошла при запуске приложения, это произошло при запуске проекта в течение одной недели в Интернете, он работал отлично до ошибки. и какой тайм-аут я должен установить? ответ, получение или время ожидания соединения? и если я установлю в -1, это никогда не будет тайм-аут, я прав? и таймаут повлияет на метод java.io.BufferedInputStream.read, поскольку я видел, что ошибка вызвана им. –

+0

Тайм-аут соединения, так как вы не можете подключиться к Брокеру. «BufferedInputStream.read» просто низкоуровневый, как соединение ожидает ответа от сервера сокетов.Как я уже сказал: похоже, есть утечка ресурсов в Брокере. Таким образом, он просто не может открыть для вас новое соединение после недели. Возможно, вы где-то не закрываете старую связь ... Или ваш целевой потребитель заблокирован навсегда, что контейнер-слушатель вынужден запускать новое и новое соединение, чтобы догнать сообщения из очереди ... –

+0

благодарит за ваш ответ! поэтому увеличение тайм-аута - это не способ решить мою проблему, я должен найти причину, по которой mq sever утечки ресурсов. и я использую только sping amqp для подключения к этому разъему, я должен закрыть какое-то соединение в моем коде? и у меня есть другой потребитель, который подключается к этому разъему в разных vhost, он отлично работает и не справляется с проблемой тайм-аута. –

Смежные вопросы