Как сделать так, чтобы данные объектов были в одном приложении, а их методы выполнялись в другом приложении? Аналогично механизму share memory во FreeBSD...

Например, в запущенном приложении Keeper есть объект 



В запущенном приложении Utilizateur происходят операции с объектом.



Приложение Utilizateur использует методы и оперирует над данными объекта point59 в другом приложении Keeper.
Это нужно для того, чтобы если Utilizateur попытается чего-то сделать неправильно, например завалится от деления на ноль, то Keeper будет продолжать работу, сохранив все данные.

Как это сделать?

Заранее признателен за подсказку в направлении, куда копать...

rmi?

rmi?

RMI сериализует/десериализует объекты, и фактически Utilizateur будет оперировать своим point59.
А нужно, чтобы Utilizateur оперировал объектом point59, который принадлежит приложению Keeper.

Например, на одной JVM на одном хосте выполняются два приложения. Может ли одно приложение получить прямой доступ к объектам другого приложения и оперировать с ними, как со своими объектами в пределах одной JVM?

Может. Но для этого нужно слишком много условностей. Во-первых, объект класса нужно сделать статическим. Во-вторых, должен существовать один экземпляр класса. Хочу напомнить, что в Java возможна сложная иерархия класслоудеров и экземпляров классов может быть много, следовательно, и экземпляров статических классов тоже. Для того, чтобы был один экземпляр, в JVM должен быть только один экземпляр файла класса. Поэтому лучше поискать альтернативную возможность хранения общих данных. Например, базу данных или сериализацию на диск.

Речь идёт не о хранении общих данных. Для этого достаточно СУБД. Но СУБД не хранит методы объектов, насколько я знаю, методы не сериализуются.

Смысл shared memory в данном случае в том, что выход из строя приложения Utilizateur не приведёт к потере данных, которые находятся в работающем приложении Keeper. Ведь приложение Utilizateur использует не свои объекты, а объекты (методы и данные) Keeper'a.

Вот например в SAP JVM сделано так, что разные приложения могут помещать объекты в shared memory и совместно использовать эти объекты. 

Можно сделать через MappedByteBuffer (правда работать с ним не удобно):

LSD, шарить нужно не данные, а объекты :о)
Из вашего кода я не понял, как Утилизатор сможет пользоваться объектами Кипера.

Попробую переформулировать на живом работающем примере на С.

Запускаю:

prol@corphangar> CorporationApplication -Keeper

Приложение запускается, распределяет память и остаётся в режиме кипера, ничего не делает.

Запускаю вторую копию этого же приложения

prol@corphangar> CorporationApplication -Utilizateur

С помощью механизма shm второе приложение работает над данными первого приложения с помощью функций первого приложения, в том числе делает new и dispose, новые объекты создаются и удаляются в общей shared memory, и первое приложение, которое ничего не делает в sleep'e, при этом владеет всеми новыми объектами.

Так как первое приложение ничего не делает, то оно и не падает. А вот если второе приложение свалится по какой-либо причине, то в первом приложении останутся все данные целыми. :о)

Как сделать такое на Java? 
Чтобы второе приложение использовало объекты первого приложения?

Объекты шарить между разными JVM - нельзя (во всяком случае стандартные реализации этого не позволяют).

А можно ли шарить объекты между приложениями внутри одной JVM?

Да, только они должны использовать один и тот же класс лоадер.

Извините, я ещё не владею достеменно понятиями Java, поэтому объясните, как в одной JVM могут быть разные класслоадеры.

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

Очень даже запросто, если это какой-то  J2EE сервер, то они даже будут разными. Но в обычном приложении он как правило один.



Да обычный синглетон например:

все потоки используют один и тот же экземпляр Runtime.

Как самому сделать такой "синглетон", одни объект, который могут использовать одновременно два моих приложения?

а с помощью JNDI не получится?

JNDI хранит сериализованные объекты (как я понял, методы не сериализуются). 

