WebSphere MQ - Изменение структуры определения канала с использованием XMS.NET API

Я пытаюсь установить свойства структуры MQCD - в частности HeartBeatInterval с использованием XMS.NET API.WebSphere MQ - Изменение структуры определения канала с использованием XMS.NET API

Фон: У меня есть клиентские приложения (в .NET) с использованием XMS.NET API для чтения сообщений из WebSphere MQ. Я использую режим ClientAcknowledge. Если клиент считывает сообщение и не делает этого, WebSphere MQ ждет 300 секунд до истечения времени ожидания и делает (откат) сообщение, доступное в исходной очереди, для других клиентов, чтобы прочитать сообщение.

Задача: Я хочу снизить таймаут с 300 секунд.

Наш MQ Admin предложил изменить свойство HearBeatInterval на канале. Но изменить это не имеет никакого значения.

По-видимому, каким-то образом настройка свойства HeartBeatInterval канала на стороне клиента (наряду с настройкой канала на стороне сервера) заставит его работать. Я пытаюсь установить это значение в клиентском приложении. Но XMS API не имеет свойства, которые соответствуют MQCD.HeartBeatInterval собственности

Любое понимание выполнения этой задачи по снижению времени ожидания сообщения ack? или даже установка HeartBeatInterval на стороне клиента - если это способ сделать это.

источник

2014-10-01 screenname

Почему вы хотите снизить таймаут? почему бы не ответить на сообщение? – Shashi

Мы делаем сообщение в обычном режиме. Но мы хотим обработать сценарий, когда клиент зависает ненормально, без необходимости. Мы хотим, чтобы другие экземпляры клиентов могли обрабатывать сообщение раньше, чем ждать 300 секунд, прежде чем сообщение будет доступно в очереди. Мы запускаем несколько экземпляров клиентских приложений в режиме балансировки нагрузки. Любая идея о том, как снизить этот тайм-аут? – screenname

Конечно, это правда, что фактическое согласованное значение интервала сердцебиения будет принимать наибольшее количество из числа биений в стороне клиента и на стороне сервера, I.e. будет использовать наименее частый интервал. Если вам нужен более короткий интервал, вам нужно будет изменить оба конца.

Вместо того, чтобы кодировать его в своем приложении, почему бы не использовать CCDT? Это более гибко, если вы измените свое мнение о ценности использования и хотите снизить его или повысить в будущем.

Дальнейшее чтение

Using a client channel definition table with .NET

источник

2014-10-01 22:20:42

Спасибо за предложение. Если я возьму подход CCDT, у вас есть информация/примеры/материалы о том, как использовать его из XMS.NET API. Насколько я понимаю, клиентское приложение должно каким-то образом ссылаться на эту запись CCDT в MQ. – screenname

Добавлена ссылка в текст ответа –

Я думаю, что вы можете использовать интервал Disconnect (DISCINT) атрибут канала подключения к серверу для завершения соединения от приложений, которые висят. По умолчанию DISCINT установлен в 0, что означает, что он отключен. Вы можете установить значение, соответствующее вашим требованиям. Подробнее читайте здесь: http://www-01.ibm.com/support/knowledgecenter/SSFKSJ_7.5.0/com.ibm.mq.ref.con.doc/q081860_.htm

Вот пример фрагмента для использования CCDT в приложении XMS .NET.

 // Get an instance of factory. 
     factoryFactory = XMSFactoryFactory.GetInstance(XMSC.CT_WMQ); 

     // Create WMQ Connection Factory. 
     cf = factoryFactory.CreateConnectionFactory(); 

     // Use CCDT URL for client connection. 
     cf.SetStringProperty(XMSC.WMQ_QUEUE_MANAGER, "QM1"); 
     cf.SetStringProperty(XMSC.WMQ_CCDTURL, "file://C:\\ProgramData\\IBM\\MQ\\qmgrs\\QM1\\@ipcc\\AMQCLCHL.TAB"); 

     // Create connection. 
     connectionWMQ = cf.CreateConnection();

источник

2014-10-04 06:35:10 Shashi

WebSphere MQ - Изменение структуры определения канала с использованием XMS.NET API

ответ

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