NewYear
ну осталось настроить каналы и вот эту "выделенная (для нас) очередь" сделать как Remote Queue Definition.
Видимо у меня какая-то сильно неполная документация. :(
Я сейчас делаю вот так:
на одном менеджере определяю request channel которому в Connection name определяю (по TCP\IP) имя своей машины и в скобках - порт на котором висит листенер целевого менеджера. Потом определяю Remote Queue. Но там нигде не указывается канал... думал, что может оно автоматом получает возможные имена удаленных менеджеров и имена очередей... но я указываю имена своих менеджера и очереди... но mqopen для этой очереди (где она remote definition) не выполняется. Вот еще интересно - где бы вводить эти mq команды вручную? У меня есть прилада MQSeries API Exerciser - но она шлет команды только такие как на кнопочках нарисовано (MQOPEN, MQDISC, MQCONN, etc)... еще есть коммандная строка для неких MQSC комманд - она запускается и говорит, что команды, которые она понимает: alter, clear, start, define, delete, etc... :(

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

ggv
Таки придется читать оба и одновременно :))
Угу. И быстро! :)

Ладно, что-то почитал (не все). Что-то поробовал - нифига не получилось. Если возможно, подскажите конкретно где я ошибся и как правильно.
Итак, два менеджера сообщений на одном сервере:
1. remote
Очереди:

a) cantsend - normal (установлена как дефолтная Dead-Letter Queue для remote)
b) send - transmission (установлена как дефолтная Transmission для remote)
c) local_sended - Remote Queue Definition (Remote Queue Name - sended, Remote Queue Manager Name - local, Transmission Queue Name - send)

Каналы:

а) ch1 - Server (TCP/IP, localhost(2222), Transmission Queue - send)

Listener слушает порт 1111

2. local
Очереди:

а) sended - normal

Каналы:

а) ch1 - Requester (TCP/IP, localhost(1111))

Listener слушает порт 2222

Теперь что пытаюсь делать:
1. Через MQSeries API Exerciser делаю MQCONN к remote
2. MQOPEN для send
3. Пару раз MQPUT
4. MQCLOSE, MQDISC

После этого в очереди send на remote у меня лежат эти два сообщения.
Теперь делаю на local: (в MQSEries Browser) правой кнопой на канале ch1, и - Start. Сообщения из send пропадают, но в sended на local не появляются! :( Зато появляются два сообщения в cantsend c Dead-Letter Header = MQFB_XMIT_Q_MSG_ERROR (в хелпе прочитал, что это означает, что он не может послать сообщение, т.к. оно неправильного формата).

В связи с этим у меня вопросы:
1. Что за формат, как его посмотреть, установить... если вам не трудно. Или когда еще может быть такая ошибка?
2. Названия\имена менеджеров, хостов, очередей - регистрозависимы млм нет? (конркетно у меня сейчас все сделано маленькими латинскими буквами, просто на будущее знать)
3. Столкнулся с тем, что после того как положу сообщения в очередь send и потом запущу старт канала на local, то потом не могу открыть очередь send - пишет, что объект занят. Я думал, что должна быть полная асинхронность и, соответственно, мультипользовательский доступ к очередям для записи и чтения. Я что-то не так делаю?
4. Не совсем понял - вроде бы в каких-то местах читал, что нужно открывать и делать MQPUT не в send, а в local_sended. Но она у меня не открывается. Если должна, то я, конечно, разберусь... но может быть вы мне подскажете сразу какие параметры мне нужно определить для MQOPEN и MQPUT?

NewYear
а вот не нужно ложить сообщение напрямую в transmission queue.

Ну я так и думал, просто у меня не ложилось в правильную. :)


так и должно быть. приложения обычно не обращаются к transmission queue.

Ну да - в таком ключе становится более понятно его поведение.


поле Options в MQOO должно иметь значение MQOO_OUTPUT. нельзя RQD открыть на INPUT.

Вроде бы я так пробовал... завтра попробую еще.


каналы sender/receiver.

Хмм.. поправьте, если ошибусь, но при sender\reciver инициатором передачи выступает sender. А у меня ситуация, что сообщения помещаются в "мою" очередь на удаленном сервере, а мне нужно инициировать соединение и забирать сообщения для меня. Впрочем я запутался во всех этих сендерах\ресиверах\реквестерах\серверах...


имя transmission queue обычно совпадает с именем менежера, на кот. нужно отправить сообщения. это важно для маршрутизации сообщений.

У меня особой маршрутизации не будет, но, конечно, лучше делать сразу как принято де факто и как правильнее.


руками канал статровать не нужно, нужно настроить trigger condition на tramsmission queue.
На трансмишн? Это, наверно, для сендер\ресивер? Ведь у меня инициирует соединение клиент.

NewYear
поле Options в MQOO должно иметь значение MQOO_OUTPUT. нельзя RQD открыть на INPUT.

