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

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

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

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

У вас есть что-нибудь посоветовать в этом проблема?

9
java messaging

5 ответов

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

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

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

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

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

4

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

4

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

2

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

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

1

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

0