Как изолировать пользовательские сеансы в Java EE?
Мы рассматриваем возможность разработки критически важного приложения на Java EE, и одна вещь, которая действительно впечатлила меня, - это отсутствие изоляции сеансов в платформе. Позвольте мне объяснить сценарий.
У нас есть собственное приложение для Windows (полное решение ERP), которое получает около 2 тыс. LoC и 50 исправлений ошибок в месяц от редких участников. Он также поддерживает сценарии, поэтому заказчик может добавить свою собственную логику, и мы не имеем ни малейшего представления о том, что делает эта логика. Вместо использования пула потоков каждый серверный узел имеет брокера и пул процессов. Брокер получает клиентский запрос, ставит его в очередь до тех пор, пока экземпляр пула не станет свободным, отправляет запрос этому экземпляру, доставляет ответ клиенту и возвращает экземпляр обратно в пул процессов.
Эта архитектура является надежной, поскольку с таким большим количеством разреженных вкладов и настраиваемый скрипт, это Нередко в развернутой версии есть серьезная ошибка, такая как бесконечный цикл, долгое ожидание пессимистической блокировки, повреждение памяти или утечка памяти. Мы реализовали ограничение памяти, таймаут для запросов и простой сторожевой таймер. Когда какой-либо процесс не отвечает правильно и вовремя, брокер просто убивает его, поэтому сторожевой таймер обнаруживает и запускает другой экземпляр. Если процесс выходит из строя до того, как он начал отвечать на запрос, брокер отправляет тот же запрос другому экземпляру пула, и пользователь не знает ни о каком сбое на стороне сервера (кроме журналов администратора). Это хорошо, потому что некоторые экземпляры медленно уничтожаются поддельным кодом, когда они работают с запросами. Поскольку большая часть данных сеанса хранится на клиенте или (в редких случаях) в общем хранилище, кажется, что он работает отлично.
Теперь, рассматривая переход на Java EE, я не мог: Я не могу найти ничего похожего в спецификации или на популярных серверах приложений, таких как Glassfish и JBoss. Да, я знаю, что большинство реализаций кластера обеспечивают прозрачное переключение при отказе с репликацией сеанса, но у нас есть небольшие компании, которые используют нашу систему в простом кластере с 2 узлами (и у нас также есть авантюристы, которые используют систему на сервере с 1 узлом) . Я понимаю, что с пулом потоков ошибочный поток может вывести из строя весь узел, потому что сервер не может его обнаружить и безопасно убить. Вывести из строя весь узел намного хуже, чем убить один процесс - у нас есть развертывания, в которых каждый узел имеет около 100 экземпляров объединенного процесса.
Я знаю, что IBM и SAP знают об этой проблеме, на основании
- http: / /www.trl.ibm.com/people/kawatiya/pub/Kawachiya07vee.pdf, и
- http://java.sys-con.com/node/47362
соответственно. Но, судя по последним JSR, форумам и инструментам с открытым исходным кодом, в сообществе не так много активности.
А теперь вопросы!
Если у вас есть похожий сценарий и использовать Java EE, как вы решили?
Знаете ли вы о предстоящем продукт с открытым исходным кодом или изменение в Спецификация Java EE, которая может решить эту проблему проблема?
У .NET такая же проблема? Можно вы объясняете или цитируете ссылки?
Знаете ли вы о некоторых современных и открытая платформа, которая может решить эту проблему проблема и стоит задача сделать Бизнес-логика ERP?
Пожалуйста, я прошу вас не рассказывать о дополнительных тестах или каких-либо инвестициях в QA, потому что мы не можем заставить наших клиентов делать это на своих собственных скриптах. У нас также есть случаи, когда срочные исправления ошибок должны обходить QA, и, хотя мы заставляем клиента принять это, мы не можем заставить его согласиться с тем, что часть программного обеспечения с ошибками может повлиять на ряд не связанных функций. Это проблема надежных архитектур, а не процесса разработки.
Спасибо за внимание!