Rails pub / sub с ActiveMQ - PullRequest
Новая
       42

Rails pub / sub с ActiveMQ

2 голосов
/ 24 марта 2020

Мне бы хотелось, чтобы мое приложение Rails могло прослушивать и публиковать sh очереди ActiveMQ.

В этой статье приведены примеры использования ruby клиента STOMP и гема activemessaging, который интегрирует этого клиента в приложение Rails. Функциональность там кажется идеальной, но камень activemessaging, похоже, больше не поддерживается.

Существует множество ресурсов по использованию rabbitMQ вместо ActiveMQ, но я пытаюсь улучшить интеграцию моего приложения Rails с существующим стеком Java, который уже использует ActiveMQ.

Так же, как и любой знаете о драгоценном камне, который я могу использовать для достижения функциональности, аналогичной таковой у activemessaging драгоценного камня? Я не могу найти один, так что произойдет сбой:

Как бы я инициализировал клиент Stomp с постоянным подключением к моему экземпляру activeMQ в контексте моего приложения Rails, так что 1) Жизненный цикл клиента привязан к процессу ruby, выполняющему мое приложение, а не к процедуре запрос-ответ, и 2) я получаю сообщения, использующие код, такой как модели Active Record или объекты службы, определенные в моем приложении?

Заранее спасибо.

Ответы [ 2 ]

1 голос
/ 24 марта 2020

Согласно веб-сайту проекта ActiveMessaging :

ActiveMessaging - это общая c платформа для упрощения использования сообщений, но она не привязана к какой-либо конкретной системе обмена сообщениями - фактически теперь у него есть поддержка Stomp, AMQP, beanstalk, Amazon Simple Queue Service (SQS), JMS (с использованием StompConnect или напрямую на J Ruby), WebSphere MQ ...

Итак, это интерфейс для упрощения интеграции между различными протоколами обмена сообщениями и / или поставщиками. Однако, поскольку вы используете стандартизированный протокол обмена сообщениями (например, STOMP) , он вам на самом деле не нужен .

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

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

0 голосов
/ 03 апреля 2020

Так как в этом топи так мало c Я думал, что поделюсь решением, которое придумал. Установив, что прямое использование гема STOMP - это путь вперед, позвольте мне повторить ключевые проблемы:

Как бы я инициализировал клиент Stomp с постоянным подключением к моему экземпляру activeMQ в контексте моего Приложение Rails, такое, что

1) Жизненный цикл клиента привязан к процессу ruby, на котором выполняется мое приложение, а не к процедуре запрос-ответ, и

2). потреблять сообщения с использованием кода, такого как модели Active Record или сервисные объекты, определенные в моем приложении?

Часть 1) оказалось плохой идеей. Мне удалось добиться этого с помощью инициализатора Rails, который отлично работал на моем локальном компьютере. Однако, когда я запустил его в промежуточной среде, я обнаружил, что мои слушатели сообщений загадочным образом умерли. Кажется, что производственные веб-серверы порождают приложение (запускают инициализаторы), разветвляют процесс (без их запуска) и произвольно убивают процессы, в конечном итоге убивая слушателей, даже не заменяя их.

Вместо этого я использовал гем daemons для создания фонового процесса, который легко запускать и останавливать. Мой код в lib / daemons / message_listener.rb выглядел примерно так: 

require 'daemons'
# Usage (from daemons dir):
# ruby message_listener start
# ruby message_listener status
# ruby message_listener stop
# See https://github.com/thuehlinger/daemons for full docs.

# Require this to get your app code
require_relative '../../config/environment'

Daemons.run_proc('listener.rb') do

  client = nil

  at_exit do
    begin
      client.close
    rescue # probably means there's no connection to close, do nothing to handle it.
    end
  end

  client = Stomp::Client.new(your_config_options)

  # Your message handling code using your rails app goes here 

  loop do
    # I'd expected that subscribing to a stomp queue would be blocking,
    # but it doesn't seem to be.
    sleep(0.001)
  end

end
...