Если общее собранное сообщение остается в пределах 100 МБ (то есть максимальный разрешенный размер сообщения), тогда у вас может быть промежуточная очередь с приложением API JQ MQ API, не использующим JMS, и повторной сборкой сообщений, а затем помещением большого повторно собранного сообщения в очередь из которого поступает приложение JMS. Это сохранит сообщения меньшего размера, пока они пересекают сеть MQ, и являются только большими (считаются неэффективными) сообщениями в последнем пункте до того, как приложение их получит.
Однако, если общее собранное сообщение больше 100 МБ, что может иметь место, если сегменты используются, то вышеупомянутое решение не поможет.
Фактически, если общее собранное сообщение больше 100 МБ, вы все равно не можете отправлять его по клиентскому соединению, и в этом случае вам нужно будет сделать приложение локальным в диспетчере очередей.
Если вы являетесь локальным менеджером очереди, то выход API, который изменяет базовый вызов MQGET, созданный уровнем JMS, также может быть возможен. Вы можете использовать это только в том случае, если у вас есть менеджер локальных очередей, потому что клиентские API-интерфейсы API поддерживаются только в C-клиенте. Вы можете пересекать канал SVRCONN независимо от типа клиента на другом конце сокета, но вы не можете отправить сообщение больше 100 МБ по клиентскому каналу, поэтому, если общее повторно собранное сообщение больше, чем MAXMSGL канала, то оно не может быть отправлен.
Связанное Чтение
Вы могли бы взглянуть на верблюде, чтобы агрегировать сообщения в памяти в конечной точке. Это вам подойдет? – flup
У вас есть какие-либо ссылки? Поддерживает ли верблюд websphere mq сегментацию? – trunkc
Верблюд построен на более высоком уровне. Таким образом, вы вернули бы верблюдов из очереди JMS, используя http://camel.apache.org/jms.html, а затем объедините их в агрегаторе верблюда http://camel.apache.org/aggregator2.html. – flup