|
From: Yauheni A. <ea...@in...> - 2009-03-12 13:48:16
|
Доброго дня! Пока в Google-группе SObjectizer активно обсуждаются средства контроля за перегрузкой агентов для SObjectizer-5, на днях в очередной раз возникла ситуация, когда подобный контроль оказался бы не лишним в SObjectizer-4. В связи с этим родилась следующая идея. Поскольку в SO4 нет возможности проконтролировать размер очереди сообщений на одного агента, то остается контролировать размер очереди для каждой рабочей нити. И в этом, в принципе, есть смысл. Если в какой-то группе агентов, разделяющих общий контекст, обнаруживается "тормоз", то можно сделать жертвами всех этих агентов. Т.е. каждое лишнее сообщение для этой нити будет выбрасываться вне зависимости от того, идет ли оно "быстрому" или "медленному" агенту. Получится, что программист сможет дать указание диспетчеру о том, каковы максимальные размеры очередей для его нитей (в идеале, такое указание должно быть возможно для конкретной нити). Далее диспетчер будет контролировать этот размер. И, если очередь на конкретной нити переполнится, выбросит лишнее сообщение. С выбрасыванием сообщений ситуация видится так. По умолчанию, сообщение можно выбросить. Но, могут быть сообщения, которые нельзя выбрасывать, даже не смотря на перегрузку. Например, сообщение о завершении работы или о появлении/исчезновении каналов связи. Такие сообщения специально помечаются как не подлежащие выбрасыванию. Они ставятся диспетчером даже в переполненную очередь. Так же есть сообщения, выбрасывание которых должно приводить к какой-нибудь реакции. Например, сообщение о прочитанном из канала пакете. Выбрасывание этого сообщения должно означать разрыв канала. Для реализации этого сообщению можно назначить обработчик "выбрасывания". Когда сообщение выбрасывается, этот обработчик задействуется. Так, для сообщения о входящих данных можно будет назначить обработчик, который принудит транспортного агента закрыть канал. Вот как-то так. Сейчас я приступил к разработке SO 4.4.0-beta7. Хочу реализовать эту схему контроля в ней. -- Regards, Yauheni Akhotnikau Chief Developer Intervale, http://www.intervale.ru e-mail:ea...@in... <mailto:ea...@in...> |