Но я веду речь не о том, как хранить совместно используемые данные (свойства объектов), а как использовать один и тот же объект из разных приложений одновременно :о)

С помощью статической переменной:



Это сообщение отредактировал(а) batigoal - 11.1.2008, 14:55

Дык оно же будет создавать новый синглтон для каждого приложения, которое пользуется им :о)

А как сделать синглтон, который создан одним приложением и виден из другого приложения, которое в это время запущено одновременно с приложением, которое создало синглтон?

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

Но ведь в одной JVM один загрузчик классов?
То есть если я сейчас запущу приложение c вашим синглтоном, то второе запущенное приложение его увидит и не будет делать new?

Это сообщение отредактировал(а) Prol - 11.1.2008, 15:19

Prol
Ты не создаешь новый экземпляр через new в этом случае, а получешь единственный через MySingleton.getInstance() -- в это суть паттерна: используется только один экземпляр класса, который хранится в статике.

Извините, я новик, у меня не получается сделать приложение с вашим синглтоном :о(

Это просто предупреждение, что объявленная переменная, в общем-то, не нужна. Оно не препятствует выполнению программы.

Prol, вы явно хотите использовать java не по назначению, т.е. преодолеть существующие защитные механизмы java, используемые для повышения надежности программ. Идея сделать на java как на C - не продуктивна.  
Если работа с данными происходит в отдельном потоке и происходит деление на ноль, то выбрасывается исключение и этот поток может спокойно умереть. Если этот поток не модифицировал данные, то данные будут в сохранности и приложение продолжает функционировать. 

Это сообщение отредактировал(а) COVD - 11.1.2008, 17:50

Нет, не один.

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

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

Не оставит, потому что снимать его будет ОС за оперейшен эксепшен или другое подобное.

Точнее, если второе приложение оставило белиберду, то и первое в этом же месте оставило бы точно такую же белиберду :о) Первое и второе приложение совершенно одинаковы. А значит надо править неправильный код приложения.

Но вот в случае исключительных ситуаций, связанных с вводом-выводом, делением на ноль или подобным, данные сохраняют целостность, а ОС убивает виновника, то есть второе приложение, сохранив при этом работающее первое, которое мне присылает смс, я смотрю, почему ОС убила второе приложение, если исправления в коде не требуются, то перезапускаю второе приложение, которое опять подхватывает shared memory, находящуюся в первом приложении и работает :о)



Это сообщение отредактировал(а) Prol - 11.1.2008, 22:29

RMI или ему подобное. Другие варианты извращение...

Как вы себе представляете работу RMI с тремя миллионами объектов? Сколько будет длиться сериализация/десериализация трёх миллионов объектов?

А у меня уже несколько лет работают реалтайм приложения на С по схеме с шаред мемори. Одно держит методы и данные, а второе использует методы и данные первого приложения прямо в памяти. Когда второе приложение падает, первое продолжает работать, и сохранять данные тысяч пользователей.

Если вы скажете, что в Java такое невозможно, то я вам приведу в пример SAP JVM, которая позволяет шарить объекты прямо в памяти между несколькими JVM.

Это сообщение отредактировал(а) Prol - 12.1.2008, 06:48

1. Зачем нужна сериализация/десериализация трех миллионов объектов. Это равносильно выгрузке 4 гиговой БД в ОЗУ!
2. Судя по проблеме надо шарить методы для других приложений, а не три миллиона объектов
3. Приложение которое сохраняет объекты это обычно БД!

Вопросы:
1. Вы пишете свою базу данных? 
2. Для каких целей  нужна сериализация/десериализация трех миллионов объектов?
3. Вы держите в ОЗУ три миллиона объектов?

p/s
Такое ощущение что архитектура приложения очень сильно хромает!

Потому что RMI сериализует/десериализует объекты между приложениями.

Добавлено через 1 минуту и 52 секунды

Шаман!  

Ключевое слово здесь три миллиона объектов, зачем так много передавать?

