fplabЕсть таблица PostgreSQL в которую пишутся данные. Не очень быстро, максимум 500 записей/мин. Эти данные по шедулеру надо каждые 5 секунд считывать и если есть новые, отсылать их по и-нету на определенные IP (в данных есть указания на какой IP и порт нужно отсылать ту или иную запись). После удачной отправки данных, на соответствующей записи в БД ставится пометка, что данные ушли (чтобы не дублировать ранее доставленные).
Сначала хотел сделать стандартными средствами Java (java.io.*, java.net.*), но поскольку это не "фреймворчно", то подумал, что наверняка в том же Spring есть подходящие решения. Ну хоть тот же Spring Integration. Проблема в том, что опыта его использования нет. Что толкового кроме Spring Integration Reference можно почитать для вхождения в тему? И второй вопрос: может, я не туда смотрю и для отправки данных есть решения получше?
Спасибо заранее!

Зачем тут БД, когда это очередь?!
А так "все равно" фреймворочно или не фреймворочно вы делаете.

Грубо говоря можно сделать так.

1-ый сервис читает из БД и записывает в очередь (ставит в таблице признак, что данные уже в очереди)
2-ой сервис берет данные из очереди и отправляет в другие очереди, для определенных IP
3-ий сервис читает данные из очереди для определенного IP и отправляет их. Если данные не отправились, то отправляет их обратно в эту же очередь.

И да можно сделать со Spring Integration, а можно и без него...
Можно вообще без Spring'а :-)

Petro123mad_nazgul,
Можно и без спринга и без 3х сервисов.
На классах и методах уже совсем разучились писать.

Какая разница, сервисы или классы.
Все равно, ИМХО, "удобнее" завернуть в очередь/ди.
Причем для каждого IP желательно своя очередь, чтобы если не отправилось, то стучать до тех пор, пока не отправиться (ну или какая другая логика отправки)
Например в рамках Spring Integration это можно сделать в одном приложении.
Но в виде микросервисов - это "стильно, модно, молодежно" ;-)

Petro123mad_nazgul,
Один метод в одном потоке прочитал, отправил и поставил галку что отправил.

Вот это то мне мне нравиться.
Трудно распараллелить отправку.

fplabНе для обучения. И коль скоро пошли цитаты, то позвольте и мне поучаствовать: "Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить" Ч.Э.Р.Хоар.
Хочется, действительно, надежно и просто, чтобы ни самому потом не разбираться в собственном мусоре, ни других не подставлять, кому доведется сопровождать и поддерживать. Поэтому и не спешу как дурак реализовывать через цикл for :)

Если нужно быстро написать, то проще через цикл.
Если нужно быстро - то нужно сразу закладывать "параллельность".
Т.е., например, для каждого IP:port иметь свою очередь.

Ну а чтобы решение было "понятным", то цикл вне конкуренции.

Если поддерживаемым... то надо "ванговать", что может понадобиться "завтра".
И тут либо "оверинженегринг", либо пусть, кто будет поддерживать в будущем сами разбираются.

Petro123fplab,
Просто равно надежно всегда было.
Т.е. опять таки за пол часа можно написать твою задачу.
Без спринга и SOA.

Просто != надежно.
Просто это просто, а надежно, это надежно.

Например, просто - это аналоговый сигнал.
А надежно - цифровой сигнал. ;-)

вадяmad_nazgulНапример, просто - это аналоговый сигнал.
А надежно - цифровой сигнал. ;-)вопрос спорный - при аналоговом тв сигнале - не обратишь внимание на помехи, а при цифровом- замаешься смотреть

Корректирующие коды, и прочие хешики.
Даже при искажении сигнала, есть алгоритмы, которые могут восстановить информацию.
Это не так просто :-)

Petro123Что есть оверхед в данной задаче всегда было искусством выбора архитектора.
Это и есть наша работа).
Можно еще треугольник вспомнить: Быстро <=> Надежно <=> Дешево

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