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

вот сейчас трасса правильная но она только с инициатора, посмотрите такую же на таргете

это значит что у вас включенна активация на очереди с опцией poison_message_handling (по умолчанию включена)

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

анализируйте свою процедуру активации на наличие ошибок или явных rollback transaction

Максим Александровитч,

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

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

Максим Александровитч,

Очередь - внутренее это таблица. открытие диалога почти тоже самое что добавление строки в таблицу (с оговорками конечно).

Для самих диалогов используются внутрение системные таблицы sysdercv sysdesend. ими управляет ядро и вам особого дела до них нет. можно сказать что управление выполнено эффективно: в один момент может быть открыто несколько милионов диалогов и это не будет большой проблемой.
Другое дело что если вы не будете своевременно диалоги закрывать они так и будут копиться в таблице, а чем большими данными оперирует сиквел как известно, тем медленней процесс.

Под многозадачностью я понимал процесс активации в котором экземпляр процедуры активации может запускаться на очереди в нескольких сессиях подряд.
у вас же есть возможность указать в инструкции alter queue опцию MAX_QUEUE_READRES. это собственно и есть контроль количества возможных параллельных сессий которые будут запускать процедуру активации.
по умолчаю каждые 5 секунд внутренний монитор на очереди проверяет справляется ли процедура активации с разгребанием сообщений в очереди, если сообщения продолжают поступать он подключает еще один экземпляр хранимки в обработку и так далее до достижения лимита max_queue_readers или пока не наступит момент когда экземпляров процедурок будет хватать.

но инструкция receive накладывает блокировку на ключ conversation_hanlde поэтому если у вас к примеру 1000000 сообщений в одном диалоге и вы считаете что сейчас "брокер разгонится и как начнет в 10 сессий вычитывать сообщения из этого диалога" то сильно ошибаетесь, экземпляр процедуры активации действительно запустится в одной сессии и начнет обрабатывать данные этого конкретного диалога, только делать он это будет один, больше экземпляров хранимок не запустится.

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

опять таки же все еще зависит от того как написать процедуру активации.
есть еще внешняя активация, которая тоже крайне полезна, описывать ее не буду легче нагуглить Service Broker External Activation

Черт..огонь.
Был бы Оскар для форумчан дал бы вам ,без сомнения.
Про внешний активатор и не слышал даже..
Скажите,на свой практике вы его использовали?

использовал.

Проблема внутренней активации в том что как я уже написал внутренний таймер мониторинга срабатывает каждые 5 секунд.
Это хард-код поведение которое никак не изменить. То есть даже при явном наличии большого пула сообщений внутренняя активация разгоняется до максимального количества одновременно работающих процедур активации относительно небыстро.

А вот внешняя активация устроена так что помимо основной очереди, есть еще "следящая" очередь. закидивая сообщения определенного типа в следяющуу очередь можно вызвать "внешний" обработчик очереди в которую поступают сообщения. это может быть ваша собственная самописная программа или уже готовое решение от microsoft (называется ssbeas). оно как раз следит за начилием сообщений в следящей очереди постоянной инструкцией waitfor receive и как только в следящую очередь поступает сообщение вызывает логику которая начинает вычитку сообщений из основной очереди.
в этом плане можно легко контролировать кол-во одновременно работающий обработчиков очереди. не хватает к примеру: запулил сразу 10 сообщений в следящую очередь и в тот же момент поднялось 10 внешних приложений которые начали вычитывать сообщения из основной очереди.

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

Максим Александровитч,

готовое из коробки от мелкомягких только под винду, можно запустить в эмуляторе типа wine или VMware

Максим Александровитч,

у Вас текущее сообщение об ошибке это транспортный уровень, вы аутентификацию не по сертификату что ли настроили?

Если соединения нет значит накосячили с эндпоинтами, проверьте наличие сертификатов и конечных точек.

Максим Александровитч,

Ну этот скриншот действительно выглядит норм, непонятно правда почему удиалога far_ broker_ instance нулевой. Ну запустите евент- сессию на обоих серверах я тут в этом топике ее код гдето приводил и посмотрите возникающие события. В случае ошибок будут message undeliverable.

С телефона не удобно просто писать