Здравствуйте, Сеня Белдыев, Вы писали:

СБ>Да это всё здорово.
СБ>Но 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% накладные расходы при передаче данных по сети, но готов выделить время на серьёзную системную доработку сырого стороннего софта? А времени ведь потребуется немало, в том числе и на тестирование. Не советую, завязнете.