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

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

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

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

на стороне сервера нет авторизовалось исключения при работе в режиме отладки.

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

EDIT: некоторые дополнительная информация:

http://pastebin.com/9iztG67D - XML файл конфигурация
каждый узел представляет собой главный узел с подключенным ведомым (чистый ведущий-ведомый)
клиент URI: отказоустойчивый: (ТСР : // SERVERA: 61616, TCP: // ServerB: 61616, TCP: // ServerC: 61616, TCP: // SERVERA-Подчиненный: 61616, TCP: // ServerB-Подчиненный: 61616, TCP: // ServerC-Ведомый : 61616)? Randomize = false

источник

2012-02-02 Laures

это, скорее всего, не так, но только для того, чтобы убедиться, что вы свободном пространстве/ram/cpu ... и т.д. на BOX? – Eugene

Вы используете отказоустойчивость в URI клиентского соединения? Добавьте дополнительную информацию о конфигурации клиента. –

добавлена клиентская сторона uri – Laures

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

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

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

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

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

источник

2012-02-02 14:07:22 jkysam

Я добавил конфигурацию своего брокера. управление потоком ложно, а пределы использования системы не были достигнуты. – Laures

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

источник

2012-02-03 19:20:19

в соответствии с клиентской стороной, регистрирующей журналы отказоустойчивости, которые он подключил к первому брокеру в списке, и мои журналы клиентов, которые возвратили getConnection, но не регистрируют, что возвращает createSession. Кроме того, когда брокер потерпел неудачу, как в последний раз, мы поняли, что созданное соединение не может быть закрыто. это тоже блокирует. – Laures

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

ответ

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