Больше... :о)

Это риалтаймовые объекты, свойства которых обновляются от контроллеров, которые присылают данные с датчиков... Их нельзя не держать в памяти, потому что моё приложение обязано откликнуться на любое событие не позднее, чем через восемь миллисекунд. Дропать события тоже нельзя, за это тюрьма.

Добавлено через 13 минут и 5 секунд

Чтобы при снятии системой одного из приложений, другое сохранило доступ ко _всем_ объектам, с которыми они работали, и возобновило работу.

В данном случае я бы использовал очень быстрый сервер БД (на очень быстром железе), возможно Oracle...

ИМХО Java не очень подходить для систем реального времени, по крайней мере с использованием стандартной Java машины от SUN. 

p/s
А что делать с данными в ОЗУ если даст сбой железо или выключат свет? тюрьма? можно не отвечать

:о)))

Почему же? Байткод Java ненамного уступает ассемблеру по скорости выполнения, но писать на нём намного легче. Кроме того, у Java отличная переносимость. То, что у SUN ещё нету шаред мемори - это вопрос времени и требований разработчиков...

Добавлено через 1 минуту и 9 секунд

За сбой питания я не отвечаю :о) Пусть хоть там все передеруцца...

А каким образом вы решили проблему со сборщиком мусора в Sun JVM? Его работа может занять гораздо больше 8 миллисекунд, причем в неопределенные моменты времени.

Мои приложения на С.

Я хочу их портануть на Java, потому что мне так кажется удобнее передать моему наследнику и уйти на пенсию. :о)

На Питон тоже можно, но если эти охламоны видят в операторе (_*_) разорванную жопу, а не умножение предыдущего выражение самого на себя (возведение в квадрат), то уж пусть лучше пишут на Java...

Это сообщение отредактировал(а) Prol - 12.1.2008, 08:33

Боюсь это плохо кончится для наследника. Сборщик мусора - это как раз одна из тех причин, по которой обычные JVM не используются в приложениях реального времени. Есть спецификация Real-time Java, начать можно отсюда - http://en.wikipedia.org/wiki/Real_time_Java.

Я знаком с нею - она дропает входящие события, типа я не видела того, на что не успеваю отвечать.

Поэтому я и спросил про шаред мемори - проверенный механизм.

Мне как-то не совсем понятен разговор про shared memory, рецепт которой, кстати, уже предложили - синглтон, но с ограничениями по загрузке классов о которой я говорил, если сама Java не подходит под задачу. Или таки 8 миллисекунд - это не жесткое ограничение?

Насколько я знаю, этим можно управлять.

Prol
Возможно я пропустил.. А в каком окружении работает ваше приложение (ОС, железо)? И куда физически приходит инфомация с датчиков (порты)? Интересно. Если не секрет.

ЗЫ. Насколько я знаю, для реалтаймовых систем используются заточенные под это дело операционный системы, типа QNX.

Ну вы развели!..  

Надо начать с описания задания. Что нужно сделать конкретно. А то завели спор, как микроскопом гвозди забивать..
Теоретические споры тоже умесны, но до определённого предела. Вроде он уже достигнут.

Нужны факты.   

ps. Построить можно что угодно, но насколько рационально.

FreeBSD 4.12
Железо нормальное :о)

Данные приходят на сетевой порт :о) Трафик порядка терабайта в месяц :о)

Добавлено через 2 минуты и 50 секунд

Не имеет значения, что делает приложение.
Я описал работающий метод защиты от сбоев приложения с использованием механизма shared memory и спросил, возможно ли сделать такое не для приложения на С, а для приложения на Java ? 

По поводу расшаривания объектов, есть предложение посмотреть в сторону JMX (Java Management Extensions). Я с этой технологией не работал, но на сколько знаю, она позволяет одной JVM подключиться к другой и, грубо говоря, дернуть метод у объекта. В целом JMX создавалась как средство мониторинга Java приложений.

