Мы готовы общаться с библиотекой C ++, разработанной другой командой из Java.
Естественный и наиболее оптимальный подход, который мы видели, — это использование JNI, но для простоты используйте SWIG во время разработки.
На самом деле мы разработали прототип и работаем хорошо. Существует также связь C ++ -> Java после первой связи Java-> c ++ с использованием SWIG Director.
Основная проблема, с которой мы столкнулись, — это подверженность возможным ошибкам в библиотеке C ++, таким как повреждение памяти и утечки памяти.
Кажется, нет способа эффективно защитить от этих ошибок. Например, выполнение прерывания (имитация некоторой неправильной операции с памятью) в C ++ приведет к остановке JVM
Решение, которое мы подумали, состоит в том, чтобы запустить несколько процессов Java из родительской JVM, которые будут работать в JBoss, и это то, что мы готовы защитить.
Запустить Java-процесс сложно, в основном потому, что для начала требуется JVM.
В этом случае мы решили использовать несколько серверов Nailgun. Каждый из них будет загружать рекламу JVM, будет иметь доступ (в classpath) к программам, которые мы хотим запустить.
Каждая JVM на каждом сервере Nailgun (отношение 1-1) способна одновременно запускать несколько исполнений нашей программы в одной и той же JVM. Если возникает какая-то ошибка, все
казни в этой JVM Nailgun потерпят крах (но JBoss JVM будет жив). По этой причине у нас запланировано несколько серверов Nailgun с ограниченным количеством исполнений.
и использовать какое-то распределение нагрузки для отправки выполнений на любой из серверов. Кроме того, серверы Nailgun будут периодически перезагружаться, чтобы предотвратить
утечки памяти.
Мы считаем, что это хороший подход для защиты от сбоев C ++.
Однако мы хотим спросить сообщество, есть ли лучший подход.
Я забыл упомянуть, что еще одним решением, которое мы рассматриваем, является создание кластерного JBoss с нашей войной по причинам отказа. А потом, может быть, включить сервер Nailgun или нет в зависимости от надежности программы C ++. Преимущество чистого кластеризованного приложения JBoss (без процессов Nailgun) состоит в том, что нам не понадобится никакого межпроцессного взаимодействия, вся операция будет выполняться в процессе с потоками.
Иногда самый простой способ защитить ваш Java-процесс от рисков стороннего нативного кода — запустить опасный код в отдельном процессе.
Однако это может потребовать межпроцессного взаимодействия, что может увеличить стоимость и сложность.
Мне больше нравится кластерный подход, вы будете защищены от сбоев Java (JVM может аварийно завершить работу даже с Pure Java. И бесконечные циклы или ошибки пожирателя всей памяти также могут остановить JVM) и сможете использовать свое решение SWIG.
С другой стороны, если вы боитесь сбоев, вам также следует опасаться повреждения памяти, которое может изменить ваши бизнес-данные.