1) чем лучше? думаю в случае в javaagent целостность решения лучше, все происходит в одном месте, приложение само под себя настраивает VM
2) а по другому наверно и нет возможности, только писать свой SecurityManager
задача стоит так: нужно не запретить, а иметь возможность держать контроль над потоками
основной поток создается веб сервером, нет возможности управлять его группой. как вариант из основного потока создавать новый поток в отдельной группе и из под него уже запускать скриптинг. Спасибо за наводку, буду думать в эту сторону тоже.
да, но пул конектов к БД как раз таки всегда инициализируется до сервиса скриптинга, сами скрипты лежат в БД, т.е. запуск скрипа на выполнение уже предполагает наличие инициализированного пула. да и в целом система построена так, что пул конектов к БД всегда инициализируется раньше каких либо пользовательских скриптов.
Действительно, в системе, предполагается принудительное завершение дочерних потоков, которые не уложись в таймаут, все что породили пользовательские скрипты умрет после порога ожидания.
Возможно, выплывут какие-то дополнительные подводные камни, о которых пока не известно. Переключить галочку на запрет всегда успеется. Но, на данный момент на горизонте нет препятствий.
запрет это крайняя мера присечения. проблемы всегда были и будут. были проблемы куда похлеще рассмотренной, но все они постепенно решились.
> Например, некоторые действия порожденной нити вызвали появление глобального пула объектов, пополняемого уже нитью этого пула. И эта нить будет включена в иерархию вместо того, что бы быть обособленной.
честно говоря недогнал суть проблемы, может примерчиком объясните?
вопрос вот в чем, получается что я могу получить ссылку на поток-родитель только изнутри ребенка, а в моем конкретном случае надо иметь связи извне, т.е. контроль производит внешний класс, который перебирает потоки и хочет знать кто родитель каждого потока.
добавить поле не получится — redefineClasses будет ругаться, я в статье описал что: переопределение класса не должно добавлять, удалять новые поля или методы, менять сигнатуру методов или иерархию наследования, можно менять только тело методов, структура класса меняться не должна.
а можно поподробнее про CFLOW и контроль вызова классов в разных частях?
ну т.е. запретив вызывать new Thread() — автоматически заблокируются все вызовы этого конструктора из всех стандартных классов, т.о. много стандартных классов будут нерабочими.
как же TimerThread примет ManagedThread если у него по умолчанию нет для этого интерфейса?
При запрете вызова new Thread() — я запрещу вызывать конструктор new TimerThread(TaskQueue taskqueue).
Относительно запрета инстациирования спасибо, так и предполагалось, даже исходники гугля просмотрел :), думал может еще есть какие альтернативные варианты.
хорошо заметили относительно threadQ — есть опасения про использование в native. Так ка информации я не нашел, придется проверять на «собственной шкуре».
в добавок не хотелось бы обрезать доступность класса стандартного Thread, так как на него завязано много других стандартных классов классов типа TimerThread и прочие.
если можно опишите детальнее как вы предполагали запретить инстанциирование стандартного Thread, возможно это пригодится в дальнейшем в других местах…
хочу поправиться — не рассматривалось решение на базе AspectJ, в статье приведен пример решения на базе библиотеки javassist, которая как раз таки и реализует AOP.
нет, не рассматривал. Было бы великолепно если бы смогли привести альтернативный вариант реализации с использованием AOP! будет прям два решения в одном топике.
2) а по другому наверно и нет возможности, только писать свой SecurityManager
задача стоит так: нужно не запретить, а иметь возможность держать контроль над потоками
Действительно, в системе, предполагается принудительное завершение дочерних потоков, которые не уложись в таймаут, все что породили пользовательские скрипты умрет после порога ожидания.
Возможно, выплывут какие-то дополнительные подводные камни, о которых пока не известно. Переключить галочку на запрет всегда успеется. Но, на данный момент на горизонте нет препятствий.
> Например, некоторые действия порожденной нити вызвали появление глобального пула объектов, пополняемого уже нитью этого пула. И эта нить будет включена в иерархию вместо того, что бы быть обособленной.
честно говоря недогнал суть проблемы, может примерчиком объясните?
вопрос вот в чем, получается что я могу получить ссылку на поток-родитель только изнутри ребенка, а в моем конкретном случае надо иметь связи извне, т.е. контроль производит внешний класс, который перебирает потоки и хочет знать кто родитель каждого потока.
а можно поподробнее про CFLOW и контроль вызова классов в разных частях?
При запрете вызова new Thread() — я запрещу вызывать конструктор new TimerThread(TaskQueue taskqueue).
Относительно запрета инстациирования спасибо, так и предполагалось, даже исходники гугля просмотрел :), думал может еще есть какие альтернативные варианты.
в добавок не хотелось бы обрезать доступность класса стандартного Thread, так как на него завязано много других стандартных классов классов типа TimerThread и прочие.
если можно опишите детальнее как вы предполагали запретить инстанциирование стандартного Thread, возможно это пригодится в дальнейшем в других местах…