Клиенты застряли при создании сессии - PullRequest
Новая
       2

Клиенты застряли при создании сессии

1 голос
/ 02 февраля 2012

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

Они по-прежнему принимают соединения, но в противном случае перестают общаться с клиентом (даже если они все еще подключены).Для новых соединений, созданных в Java, это означает: 

con = factory.getConnection(); // method returns, connection is created
con.createSession(false, Session.AUTO_ACKNOWLEDGE); // never returns

на стороне сервера нет зарегистрированных исключений при работе в режиме отладки.

Есть ли у вас какие-либо идеи, что происходит здесь?Есть ли какое-либо сообщение журнала, которое я могу найти?

РЕДАКТИРОВАТЬ: некоторая дополнительная информация:

  • http://pastebin.com/9iztG67D - файл конфигурации XML
  • каждый узел являетсяведущий узел с подключенным ведомым (чистый ведущий)
  • клиент URI: аварийное переключение: (tcp: // serverA: 61616, tcp: // serverB: 61616, tcp: // serverC: 61616, tcp: // serverA-Slave: 61616, tcp: // serverB-Slave: 61616, tcp: // serverC-Slave: 61616)? randomize = false

Ответы [ 2 ]

0 голосов
/ 03 февраля 2012

Поскольку вы еще не показали, как выглядит клиентский URI, трудно сказать, в чем именно заключается проблема. Зависание клиента, которое вы описали, может произойти, если вы используете аварийное переключение на клиентском URI, и клиент не может подключиться к брокеру. Вызов createSession в основном отключает условие, при котором клиент начинает свой обмен командами протокола с сервером, и, если соединение не может быть установлено, вызов блокируется до тех пор, пока транспортный узел при отказе не сможет создать соединение.

0 голосов
/ 02 февраля 2012

Не зная больше о том, как настроены ваши брокеры и какую структуру очередей / тем вы используете, немного сложно точно сказать, что происходит. Но, исходя из общего поведения, которое вы описали, на некотором уровне это звучит как управление потоком.

Смотрите здесь для более подробного объяснения управления потоком. По сути, если у вас есть пункт назначения, который заполняется и достигает предела памяти из-за медленного или зависания потребителя, у брокера может возникать впечатление «блокировки», когда новые производители пытаются отправлять сообщения.

Брокеры также могут блокироваться странным образом при достижении ограничений системной памяти. Проверьте значения конфигурации для: 

<systemUsage>
  <systemUsage>
    <memoryUsage>
      <memoryUsage limit="64 mb" />
    </memoryUsage>
    <storeUsage>
      <storeUsage limit="100 gb" />
    </storeUsage>
    <tempUsage>
      <tempUsage limit="10 gb" />
    </tempUsage>
  </systemUsage>
</systemUsage>

Самый простой способ определить проблему такого рода - это использовать JMX-клиент, такой как jconsole, подключиться к брокерам и проверить текущее использование памяти с точки зрения их ограничений, для различных назначений и всего брокера. *

...