Банальный вопрос а зачем?

Ещё хуже. Зачем делать так же как на с?

 ,  но не совсем..
Язык определяет мышление. Нельзя на одном писать средствами другого.

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

Как средство управления с универсальным интерфейсом.

http://voituk.kiev.ua/2007/11/08/jmx-hello-world/

около 400к данных в секунду приходит?

Это суммарный входящий/исходящий. Пропорция примерно 100к входящего на 300к исходящего от приложения в секунду.

Добавлено через 11 минут и 40 секунд

Как зачем?

Затем, чтобы обеспечить сохранность данных, разделяемых двумя приложениями, при любых практически сбоях одного из приложений. :о)

Большинство из БД могут удовлетворить этим требованиям. Например Apache Derby (Java DB) прекрастно с этим справится. Просто настройте 2 приложения работать с одной БД. Более того, при работе с БД, вы имеете возможность сохранить данные даже при крахе обоих приложений.

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

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

праивильный ответ 

Ок, я понял, что не могу доходчиво донести. Попробую по другому.

Фаза инициализации более трёх миллионов объектов в памяти занимает более 15 минут. Они читаются из БД и размещаются в памяти одним приложением. В случае, если ОС снимет это приложение, то время повторного перезапуска займёт те же более 15 минут, каковое время недопустимо по требованию заказчика.

Поэтому я запускаю две копии одного приложения. Первая копия при первом старте тратит 15 минут на чтение и размещение объектов в shared memory памяти и падает в sleep.
После того, как я вижу, что первое приложение отинитилось, то запускаю вторую копию этого же приложения. 
Поскольку оба приложения используют shared memory, то второе приложение (оно точно такое же по коду как и первое) получает уже отиниченную память со всеми тремя миллионами объектами и приступает к отработке очереди сообщений всего за одну секунду.

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

Можно ли так сделать на Java?

Добавлено через 3 минуты и 32 секунды

Если умрёт диск (это тоже неважно, потому что диск не используется), ОС снимет второе приложение по сбою ввода-вывода, но первое приложение останется в памяти и сохранит все данные :о)

Грубо говоря, можно ли примерно так? :





Это сообщение отредактировал(а) Prol - 15.1.2008, 04:16

Дальше небольшой  

Помню пришлось дорабатывать код написанный бывшими PHPшниками, это был их первый большой проект на Java. 
Таких извращений в коде я больше никогда не видел Да кстати их проект был переписан с PHP на Java:)

p/s
а оно надо переписывать с си на Java? Ведь работает и устраивает заказчика. А если код стабилен то проще найти нормального сишника!

p/s/s
А сборка мусора это действительно большие грабли для реалтаймовых систем У меня томкет всегда за разное время обрабатывает запросы, иногда бывает что время отличается на порядок (для тестового приложения без бд).

  
А может ли волк понять овцу?

И может ли овца стать волком?

Задачи надо решать средствами языка, иначе будет.. ну что-то на 5 точке ;)

Те я хочу сказать, что простой переделкой кода тут не обойдёшься. Надо переделывать архитектуру системы с точки зрения java и как это на java делается.
Готовы Вы на это пойти, или нет - это Вам решать.

Ну и есть принцип. Работает, не трожь!


Это сообщение отредактировал(а) serger - 15.1.2008, 06:27

Не такие уж и большие грабли - этот garbage collector.
По крайней мере его можно заставить убирать мусор не когда ему требуется, а когда нам требуется.

это не так
Это лишь уведомление о необходимости - jvm САМА решает когда запускать.

gc() - принудительный вызов сборщика мусора.
Когда управление выходит из вызванного gc(), мусор уже убран.

Prol, это ошибка. Вызов сборщика мусора не гарантирован ВАЩЕ. Кое-как им можно управлять с помощью ключей запуска JVM, но это весьма ограниченное управление.

Раньше еще использовался такой прием - вызов gc() несколько раз подряд. Сейчас даже он уже не прокатывает.

