Облегченный обмен сообщениями (асинхронные вызовы) в Java

Question

Я ищу легковесный фреймворк для обмена сообщениями на Java. Моя задача - обрабатывать события способом SEDA: я знаю, что некоторые этапы обработки могут быть завершены быстро, а другие нет, и хотел бы отделить эти этапы обработки.

Допустим, у меня есть компоненты A и B, и механизм обработки (будь то контейнер или что-то еще) вызывает компонент A, который, в свою очередь, вызывает компонент B. Мне все равно, будет ли время выполнения компонента B равным 2 с, но например, если время выполнения компонента A меньше 50 мс. Поэтому для компонента A представляется наиболее разумным отправить сообщение B, которое B будет обрабатывать в нужное время.

Мне известны различные реализации JMS и Apache ActiveMQ: они слишком тяжелые для этого. Я искал некоторые легкие сообщения (с действительно базовыми функциями, такими как сериализация сообщений и простейшая маршрутизация), но безрезультатно.

Вам есть что порекомендовать в этом выпуске?

Answer 1

Вам нужен какой-либо тип настойчивости (например, если ваша JVM умирает между обработкой тысяч сообщений) и вам нужны сообщения для перехода к любым другим JVM?

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

ActiveMQ довольно легкий; вы можете использовать его в одной JVM только без настойчивости, если хотите; Затем вы можете включить транзакции / постоянство / восстановление / удаленное взаимодействие (работая с несколькими JVM) по мере необходимости. Но если вам ничего не нужно, тогда это излишне - просто используйте Executors.

Кстати, другой вариант, если вы не уверены, для каких шагов может потребоваться постоянство / надежность или балансировка нагрузки для нескольких JVM, будет полностью скрывать использование промежуточного программного обеспечения , чтобы вы могли переключаться между очередями SEDA в памяти с исполнителями в JMS / ActiveMQ, как и когда вам нужно.

например. может случиться так, что некоторые этапы должны быть надежными и восстанавливаемыми (поэтому требуется некоторая настойчивость), а в других случаях вы этого не сделаете.

Answer 2

Действительно легкий? Исполнители . :-) Итак, вы назначаете исполнителя (B, в вашем описании), а A просто отправляет задания исполнителю.

Answer 3

Я думаю, что Apache Camel покрывает все ваши потребности. Он работает в JVM и поддерживает стиль SEDA (http://camel.apache.org/seda.html) и простую маршрутизацию. Может использоваться самостоятельно или с пружиной с поставщиком JMS или другими адаптерами.

Answer 4

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

ОБНОВЛЕНИЕ: однако я не уверен, поддерживает ли он задержки повторной доставки (проблема очереди недоставленных писем). Я нашел бы это пригодным даже для легких поставщиков. Но я предполагаю, что это могло бы быть возможно с комбинацией запроса MessageSelector и свойств сообщения.

Answer 5

Для помощи кому-то еще прочитайте эту ветку:
Одна из самых легких систем обмена сообщениями - Mbasseder . MB Ambassador - очень легкая реализация шины сообщений (событий), следуя шаблону публикации подписки. Он разработан для простоты использования и стремится быть многофункциональным и расширяемым, сохраняя при этом эффективность использования ресурсов и производительность.
Основой высокой производительности MB Ambassador является специализированная структура данных, которая сводит к минимуму конфликты блокировок, так что снижение производительности при одновременном доступе минимально.
Возможности: декларативное определение прослушивателя с помощью аннотаций, синхронизация и / или асинхронная доставка событий, слабые ссылки, фильтрация сообщений