Приложение - программа тех анализа для биржевых торгов.

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

Стратегия может получать некие данные от ядра, при этом используется синхронизация на источниках данных. 

Запущенную стратегию необходимо уметь останавливать в любой момент.
Если использовать Thread.stop(), то как и гласит документация к java, все блокировки снимаются, и источники данных могут оказаться "damaged" (избежать этого не получается).

Может быть, кто-то встречался с подобной проблемой и знает, как ее решить?
На ум приходит только catch(ThreadDeathError) - и попытка "починить" источники данных.

Подскажите, кто что знает.
Заранее спасибо.

По-моему, проверка вида

не настолько сложна для понимания.

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

Была подобная задача, расскажу свое решение, хотя может оно и далеко не лучшее.

Так же есть пользовательский код, который что-то делает и использует какие-то (условно) "ресурсы".

Со stop лучше не эксперементировать, все-таки даже сановцы пишут о нежелательности твоего метода (обработка ThreadDeathError)



Завершать поток лучше с Thread.interrupt() и все-таки!!! просить юзеров после длительных операций проверять .interrupted().

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

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

Все(!)  внешние ресурсы скрипт получает через методы типа ApplicationContext.getResource(...), где в параметрах он описывает что за тип ресурса он хочет (в моем примере - это телефонные ресурсы типа ISDN-каналов, голосовые и факс-каналы).

Соответственно наш ApplicationContext знает, какие ресурсы какой скрипт взял себе.

При необходимости застопить поток выполняем:

1. выставлем флаг, что поток должен убит - следовательно новых ресурсов он уже не получит
2. делаем Thread.interrupt()
3. ждем Nнное количество времени на корректное завершение (можно исключить этот этап)
4. принудительно освобождаем и подчищаем ресурсы, занятые скриптом, если они еще не были освобождены и подчищены.
Закрываем все коннекшены к базе, http и прочее.

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

Но это сложнее и обычно не требуется

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

P.S. А кстати не удобнее ли тебе будет вместо компилирования java работать со скриптами. Вроде бы для неискушенных людей проще скриптовать.
Или там 6 jre нельзя поставить?

С одной стороны, проверка на interrupted - на самом деле не очень уж сложна.
И всякие ресурсы у меня тоже через через подобие ApplicationContext.
НО.. Если в конце концов пользовательский "шедевр" может и просто в бесконечный цикл войти..  
А в другом Thread'е другой шедевр (получше) в этот момент может торговать реальными (причем не моими, и не маленькими) деньгами. И хотелось бы, чтобы шедевр №1 можно было гарантировано убить. 

В принципе, во всей программе только 2 класса могут быть серьезно damaged в случае остановки стратегии.. остальные - максимум в кэш поместить не успеют что-то.. и если сановцы рекомендуют не использовать ThreadDeathError только из-за сложности, то в моем случае это кажется реализуемым.

kkorsakoff, а по поводу компилирования vs скриптинг - производительность критична.

Если нельзя, но очень хочется, то можно