Блог

Возможно ли (… прекрасно понимая, что это безумие и серьезно опрометчивый совет …) запустить приложение J2EE на сервере приложений Java (использующем weblogic в настоящее время) и запустить собственный исполняемый процесс, используемый и остановленный как часть жизненного цикла этого Java-приложения? (Примечание: это не JNI, на самом деле это отдельный собственный процесс. Это unix / Linux, но он также должен работать в Windows.) Я не нашел никаких документов по этому вопросу — и, вероятно, на то есть веская причина.

Справочная информация: Собственный процесс на самом деле представляет собой некоторый монолитный программный пакет сторонних разработчиков, который невозможно взломать, и нет никакого API, кроме stdin / stdout. Java-приложению требуется собственное приложение для выполнения определенных служб. Я могу легко обернуть собственный процесс с помощью ProcessBuilder и запустить / остановить и взаимодействовать с ним (используя stdin / stdout). Для целей тестирования у меня есть простой exe (C ), который обменивается данными через stdin / stdout и может получать «запуск», «завершение работы» и выполняет простую службу «echo». («Запуск» — это не операция, но просто возвращает «ok», если собственный процесс запущен успешно.)

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

Если бы это действительно работало, то «часть 2» вопроса заключалась бы в том, могло ли это действительно работать в среде кластера / отработки отказа. Собственный процесс может быть привязан к платформе и программно-ориентированной службе мониторинга и управления, но я бы хотел, чтобы все было объединено и управлялось с помощью Java-приложения, если это возможно.

Если Glassfish или любая другая среда типа OSGi упростит это, пожалуйста, не стесняйтесь, дайте мне знать (это может быть вариантом… Я бы предпочел Glassfish, но WLS — это общий мандат.)

Я пытаюсь составить доказательство концепции, но любой четкий ответ «да, я это сделал» или «нет, это не сработает» был бы высоко оценен и значительно сэкономил бы время (со ссылками на вспомогательные документы, если они у вас есть).

Редактировать: просто для пояснения (тема может вводить в заблуждение): также запущено значительное Java-приложение (которое я написал и могу свободно изменять по мере необходимости); сторонний собственный процесс просто выполняет службу, которая требуется Java-приложению. Я не просто пытаюсь управлять собственным процессом через сервер приложений.

Ответ на часть 1 — да, абсолютно возможно, чтобы сервер приложений Java управлял собственным системным процессом. Похоже, вы в значительной степени разобрались в этом сами, если подумываете об использовании ProcessBuilder для создания внешней программы и взаимодействия с ней. Это в значительной степени способ сделать это.

В прошлом я использовал именно такую настройку для реализации службы транскодирования мультимедиа поверх сервера Java (сервер Java запускал задания транскодирования через процессы ffmpeg, отслеживал их состояние и сообщал остальным приложениям об успехе / сбое и т.д.). Насколько чисто все это может быть выполнено, зависит от того, как вы это реализуете и от поведения вашего внешнего приложения (т. Е. Гарантировано ли, что оно изящно и быстро отреагирует на запрос о завершении работы?), Но это будет будет очень сложно (если не невозможно) сделать его полностью совершенным. Как минимум, если кто-то выполняет kill -9 на вашем Java-серверном процессе, у вас нет возможности корректно завершить собственный процесс, по крайней мере, до тех пор, пока сервер не будет перезапущен и вы не увидите, что собственный процесс уже запущен.

Вторая часть зависит от того, что именно вы подразумеваете под «работой в среде кластера / отработки отказа». Что касается управления собственным процессом, если вы можете запустить его и взаимодействовать с ним на Java, то вы также можете управлять им на Java. Но если вы имеете в виду, что вам нужно идеальное поведение при отказоустойчивости, такое, чтобы, если узел с собственным процессом на нем выходил из строя, новый узел автоматически возобновлял процесс в точно таком же состоянии, в каком он был раньше, то это может быть очень сложно или даже невозможно. Но, если вы абстрагируетесь от взаимодействий с внешним процессом, чтобы он просто отображался как сервис, с которым взаимодействует ваш Java-код (например, возможно, отправляя запросы в некоторый класс facade, который понимает, как взаимодействовать с внешним процессом и управлять им), тогда вы сможете получить довольно хорошие результаты.

Внедренная мной служба перекодирования работала в кластеризованной среде (с использованием JBoss / Tomcat), и способ ее работы заключался в том, что при запросе задания перекодирования отправлялось сообщение. Это сообщение было бы получено координирующим классом, который управлял бы очередью запросов на перекодирование, порождая задания по мере того, как рабочие процессы становились доступными. Состояние очереди было реплицировано по всему кластеру, поэтому, если узел, выполняющий процессы ffmpeg, вышел из строя, текущие запланированные задания будут запомнены, а затем возобновлены, как только подходящий узел снова станет доступен (служба перекодирования была настроена таким образом, что ее можно было включать / отключать для каждого узла). На практике система оказалась довольно надежной.