Так работает! :) А вчера я пробовал эту опцию включать, но, видимо, были включены еще другие опции.

NewYear , ggv - Спасибо вам огромное за терпение! Задача у меня пока окончательно не решена, но с мертвой точки сдвинулась однозначно. Да и в голове по чуть-чуть начинает укладываться.

З.Ы. Но вы все же ответьте на мое предыдущее сообщение, если будет минутка свободного времени.

NewYear
>Ведь у меня инициирует соединение клиент.
можно конечно так. на практике я никогда так не делал.

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


вообще вот такая последовательность.

Согласен, что так будет правильнее и беспроблемнее, но (во всяком случае, на этом этапе) задача стоит так, что мы должны инициировать соединение и забирать наши сообщения - насколько я понял, в этом случае может вырасти сетевой трафик, т.к. проверять есть сообщения или нет придется просто через интервалы времени. Правда сообщений будет достаточно много скорее всего!

ggv
Так что если не трудно - повторно вопросы требующие ответа

Не трудно, но на них уже ответил New Year. Пока больше вопросов нет - вот сейчас пытаюсь читать про то, каким же образом можно управлять секурностью - где задавать\определять пользователей, пароли, принадлежности очередей. Но про это мне стоит почитать сначала, а уж потом вопросы задавать. :)

Вообще, конечно, тема достаточно большая и интересная, если бы у нас планировалось более масштабное внедрение сообщений, то, вероятно, был бы и более серьезный подход. А так эти сообщения воспринимаются просто дополнительной заморочкой, которую надо обойти и все (потому что уже есть и отлично функционирует схема получения данных из таблиц удаленного сервера, тем более, что sql server позволяет линковать удаленные сервера и обращаться к их таблицам, вьюшкам, функциям и процедурам). Мне бы по этой теме было бы очень интересно послушать\высказаться (хотя я не могу достаточно авторитетно сказать про плюсы и минусы очередей сообщений, но никак не могу найти минусы в использовании удаленных таблиц). Но это, наверно, лучше делать другой теме и когда у вас будет свободное время. А эту тему оставить для вопросов-ответов по конфигурации клиентов-каналов-серверов MQSeries.

ggv
Ну не везде есть смысл лепить RDBMS для воплощения IPC

100% согласен.


А вот, например, связать несколько RDBMS посредством некоего IPC (MQ) - легко можно представить. И воплотить.
Представить-то легко. Но если стоит задача ТОЛЬКО репликации (или просто предоставления данных с одного сервера OLTP для нескольких серверов OLTP или OLAP), то и плюсов нет. Или я все же что-то еще недопонимаю?

ggvну судя по тому, что IBM мигрирует с SQL-replication to Q-replication - видимо чего-то вы с IBM понимаете по другому.

По моему, пока очень небольшому, опыту общения с DB2 IBM очень многое понимает по другому. :)
Тем не менее (как мне кажется) абсолютное большинство RBDMS встраивает в свои продукты механизмы репликации и получения данных из удаленных БД. Вероятно они тоже имеют мнение отличное от мнения IBM. Впрочем, MS, говорят, в Юконе уже ввела более плотную интеграцию с очередями сообщений. Интересно - будут ли они напрямую поддерживать MQSeries.


Если посмотреть на

Я постараюсь.


Есть и практические примеры преимуществ - но уже на мыло, если хочешь.
r_runner at mail.ru

ggvили по другому - у меня и мысли никогда не возникнет, чтоб торкнуть SP прилинкованного сервера....

Ну а что тут страшного, если
Главное - интерфейс согласовать.


А ну как он аж фиг знает где....

Да и пусть - ничего более страшного, чем и при очередях. Как мне кажется.

Однако SP - это очень неправильно. Особенно в DB2 - там они не могут быть федеративными. Да и другие СУБД понимают их ресальсеты как табличные значения со многими ограничениями. На мой взгляд наиболее гибко получается, если предоставляется вьюшка или табличная функция с инкрементальным ключом. Конечно, если вью или функцию переписать - все может сломаться, но ведь если формат сообщений поменять в одностороннем порядке, то все то же сломается. Вью или функция как раз и есть тот самый интерфейс, который надо согласовывать и менять только при обоюдной договоренности... ну, или хотя бы обязательном уведомлении.

Я пока увидел один (возможно очень серьезный для некоторых применений) плюс - при схеме, когда сообщение посылает сервер по триггеру получится реализовать соответствие таблиц (я так думаю, про триггеры еще не читал) в реальном (насколько позволит скорость сетевого соединения) времени. Просто с БД это можно также сделать достаточно эффективно, но несколько заморочено. И вижу (как мне кажется) один минус - надо договариваться о формате сообщений и реализовывать парсер(ы), а это означает дополнительное время на разработку и удорожание пересылки (в смысле объемов) и обработки (в смысле ресурсов - ЦП и памяти).