Websphere MQ с использованием JMS, закрытые соединения застряли на MQ

У меня есть простое приложение JMS, развернутое на OC4J под сервером AIX, в моем приложении я прослушиваю некоторые очереди и отправляю в другие очереди на Websphere MQ, развернутом под сервером AS400.

Проблема в том, что мои соединения с этими очередями разрываются/закрываются, когда они какое-то время бездействуют с ошибкой MQJMS1016 (проблема не в этом), и когда это происходит, я пытаюсь восстановить соединение и это работает, однако старое соединение застревает на MQ и не будет прервано, пока оно не будет прервано вручную.

Код восстановления выглядит следующим образом:

public void recover() {
    cleanup();
    init();
}

public void cleanup(){
    if (session != null) {
        try {
            session .close();
        } catch (JMSException e) {
        }
    }
    if (connection != null) {
        try {
            connection.close();
        } catch (JMSException e) {
        }
    }
}

public void init(){
    // typical initialization of the connection, session and queue...
}

java websphere ibm-mq jms message-queue
person Ahmad Y. Saleh    schedule 01.09.2009    source источник
comment
Но в чем вопрос, и где он застревает - в session.close() ?   -  person nos    schedule 01.09.2009
comment
проблема в том, что на стороне Websphere MQ старый слушатель/производитель застрял, поэтому у меня будут дополнительные задания, которые, похоже, будут связаны с MQ. Код восстановления запускается без проблем   -  person Ahmad Y. Saleh    schedule 02.09.2009

Ответы (2)


arrow_upward
3
arrow_downward

MQJMS1016 является внутренней ошибкой и указывает на то, что потеря соединения связана с ошибкой в ​​коде или самом WMQ. Настройка каналов поможет, но вам действительно нужно решить проблему, почему приложение извергает потерянные соединения достаточно быстро, чтобы исчерпать все доступные каналы.

Первое, что я хотел бы сделать, это проверить версии WMQ и клиента WMQ, которые работают. Если это новая разработка, убедитесь, что вы используете клиент WMQ v7, поскольку версия v6 устарела в сентябре 2011 года. Клиент v7 работает с v6 QMgrs, пока вы не сможете обновить и его. Как только вы доберетесь до клиента v7 и QMgr, вам будет доступно довольно много вариантов настройки канала и повторного подключения.

Скачать клиент WMQ v7 можно здесь: http://bit.ly/bXM0q3

Также обратите внимание, что логика повторного подключения в приведенном выше коде не приостанавливается между попытками. Если клиент отправляет запросы на соединение с высокой скоростью, он может перегрузить прослушиватель WMQ и выполнить очень эффективную DOS-атаку. Рекомендуется спать несколько секунд между попытками.

Наконец, ПОЖАЛУЙСТА, распечатайте связанные исключения в ваших блоках перехвата JMSException. Если у вас есть проблема с транспортным провайдером JMS, JMS Linked Exception будет содержать любую низкоуровневую информацию об ошибке. В случае WMQ он содержит код причины, например 2035 MQRC_AUTHORIZATION_ERROR или 2033 MQRC_NO_MSG_AVAILABLE. Вот пример:

try {
  .
  . code that might throw a JMSException
  .
} catch (JMSException je) {
  System.err.println("caught "+je);
  Exception e = je.getLinkedException();
  if (e != null) {
    System.err.println("linked exception: "+e);
  } else {
    System.err.println("No linked exception found.");
  }
}

Если вы получите сообщение об ошибке в 2 часа ночи, ваш администратор WMQ поблагодарит вас за связанные исключения.

person T.Rob    schedule 26.04.2010
comment
Сеть была настроена на завершение любого бездействующего соединения, поэтому проблема была для нас ясна, а связанное исключение было вроде бы неуместным (однако я проверю историю проблемы и предоставлю связанное исключение, когда у меня будет больше времени). На самом деле восстановление соединения происходило с 30-секундным тайм-аутом, а для возникновения проблемы с максимальным количеством подключений требовалось несколько дней (не так часто, как можно предположить в моем исходном сообщении). соединение, которое мы инициируем. - person Ahmad Y. Saleh; 28.08.2010
comment
Это отличные новости! Что бы это ни стоило, связанное исключение не относится к WMQ. Любой транспортный провайдер имеет возможность разместить там соответствующую информацию. Поэтому, если он станет стандартом кодирования, он поможет с любым кодом JMS. У меня много клиентов, которые не принимают код в производство без него. В любом случае, рад слышать, что Keepalive теперь поддерживают соединения. - person T.Rob; 28.08.2010

arrow_upward
1
arrow_downward

Поскольку потерянные соединения (застрявшие соединения на стороне MQ) не влияют на обработку сообщений (т. е. они не потребляют сообщения), мы оставили все как есть, пока не будет достигнуто максимальное количество соединений, разрешенных на MQ.

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

проверьте здесь

person Ahmad Y. Saleh    schedule 17.01.2010
comment
Упомянутый APAR просто говорит вам, как настроить каналы, чтобы WMQ быстрее пожинал сирот. Хотя это полезно, это всего лишь обходной путь и не замена для устранения основной причины и печати связанных исключений. - person T.Rob; 25.08.2010