Асинхронщина в Spring

православный Java EE, а не этот набор костылей (Spring)

Скажи, что ты труллишь.

JMS

Ну натурально содомит. RabbitMQ, епта.

Спринг дружит с JMS, там даже шаблоны есть, но сам не использовал, т.ч. за удобство ручаться не могу http://docs.spring.io/spring/docs/3.0.x/reference/jms.html

на гугле забанили? или ты так, потролить про набор костылей, т.е. spring?

По теме есть что ответить?

Если что, вопрос был архитектурный. Естественно его задавать не гуглу, а сообществу.

про набор костылей, т.е. spring?

Ну, а что не так? :) Но, в любом случае, мне с этими костылями ещё не один десяток км предстоит пройти.

Ну вроде как в spring есть даже jms template какой-то... Не пользовался. Думаю, вполне себе дружит.

Без JMS обойтись вообще можно - выше советовали RabbitMQ.

Если что, вопрос был архитектурный. Естественно его задавать не гуглу, а сообществу.

Ну ты нашел где искать экспертного мнения. Сходил бы на StackOverflow лучше. Тут одни борщевики остались да хипстеры. Экспертов вытравили всех, днем с огнем не сыщешь.

Когда-то в development было мощное коммьюнити профессионалов, но сейчас это маргинальное болото, побулькивающее метаном.

Если б я разрабатывал проект с нуля, разумеется, выбрал бы кошерно-православный Java EE, а не этот набор костылей (Spring)

Мдя, все смешалось в доме Облонских. Еще буквально пару лет назад эта фраза вызвала бы гомерический хохот, плавно переходящий лицоруку у любого вменяемого джависта. Потому что в мире явы спринг был и имхо до сих пор остается единственным фреймворком, где все работает как надо, а если не работает как надо по умолчанию, то это настраивается за 10 минут использования гугла.

По делу тут уже посоветовали JmsTemplate спринговый. http://docs.spring.io/spring/docs/3.2.x/spring-framework-reference/html/jms.html

ThreadPool с очередью не хватит? Поддержка такого есть в виде например @Async аннотации

Вполне не проблема в контроллере пулять запрос на MQ, и в том же сервисе его слушать. Пример даже в сорцах лора есть(см. индексацию в солр).

По теме есть что ответить?

http://bit.ly/1ay4Kib

ThreadPool с очередью не хватит? Поддержка такого есть в виде например @Async аннотации

Так и буду делать поначалу, эдакая недоJMS для бедных :) понятное дело, что ни о каком queue persistence, pubsub, in-order delivery тут речи не будет.

Всем, кто советовал RabbitMQ — пацаны, для одной задачи поднимать цельную йобу на Ерланге? Вы представляете, сколько это проблем повлечёт с кластерным деплойментом, с безопасниками и т.п.

Так что поначалу буду делать как maxcom посоветовал, на ограниченном ThreadPool'e с очередью. Потом буду предлагать либо JMS (в WebSphere он встроенный, а разработчикам поднимать легковесный брокер), либо безброкерный солюшен типа ZeroMQ.

Всем спасибо!

Хочется большего — можно много всякого притащить. Akka например, но это уже будет не spring. Ну или можно JMS реализацию встраиваемую взять.

ZeroMQ без нативной либы бывает?

Ну или можно JMS реализацию встраиваемую взять.

О! А такое есть?

ZeroMQ без нативной либы бывает?

хз, пока не курил, как раскурю — отпишусь здесь

Ну или можно JMS реализацию встраиваемую взять.

О! А такое есть?

Например ActiveMQ на l.o.r именно так и запущен для простоты - прямо внутри веб приложения, настраивается Spring'ом. HornetQ, говорят, проще встраивается и в целом более подходит для встраиваемого применения.

Хороший топик на StackOverflow: http://stackoverflow.com/questions/2507536/lightweight-jms-broker

Там рекомендуют:

• FFMQ
• ActiveMQ в embedded-режиме, что якобы особенно легко достигается со спрингом
• какую-то неведому зверушку, которую я бы не рисковал юзать

В общем, есть где разгуляться.

Круто, спасибо огромное. А какие use cases обслуживает ActiveMQ на ЛОРе, в трёх словах? знаю, что сорцы открыты, но из первых уст быстрее получится :)

Отправка емейлов? Долгоиграющие запросы на переиндексацию чего-нибудь? Уведомления о топиках?

Сейчас используется только для построения / перестроения поискового индекса.

Рассылка уведомления пока происходит синхронно, но думаю рано или поздно там тоже будет использоваться очередь.

Я таки угадал один пункт :) Последний вопрос, если ещё не надоел.

Почему здесь именно MQ, а не тот же самый ThreadPool? Несколько слушателей на разные типы индексов (pubsub)? Нужна гарантированная доставка, порядок и персистентность? Или задел на будущее (уведомления и т.п.)?

Нужна минимальная персистентность. Чтобы рестарт веб-приложения не приводил к продалбыванию обновлений индекса.

Всё, теперь понятно. Спасибо и удачи! :)