Потоки производителя HornetQ застряли в состоянии WAITING

Мы используем HornetQ 2.2.5, и наша проблема заключается в том, что на стороне клиента (который отправляет сообщения в Q) все потоки-производители застряли в состоянии WAITING.

обратите внимание, что производитель находится на одной машине, а сервер HornetQ — на другой.

Это дамп потока на стороне клиента:

Поток: pool-10-thread-9: приоритет: 5, демон: false, threadId: 521, threadState: WAITING, lockName: java.util.concurrent.Semaphore $ NonfairSync@60568a13

sun.misc.Unsafe.park (собственный метод)

java.util.concurrent.locks.LockSupport.park(LockSupport.java:156) java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:811) java:969)

java.util.concurrent.Semaphore.acquire(Semaphore.java:441) org.hornetq.core.client.impl.ClientProducerCreditsImpl.acquireCredits(ClientProducerCreditsImpl.java:74) org.hornetq.core.client.impl.ClientProducerImpl.doSend( ClientProducerImpl.java:305) org.hornetq.core.client.impl.ClientProducerImpl.send(ClientProducerImpl.java:142) org.hornetq.jms.client.HornetQMessageProducer.doSend(HornetQMessageProducer.java:451) org.hornetq.jms. client.HornetQMessageProducer.send(HornetQMessageProducer.java:199)

соединение и сеанс к Q кэшируются и повторно используются на стороне клиента.

На стороне сервера есть следующий лог:

[hornetq-failure-check-thread] 19:25:30,820 ПРЕДУПРЕЖДЕНИЕ [org.hornetq.core.protocol.core.impl.RemotingConnectionImpl]
Обнаружен сбой подключения: не получены данные из /10.2.6.11:50697 . Вероятно, клиент завершил работу или произошел сбой, не разорвав соединение, или произошел сбой в сети между сервером и клиентом. Возможно, вы также неправильно настроили connection-ttl и client-failure-check-period. Пожалуйста, обратитесь к руководству пользователя для получения дополнительной информации. Теперь соединение будет закрыто. [код=3]

Есть ли причина, по которой все потоки производителей застряли?


producer hornetq
person Elad Eldor    schedule 06.11.2013    source источник

Ответы (1)


arrow_upward
2
arrow_downward

Это FAQ на форуме пользователей hornetq...

HornetQ по-разному справляется с переполнением сообщений, защищая его от нехватки памяти.

  • Блокировать при переполнении
  • Поток на диск (как мы это называем... пейджинг)
  • Удаление (сообщения просто исчезнут. Действительно только в тех случаях, когда вы можете позволить себе потерять сообщения)
  • Ошибка (недавно появилась в версии 2.4, в версии 2.2 этой функции нет)

Когда вы настроите систему на блокировку, клиент будет ждать кредитов, которые поступят только после того, как вы израсходуете сообщения.

Итак, либо потребляйте сообщения, либо устанавливайте настройки адреса как пейджинг.

Документация по настройке пейджинга:

http://docs.jboss.org/hornetq/2.4.0.beta1/docs/user-manual/html/paging.html#paging.main.config

Документация по режиму блокировки:

http://docs.jboss.org/hornetq/2.4.0.beta1/docs/user-manual/html/paging.html#d0e5213

person Clebert Suconic    schedule 06.11.2013
comment
согласно вашему ответу, сообщения ждут, чтобы быть употребленными. но мы проверили, что Q пуст (с помощью QueueBrowser), и, кроме того, политика addfress-full, если Q настроен на DROP. вот XML-код конфигурации Q: ‹address-settings› ‹!--по умолчанию для всех--› ‹address-setting match=#› ‹max-size-bytes›524288000‹/max-size-bytes› ‹page- size-bytes›10485760‹/page-size-bytes› ‹address-full-policy›DROP‹/address-full-policy› ‹/address-setting› ‹/address-settings› - person Elad Eldor; 10.11.2013
comment
кроме того, мы проверили, что потребитель работает — мы просматривали Q, пока потребитель работал, и браузер показывал 0 сообщений в Q. затем мы отключили потребителя, и браузер показал, что Q содержит все больше и больше сообщений. во время этого процесса производитель блокируется. - person Elad Eldor; 10.11.2013
comment
Вы используете 2.2.5, более старую версию. Вероятно, вам следует обновиться, и если вы все еще видите проблему, мне понадобится репликатор для ошибки. - person Clebert Suconic; 11.11.2013
comment
Вы также должны проверить, нет ли у вас какой-либо другой подписки на адрес... (например, подписка на тему, не использующая сообщение) - person Clebert Suconic; 11.11.2013