Это сообщение отредактировал(а) batigoal - 15.1.2008, 09:40

да даже если бы и срабатывал сразу, к чему это приводило бы?

Вот тут сайт про JVM.
http://blogs.sun.com/vmrobot/category/GC

или вот есть такие шаманства (отсюда):
Следующий метод освобождает всю возможную память:



Это сообщение отредактировал(а) serger - 15.1.2008, 09:57

Что значит "ошибка"? В одном из базовых классов Java ошибка?

Его нельзя вызывать несколько раз подряд, это асинхронное событие имеющее длительно время исполнения. Сборщик мусора нужно вызывать не в основном потоке приложения, а делать для него отдельный поток и пользоваться как при асинхронном вводе-выводе, наверна, да? :о)

Вообщем пообщался с одним умным человеком

gc() не просто удалят все неиспользуемые объекты из памяти он при вызове решает стоит удалять объекты из пямяти или нет на основе времени жизни объекта, количества свободной (занятой) ОЗУ и т.д.

то есть он попробует почистить память но то что он удалит все неиспользуемые объекты он не обещает.

Так по крайней мере в стандартной Java машине

p/s
Кстати если нужен нормальный runtaime и адекватное время исполнение, то скорее всего надо использовать специальное железо от SUN и специальную сборку Java машины. Но стандартная сборка Java машины для этого точно не подходит! Но это ИМХО.

Что значит "нельзя"? Можно. Но исполняться оно будет долго.


Ошибка заложена уже в самой идее - управлять памятью в managed-языке. Приложение не может управлять своей выполняющей средой, оно может лишь рекомендовать ей что-то сделать, что и подтвержадется приведенным куском доки:



Зачем? В том же фрагменте написано:


Рекомендую почитать статьи по тюнингу сборщика мусора, в Интернете их немало.

Добавлено через 1 минуту и 21 секунду

Для этого и создана Real-Time Java.

Вообщем пообщался с одним умным человеком

gc() не просто удалят все неиспользуемые объекты из памяти он при вызове решает стоит удалять объекты из пямяти или нет на основе времени жизни объекта, количества свободной (занятой) ОЗУ и т.д.

то есть он попробует почистить память но то что он удалит все неиспользуемые объекты он не обещает.

Так по крайней мере в стандартной Java машине

p/s
Кстати если нужен нормальный runtaime и адекватное время исполнение, то скорее всего надо использовать специальное железо от SUN и специальную сборку Java машины. Но стандартная сборка Java машины для этого точно не подходит! Но это ИМХО.

Мы отвлеклись от темы. :о)

Как обратиться к объекту (экземпляру класса), находящемуся в другом приложении?

Я бы тогда пошел по другому пути - повышение надежности и отказоустойчивости.

Например запускаем Application Server у которого работает два приложения - одно хранит данные в некотором кэше (хранилище), другое (логика) - выполняет какие-либо действия с этими данными.

Падение Application Server - ну надо очень постараться. Даже если при выполнении логики что-то отвалится, то хранилище должно (и будет) нормально работать. Сервер просто подымет еще одну копию логики. И все.

Хотя инициализация трех миллионов объектов - это как-то странно.

Вам уже ответили - никак. Связь только через файл, отображаемый на память или сокеты (или любой другой более высокоуровневый механизм).

Ну вообщем-то никто не мешает исполmзовать RMI или просто сокеты для общения приложений. Но правда в таком случае эффективность работы наверняка снизится.
Если же иметь в виду общую память, которую можно разделять между процессами, то это особенности ОС и кроссплатформенность JAVA на такие вещи не рассчитана.

Я бы тоже задумался (как и AntonSaburov) над проектированием системы.

Что подразумевается под "Хранилищем"? Образ памяти или БД?
Application Server предоставляет доступ двум приложениям к одной памяти?

Добавлено через 2 минуты и 17 секунд

Как сделать в Java связь через файл, отображаемый на память?

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