Хотя в настоящее время вы не можете использовать solace-jms-spring-boot для одновременного подключения к нескольким VPN, у вас есть несколько вариантов:
Публикация обратно в ту же VPN на другую тему, и это соединение с другой VPN с использованием моста VPN. Преимущество этого подхода заключается в том, что при необходимости вы можете подключиться к ряду других VPN, которые могут быть расположены на том же или другом посреднике. Поскольку это делается в административном порядке, никаких изменений в приложении не требуется, кроме публикации в новой теме. Обратите внимание, что вам потребуется настроить мост (ы) и подписку (и), для которых требуется административный доступ. Если вы используете новую функцию динамической маршрутизации сообщений, вы можете уменьшить или устранить административную нагрузку, связанную с настройкой тем. DMR работает на нескольких сайтах и динамически обрабатывает маршрутизацию сообщений при добавлении или удалении подписок.
Используйте связыватель Solace Spring Cloud Stream (SCS) (доступно в GitHub и Maven Central) в приложении Spring Boot. Связыватель поддерживает несколько связывателей в одном приложении, используя один и тот же или другой транспорт - в этом случае вы можете определить два связывателя Solace для одного и того же посредника, но с разными именами VPN.
Что касается сообщений о подтверждении, с solace-jms-spring-boot вам не нужно явно подтверждать сообщения, так как Spring JMS использует локальные транзакции. Если ваш обратный вызов вызывает исключение, транзакция откатывается, в противном случае она фиксируется. Если он будет откатан, по умолчанию сообщение вернется в очередь и будет доставлено. Это может привести к тому, что ваше приложение перейдет в бесконечный цикл, пытаясь обработать плохое сообщение, поэтому рекомендуется установить свойство max-redelivery> 0 в очереди, а также назначить очередь мертвых сообщений, куда будет отправлено подозрительное сообщение после превышения предел повторной доставки. По умолчанию DMQ #DEAD_MSG_QUEUE, который вам может потребоваться создать. Обратите внимание, что сообщение также должно быть опубликовано с установленным флагом DMQ, установленным в значение true.
Если вместо этого вы решите использовать связыватель SCS, механизм взлома отличается и не использует локальные транзакции, а вместо этого управляется SCS. Подробные сведения о повторных попытках, DMQ (также известные как DLQ) и обработчиках глобальных и прикладных ошибок можно найти в справочной документации SCS. Поскольку SCS предоставляет аналогичную функциональность, вам не нужно настраивать max-redelivery или DMQ на брокере, а для сообщения не нужно устанавливать соответствующий флаг DMQ. Вместо этого вам нужно будет настроить обработку ошибок в свойствах вашего приложения / YAML. В общем, когда ваше приложение выдает исключение, будет предпринята попытка повторной доставки, и после превышения лимита доставки (по умолчанию 3 раза) оно либо перейдет к DLQ, либо к обработчику ошибок, определенному на уровне приложения или на глобальном уровне. Как отмечалось ранее, как это произойдет, будет зависеть от вашей конфигурации.
Пример отключения локальных транзакций здесь . Затем вы можете использовать setSessionAcknowledgeMode(Session.CLIENT_ACKNOWLEDGE) для включения подтверждения клиента. Однако любые исключения могут не откатывать другие операции (например, если вы публикуете ответ в другом сеансе). Обратите внимание, что в аннотации @JmsListener должен быть указан аргумент containerFactory, относящийся к вашей фабрике контейнеров.
В соответствии с документами, отмеченными для DefaultMessageListenerContainer, лучше использовать транзакции, если вы хотите избежать потери сообщений или неатомарных операций. Как транзакции, так и подтверждения клиента завершаются, когда ваш обратный вызов успешно возвращается.