Есть два java приложения. Парсер логов и web приложение отображающее информации подсчитанную парсером.
Приложение парсирует постоянно дописываемый лог, проводит вычисления полученных данных и накапливает их. Данные постоянно обновляются в зависимости от вновь поступивших данных. Есть web приложение которому в реальном времени нужно отобразить данные которые подсчитаны в парсере. Страница обновляется раз в 200 мили секунд. Значений всего около 500. Из за того что данные постоянно обновляются (например суммы) то базу использовать не совсем практично, из за задержек записи в базу и чтения из нее. Нету ли в Java более быстрого способа обмена данными между двумя java приложениями (разделяемая память и т.д.)?

cuvorov, в Java я этого не делал. Но, в принципе, параллельно запущенные программы прекрасно обмениваются данными через локальный TCP порт.

Если эта информация для человеческого глаза, то можно и не так часто.



разделяемая память - http://www.hazelcast.com/ (простой вариант) , http://www.terracotta.org  и другие.

Ну, например, транзакционный кластерный кеш. JBossCache как вариант.

Зачем же такие сложности? Требуется всего-то навсего передавать информацию между парой Java-приложений. Помимо уже упоминавшегося фокуса с сокетом способов тут может быть много:

Способ первый: Используйте RMI. Десять строк кода и простенький POJO-класс для передачи данных позволит вашему парсеру вызывать методы web-приложения.

Способ второй: используйте REST-сервис на какой-нибудь легкой основе, например Jersey. Web-приложение предоставляет этот сервис, парсер периодически постит в него найденные данные.

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

sockets  --> RMI (и прочие REST) --> distributed memory - это разные уровни абстракции, от низкого к высокому. Зачем программировать сокеты , если есть RMI ? Зачем программировать RMI , если есть распределенная память , где вопросы синхронизации, нахождения данных в сети и прочие уже решены? И те же 10 строк кода. Но вопрос на самом деле не в количестве строк ( а в их качестве  ). 

Совершенно верно. И уровень абстракции надо выбирать под задачу. Чтобы отправить простенький объект от одного приложения к другому использовать distributed memory - это  как стрелять из пушки по воробьям. Имхо, разумеется.

Я бы ровно то же самое сказал про REST-сервис. Имхо, разумеется. 

Тут, на мой взгляд, достаточно RMI, через который приложение будет дергать парсер и получать от него все данные с последнего вызова.

Как я понял, по крайней мере одно приложение Вы пишете сами. Оба приложения написаны на Java. В этом случае никто не мешает Вам вызвать одно приложение из другого и напрямую обращаться к интересующим Вас методам и даже переменным (если область видимости позволяет).

"простенький" - это, в смысле, сериализуемый? Да, абстрактно все верно. Для просто "один раз отправить один обьект" существует RMI. Но задача-то не абстрактная. Задача совершенно типовая - с компьютера на компьютер пересылается  некое состояние ("Значений всего около 500") с последующими регулярными обновлениями. Да, на RMI все делается простенько, только еще быстренько натянем где надо синхронизацию, прикрутим контроль версии обновлений, продумаем, что делать, когда один из компьютеров рестартует и т.д.. Но поскольку задача типовая, это все рутина. А рутина может и должна быть уже реализована на более высоком уровне абстракции. На мой взгляд "распределенная память" в данном случае - отнюдь не "из пушки по воробьям". Возможно, и не лучший вариант и есть что-то более специализированное, но и избыточности особой не вижу, если с компьютера на компьютер пересылается коллекция и она постоянно обновляется. Советую взглянуть на Hazelcast (кстати, он, похоже, основан на RMI) - там очень низкий порог вхождения ( а это не маловажно). Дополнительные же возможности, те, что вначале воспринимаются как "из пушки по воробьям", можно применять по мере осознания потребности.

Это сообщение отредактировал(а) COVD - 15.11.2010, 00:38