ActiveMQ: начальный потребитель без брокера

Question

Я пишу JMS-клиент, который потребляет из очереди. Мой брокер - это activemq, если это имеет значение.

Одним из требований является то, что клиент должен начать работу, даже если брокер не работает. В этом случае он должен вести себя так, как будто там, где нет сообщений в очереди, и как только брокер встает, и сообщения начинают поступать соответственно.

Проблема заключается в том, что в моем коде:

connectionFactory = new ActiveMQConnectionFactory(url); 
Connection connection = connectionFactory.createConnection(); 
connection.start() 

Если брокер вниз, то он застревает в connection.start(). Хотя то, что я хотел бы иметь, - это connection.start(), чтобы вернуться тихо и продолжать пытаться подключиться в фоновом режиме и потреблять сообщения, когда это возможно, и молчать, когда это невозможно.

Как я могу достичь этого.

Answer 1

Используйте отдельные потоки для потребления из очереди и запуска соединения. Вам потребуется использовать параллельную реализацию очереди.

Тема 1:

• очереди Instantiate
• Старт Тема 2
• Попробуйте подключить/блок
• Добавление сообщений в очереди

Тема 2 (или пул некоторых сортировка):

• Запуск клиента
• Считывание из очереди/блока
• обработки сообщений

Answer 2

Я думаю ActiveMQ есть протоколы (многие протоколы ....), чтобы изменить поведение подключения. Попробуйте использовать «failover: //» или что-то в этом URL-адресе и посмотрите, как это работает.

Answer 3

Я должен сейчас бороться с этой проблемой. См. AMQ-2114.

Я не совсем понимаю принятый ответ, поэтому предлагаю щедрость.

Я использую версию ActiveMQ на C++. Но я считаю, что это не должно сильно отличаться.

Я думал о вызове connection.start() в отдельном потоке и вызове и вызове connection-> createSession() в TransportListener :: transportResumed(). Но createSession вешает трубку.

Нижняя линия, у меня нет рабочего решения, и я рад узнать другое решение проблемы.

Answer 4

Есть два способа работы вокруг этого типа сценария, один из которых описан в Amq-2114:

1. Используя брокер URI, который был предложен в Amq-2114. Используя URI брокера, который предлагается в AMQ-2114, встроенный брокер создается с сетевым подключением к удаленному брокеру. Однако, как указывалось, этот URI брокер не использует соединитель переключения отказа.

2. Использование встроенного брокера, настроенного вручную для использования сети брокеров. Я использовал это раньше, когда экземпляр брандмауэра ActiveMQ встроен в ваше Java-приложение и настроен с сетевым подключением к удаленному брокеру. Это позволит вашему клиенту подключаться к встроенному брокеру без зависания и отправлять сообщения встроенному брокеру. Сообщения будут поступать от встроенного брокера к удаленному брокеру, но только при наличии потребительского спроса на сообщения удаленного брокера (т. Е. Потребитель подключается к удаленному брокеру и запрашивает сообщения). Подключение к встроенному брокеру может использовать транспорт отказоустойчивости, а сетевое подключение к удаленному брокеру также может использовать переход на другой ресурс.

Пример, который я даю для этого решения, является примером использования Java-приложения на ноутбуке продавца. Такое приложение должно продолжать работать, даже если продавец не подключен к своей офисной сети. Решением здесь является включение брокера в приложение Java, чтобы приложение не зависало при отправке сообщений, даже если оно не подключено к офисной сети. Когда приложение снова подключится к офисной сети, оно автоматически подключится к другому брокеру, и сообщения будут протекать.

Брюс

Answer 5

Только для потомков, я бы настоятельно рекомендовал использовать Spring в DefaultMessageListenerContainer для потребления сообщений, после настройки, используя следующие code snippet:

<jms:listener-container> 
    <jms:listener destination="queue.orders" ref="orderService" method="placeOrder"/> 
</jms:listener-container> 

он будет заботиться о подключении к инфраструктуре очереди JMS с ваши специфические требования (если инфраструктура JMS не работает, контекст приложения все равно будет загружен, но поток повторов попытается восстановить соединение каждые несколько секунд).