Как прослушивать тысячи незанятых почтовых ящиков imap через spring/amqp/rabbit

Вариант использования состоит в том, чтобы сервер подключался к тысячам учетных записей электронной почты пользователей и обнюхивал входящую почту в java, предпочтительно с java mail и масштабируемой инфраструктурой типа Spring Integration/amqp/rabbit mq.

Один входящий канал удобен с входящим адаптером бездействия imap. Вы можете настроить несколько каналов в XML. Но если вам нужна постоянная очередь адаптеров прослушивателя / imapidlechannel из тысяч этих адаптеров и необходимо динамически добавлять новое пользовательское соединение для обработки сервера. Это будет проблемой. Также необходимо устранить неисправность, если прослушиватель java умирает или сервер перезагружает все эти прослушиватели, и их конфигурация также перезагружается по сравнению с восстановлением тысяч этих соединений и восстановлением, если некоторые соединения теряют способность приема в режиме ожидания без восстановления всех пользовательских соединений для приема в режиме ожидания.

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


rabbitmq jakarta-mail imap spring-integration spring-amqp
person user815026    schedule 19.05.2012    source источник

Ответы (2)


arrow_upward
0
arrow_downward

Если вы хотите использовать команду IMAP IDLE для прослушивания новых сообщений с помощью JavaMail, вам потребуется один поток для каждого почтового ящика, что, вероятно, повлияет на вашу масштабируемость. Даже сохранение тысяч подключений может быть проблемой.

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

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

person Bill Shannon    schedule 19.05.2012
comment
Это своего рода вывод, который я сделал ... нужен совет о наилучшем способе повышения устойчивости и масштабирования с помощью инфраструктуры amqp / spring. Последовательность действий будет следующей: создать список всех пользователей для опроса и разбить на страницы n – поставить первых n в очередь и обработать в распределенной среде amqp – поместить следующие n до завершения – воссоздать цикл процесса с помощью Spring-интеграции и возможностей постоянства. Каков был бы наилучший подход, чтобы вытащить вилку и восстановить состояние обработки с того места, где оно было остановлено, без ручного создания большого количества кода? - person user815026; 24.05.2012
comment
Кроме того, я забыл упомянуть, что пользовательский интерфейс действительно требует задержки типа почти в реальном времени, чтобы увидеть всплывающее окно электронной почты, поэтому вопрос в том, могут ли серверы добавляться на лету в распределенной среде по мере добавления пользователей, где эти n обрабатывают с x потоками каждый может вечно слушать? например, динамические пулы соединений для каждого сервера, их сходство и знание того, с какими пользователями они подключаются навсегда? может быть, какой-то постоянный кеш для пользовательских атрибутов, но динамические распределенные пулы узлов - это сложно. - person user815026; 24.05.2012

arrow_upward
0
arrow_downward

Другой вариант — взглянуть на что-то вроде Akka с актерами, выполняющими асинхронный ввод-вывод. Вам нужно будет отказаться от пакета JavaMail и самостоятельно проанализировать команды imap, но для этого существует множество пакетов. Хотелось бы услышать, есть ли у вас лучшее решение.

person Community    schedule 22.03.2014