Изменения документа Примеры

Сводка

• Свойства страницы (2 изменено, 0 добавлено, 0 удалено)

Подробности

Свойства страницы

Родительский документ

...	...	@@ -1,1 +1,1 @@
1		-Проекты и репозитории.Библиотеки.Движок cccc1808\. ProcessEngine.WebHome
	1	+Проекты и репозитории.Библиотеки.Движок cccc1808\. ProcessEngine.Тема\. Сигналы и триггеры.WebHome

Содержимое

...	...	@@ -24,11 +24,14 @@
24	24	|(((
25	25	Вариант №2:
26	26
27		-Мы просто ставит timerTrigger на условно 1-5-10 минут (насколько важна задержка) и перепроверяем условие завершения.
	27	+Мы просто ставим TimerTrigger на условно 1-5-10 минут (насколько важна задержка) и перепроверяем условие завершения.
28	28	В этом случае будет
29	29
30		-* Из минус: что родительский процесс узнает о завершении дочерних процессов с задержкой (хотя в задержке можно использовать функцию от количества необработанных дочерних процессов, но тогда нужно считать количество или хотя бы что оно не больше N).
31		-* Из плюсов: будет меньше пишущей нагрузки на БД (но больше читающей - на проверку) т.к. у нас не будет CounterTrigger, но будет периодический запрос на проверку завершения всех дочерних процессов (аналогично страхующему триггер). \
	30	+* Из минус: что родительский процесс узнает о завершении дочерних процессов с задержкой.
	31	+Если дочерний процесс падает в ошибку, TimerTrigger все равно будет крутиться и создавать пустую нагрузку.
	32	+* Из плюсов: будет меньше пишущей нагрузки на БД чем в варианте 1 (но больше читающей - на проверку) т.к. у нас не будет CounterTrigger, но будет периодический запрос на проверку завершения всех дочерних процессов (аналогично страхующему триггер).
	33	+* [Расширенный]: Дочерние процессы в блоке wakeup condition проверяют наличие незавершенных процессов.
	34	+** Если все процессы завершены или (незавершенных процессов мало и нет процессов с ошибкой), то можно опубликовать событие на TimerTrigger на сброс или установку минимальной задержки.
32	32	)))
33	33	|(((
34	34	Вариант №3:
...	...	@@ -38,9 +38,44 @@
38	38	За счет такого способа у нас также отсутствует конкуренция передачи сигнала в родительский процесс.
39	39	Но мы ограничены выполнением дочерних процессов одной одной сервиса.
40	40	Сложнее контролировать распределение нагрузки, если будет вложенный параллелизм.
41		-Также решает проблему, если дочерний процесс содержит ожидание (например асинхронный запрос-ответ).
	44	+Также решает проблему, если дочерний процесс содержит ожидание (например асинхронный запрос-ответ), тут будет конкуренция сигнала от хендлера ответа к родительскому процессу.
42	42	)))
	46	+|(((
	47	+Вариант №4:
	48	+
	49	+SimpleStreamTrigger + Timer (один из лучших вариантов).
	50	+
	51	+* Триггер проверяет условие завершения всех дочерних процессов (можно прикинуть количество незавершенных дочерних процессов).
	52	+** Если все обработано, то пробуждает процесс и деактивируется.
	53	+** Иначе:
	54	+*** деактивируется (до поступления хотя бы одного сигнала),
	55	+*** взводит признак стрима - процесс ожидает,
	56	+*** взводит флаг новых сигналов на 0,
	57	+*** выставляет задержку от оценки количества необработанных процессов (< N - малая задержка, иначе большая задержка).
	58	+* [Расширенный]: Дочерние процессы в блоке wakeup condition проверяют наличие незавершенных процессов.
	59	+** Если все процессы завершены или (незавершенных процессов мало и нет процессов с ошибкой), то можно опубликовать событие на SimpleStreamTrigger на сброс или установку минимальной задержки (в дополнение к сигналу).
	60	+* Читающей нагрузки будет немного больше чем в варианте 2 (чтение триггера на поступлении сигнала),
	61	+но пишущей нагрузки будет меньше чем в варианте 1 (запись - только на активации новым сигналом).
	62	+* Если сигналов нет, то нет пустых срабатываний в отличие от варианта 2 (т.к. нет поступления сигнала от дочерних процессов).
43	43	)))
	64	+|(((
	65	+|Вариант №5: Trigger + Счетчик в Redis.
	66	+|Дочерний процесс уменьшает счетчик. И публикует событие только если счетчик достиг 0.
	67	+|(((
	68	+Проблема: изменение счетчика не привязано к основной транзакции БД.
	69	+
	70	+Возможно:
	71	+
	72	+1. До коммита транзакции уменьшаем счетчик и записываем id дочернего процесса в redis hashset. Если счетчик 0, то публикуем triggerEvent через TransactionalOutbox.
	73	+(На старте обработки можно удалить из HashSet и если удалили, то увеличить счетчик на 1 - значит была упавшая транзакция).
	74	+1. После коммита транзакции удаляем id дочернего процесса из redis hashset.
	75	+1. Trigger при получении события смотрит значение счетчика и HashSet.
	76	+Если счетчик 0 и HashSet пустой, то скорее всего все корректно и триггер может активироваться.
	77	+Иначе если HashSet не пустой, то можно попытаться проверить статус процесса (если он завершен, то можно удалить значение из HashSet).
	78	+)))
	79	+|Проблемы: Потеря счетчика целиком или искажения значения в случае падения Redis.
	80	+)))
	81	+)))
44	44	|2|(% style="width:188px" %)Transaction outbox stream process.|(% style="width:1268px" %)[[image:TransactionOutbox. Sequence.jpg]]
45	45	|3|(% style="width:188px" %)Stream trigger|(% style="width:1268px" %)(((
46	46	| |(((
...	...	@@ -79,3 +79,27 @@
79	79	|(% style="width:888px" %)Родительский процесс ожидает завершения дочерних процессов (см. пример 1).|(% style="width:266px" %)
80	80	)))
81	81	)))
	120	+
	121	+----
	122	+
	123	+==== Внутренние ссылки: ====
	124	+
	125	+====== Дочерние страницы: ======
	126	+
	127	+{{children/}}
	128	+
	129	+====== Обратные ссылки: ======
	130	+
	131	+{{velocity}}
	132	+#set ($links = $doc.getBacklinks())
	133	+#if ($links.size() > 0)
	134	+ #foreach ($docname in $links)
	135	+ #set ($rdoc = $xwiki.getDocument($docname).getTranslatedDocument())
	136	+ * [[$escapetool.xml($rdoc.fullName)]]
	137	+ #end
	138	+#else
	139	+ No back links for this page!
	140	+#end
	141	+{{/velocity}}
	142	+
	143	+----