Хотелось бы выслушать мнение каким образом реализовать клиент серверную систему в локальной сетке на Яве со следующим требованиями.
Клиенты группируются и имеют общий ресурс (мапа с примитивами)
Клиенты шлют на сервер данные около 200 байт в секунду.
Сервер шлёт на клиенты одинаковую структуру каждую секунду. 4кб максимум
Минимум задержек.
Кластеризация серверной части (основной нод и запасной) с функцией fail-over на клиенте то есть по таймауту или резету соединения повторная попытка осуществляется уже к другому ноду.
Хотелось бы иметь интерфэйс и экспортировать его, как например это есть в Sprint Remoting но с функционалом push-callback
Здравствуйте, Сеня Белдыев, Вы писали:
СБ>Всем бодрой ночи.
СБ>Хотелось бы выслушать мнение каким образом реализовать клиент серверную систему в локальной сетке на Яве со следующим требованиями. СБ>Клиенты группируются и имеют общий ресурс (мапа с примитивами) СБ>Клиенты шлют на сервер данные около 200 байт в секунду. СБ>Сервер шлёт на клиенты одинаковую структуру каждую секунду. 4кб максимум СБ>Минимум задержек. СБ>Кластеризация серверной части (основной нод и запасной) с функцией fail-over на клиенте то есть по таймауту или резету соединения повторная попытка осуществляется уже к другому ноду.
СБ>Хотелось бы иметь интерфэйс и экспортировать его, как например это есть в Sprint Remoting но с функционалом push-callback
СБ>С уважением.
Вариант №1 "lightweight" с Jini поверх обычного Java RMI:
Запускается несколько экземпляров серверов. В сети присутствует экземпляр lookup service, в котором хранятся RMI-заглушки на экспортированные интерфейсы серверов. Клиенты находят lookup service через multicast discovery и запрашивают ссылку на работающий сервер. В случае ошибки коммуникации с основным сервером, клиент снова обращается к lookup service и получает ссылку на вторичный севрер. Сам lookup service также может дублироваться, так что SPOF не появляется. С callback к клиентам со стороны серверов тоже никаких проблем нет, так как всё peer-to-peer.
Вариант №2 "enterprise" c JMX:
Берётся реализация JMX, поддерживающая резервирование. Например, ActiveMQ. На клиентах прописываются параметры подключения к основному и резервному ActiveMQ. Для образной связи к клиентам можно тоже использовать JMX, например, временные очереди сообщений.
В этом варианте можно попробовать спрятать детали работы с JMX от клиентов с помощью Spring Integration, но это уже опционально.
Здравствуйте, Лобанов Игорь, Вы писали:
ЛИ>Здравствуйте, Сеня Белдыев, Вы писали:
СБ>>Всем бодрой ночи.
СБ>>Хотелось бы выслушать мнение каким образом реализовать клиент серверную систему в локальной сетке на Яве со следующим требованиями. СБ>>Клиенты группируются и имеют общий ресурс (мапа с примитивами) СБ>>Клиенты шлют на сервер данные около 200 байт в секунду. СБ>>Сервер шлёт на клиенты одинаковую структуру каждую секунду. 4кб максимум СБ>>Минимум задержек. СБ>>Кластеризация серверной части (основной нод и запасной) с функцией fail-over на клиенте то есть по таймауту или резету соединения повторная попытка осуществляется уже к другому ноду.
СБ>>Хотелось бы иметь интерфэйс и экспортировать его, как например это есть в Sprint Remoting но с функционалом push-callback
СБ>>С уважением.
ЛИ>Вариант №1 "lightweight" с Jini поверх обычного Java RMI: ЛИ>Запускается несколько экземпляров серверов. В сети присутствует экземпляр lookup service, в котором хранятся RMI-заглушки на экспортированные интерфейсы серверов. Клиенты находят lookup service через multicast discovery и запрашивают ссылку на работающий сервер. В случае ошибки коммуникации с основным сервером, клиент снова обращается к lookup service и получает ссылку на вторичный севрер. Сам lookup service также может дублироваться, так что SPOF не появляется. С callback к клиентам со стороны серверов тоже никаких проблем нет, так как всё peer-to-peer.
ЛИ>Вариант №2 "enterprise" c JMX: ЛИ>Берётся реализация JMX, поддерживающая резервирование. Например, ActiveMQ. На клиентах прописываются параметры подключения к основному и резервному ActiveMQ. Для образной связи к клиентам можно тоже использовать JMX, например, временные очереди сообщений.
ЛИ>В этом варианте можно попробовать спрятать детали работы с JMX от клиентов с помощью Spring Integration, но это уже опционально.
Да это всё здорово.
Но JMS добавляет оверхэд на объёмы пересылаемого. 40% получается в моём конкретном случае.
Насяльника ругается.
RMI это прошлый век. Плюс только в том что она в яве в дистрибутиве сидит.
Предыдущую версию сделал через спринговый RMIServiceExporter — медленно и самое главное что lookup rmi registry изредка тупит аж по 2 минуты.
Повторить практически невозможно, а если клиенты жалуются на лаги, то и мне насяльника пайку урезает.
Здравствуйте, mazurkin, Вы писали:
M>Сеня Белдыев wrote:
>> Клиенты группируются и имеют общий ресурс (мапа с примитивами)
M>Terracotta
Клиенту ставить её чтоли ? Программа для клиента вообще через вебстарт работает у меня сейчас.
И разве можно в терракоте частично реплицировать стэйт?
Я имею ввиду если на серваке лежит структура ввиде дерева, то можно ли синхронизировать только 1 её часть с другой ява машиной?
В других распределённых кэшах так нельзя. В jboss cache нету такого точно.
>> Клиенты шлют на сервер данные около 200 байт в секунду. >> Сервер шлёт на клиенты одинаковую структуру каждую секунду. 4кб максимум
M>JMS
Оверхэд большой. Замерил.
Здравствуйте, Сеня Белдыев, Вы писали:
СБ>Да это всё здорово. СБ>Но JMS добавляет оверхэд на объёмы пересылаемого. 40% получается в моём конкретном случае. СБ>Насяльника ругается.
Порекомендуйте начальнику Gigabit Etherner.
СБ>RMI это прошлый век. Плюс только в том что она в яве в дистрибутиве сидит. СБ>Предыдущую версию сделал через спринговый RMIServiceExporter — медленно и самое главное что lookup rmi registry изредка тупит аж по 2 минуты. СБ>Повторить практически невозможно, а если клиенты жалуются на лаги, то и мне насяльника пайку урезает.
Из вашего исходного поста создавалось впечатление, что основная проблема лежит в реализации discovery и failover, и я рекомендовал Jini именно как как ответ на эти вопросы. RMI это всего лишь спецификация, которая сводится, грубо говоря, к классу RemoteException. JBossRemoting, кстати, поддерживает эту спецификацию. Именно поэтому у них получается "it is how easy has been to move from Java RMI to JBoss Remoting". Нет ничего, что не давало бы использовать тот же JBossRemoting как транспортный уровень Jini.
СБ>Вот что в мире происходит. СБ>http://www.theserverlabs.com/blog/2009/02/19/jboss-remoting-jboss-serialization-kills-javarmi-and-spring-remoting/ СБ>Смигрировался на jboss remoting 2, да быстро, просто, конфигурабельно. СБ>Но код сырой, эксепшоны глотаются в пару важных местах, и нету файл-овер фичи. СБ>Решил сам дописать, но перед этим совета спросить у вас. А стоит ли?
Начальник ругается на 40% накладные расходы при передаче данных по сети, но готов выделить время на серьёзную системную доработку сырого стороннего софта? А времени ведь потребуется немало, в том числе и на тестирование. Не советую, завязнете.
Программа для клиента вообще через вебстарт работает у меня сейчас.