Amazon SWF: co najmniej jeden pracownik musi być uruchomiony, dlaczego?

Question

Właśnie zacząłem używać pakietu Ruby SDK AWS do zarządzania tak prostym przepływem pracy. Od razu zauważyłem, że przed złożeniem nowego przepływu pracy musi być uruchomiony co najmniej jeden odpowiedni pracownik i jeden odpowiedni decydent.

Jeśli przed uruchomieniem mojego pracownika i decydenta złożę nowe zlecenie, zadania nigdy nie zostaną odebrane, nawet jeśli nadal znajduję się w granicach limitu czasu. Dlaczego to? Opierając się na opisie działania długich sondowań HTTP, oczekiwałbym, że każda aplikacja otrzyma odpowiednie zadania po osiągnięciu połączenia z odpytaniem().

Występują inne sytuacje zakleszczenia po niepowodzeniu zadania (np. Z powodu błędu pracownika lub sprawcy lub z powodu rozwiązania). Czasami ponowne uruchomienie lub nawet rozpoczęcie całkowicie nowego przepływu pracy spowoduje zablokowanie przepływu pracy. Początkowe zadania decyzyjne są wyświetlane w historii wykonania przepływu pracy w konsoli AWS, ale decydent nigdy ich nie otrzymuje. Wprawdzie mam problem z potwierdzeniem/zredukowaniem tego problemu do przypadku testowego, ale podejrzewam, że jest on związany z powyższym problemem. Dzieje się to w przybliżeniu od 10 do 20% czasu; przez resztę czasu wszystko działa.

Kilka innych rzeczy, o których warto wspomnieć: Używam pojedynczej listy zadań dla dwóch osobnych zadań, które są uruchamiane kolejno. Zarówno pracownik, jak i decydent odpytują tę samą listę zadań.

Oto mój pracownik:

 

require 'yaml' 
require 'aws' 

config_file_path = File.join(File.dirname(File.expand_path(__FILE__)), 'config.yaml') 
config = YAML::load_file(config_file_path) 

swf = AWS::SimpleWorkflow.new(config) 

domain = swf.domains['test-domain'] 

puts("waiting for an activity") 
domain.activity_tasks.poll('hello-tasklist') do |activity_task| 

    puts activity_task.activity_type.name 
    activity_task.complete! :result => name 

    puts("waiting for an activity") 
end 
 

EDIT

Inny użytkownik na forum AWS komentuje:

Myślę, że przyczyna jest w SWF nie od razu rozpoznając długą ankietę zamknięcie połączenia. Po zabiciu pracownika jego połączenie może zostać uznane za otwarte przez serwis. Więc nadal może wysłać zadanie do niego. Dla ciebie wygląda na to, że nowy pracownik nigdy tego nie dostanie. Aby to sprawdzić, sprawdź historię przepływu pracy. Zobaczysz zdarzenie uruchamiania zadania z polem identyfikacyjnym zawierającym host i pid zwłok pracownika. W końcu takie zadanie zostanie przerwane i może zostać ponownie sprawdzone przez decydenta.

Należy zauważyć, że taki stan występuje często podczas testów jednostkowych, które często kończą połączenia i tak naprawdę nie stanowią problemu dla jakichkolwiek aplikacji produkcyjnych. Typowym rozwiązaniem jest użycie innej listy zadań dla każdego testu jednostkowego.

To wydaje się być całkiem rozsądnym wyjaśnieniem. Spróbuję to potwierdzić.

Answer 1

Podniosłeś dwie kwestie: jedną dotyczącą rozpoczęcia egzekucji bez aktywnych decydentów i drugą dotyczącą aktorów upadających w trakcie zadania. Pozwól, że zwrócę się do nich po kolei.

Przeprowadziłem eksperyment na podstawie twoich obserwacji. Rzeczywiście, kiedy rozpoczyna się nowe działanie workflow i nie ma sprawców, SWF wciąż uważa, że ​​zaczyna się nowe zadanie decyzyjne. Poniżej znajduje się mój dziennik zdarzeń z konsoli AWS. Zauważ, co się dzieje:

Fri Feb 22 22:15:38 GMT+000 2013 1 WorkflowExecutionStarted 
Fri Feb 22 22:15:38 GMT+000 2013 2 DecisionTaskScheduled 
Fri Feb 22 22:15:38 GMT+000 2013 3 DecisionTaskStarted 
Fri Feb 22 22:20:39 GMT+000 2013 4 DecisionTaskTimedOut 
Fri Feb 22 22:20:39 GMT+000 2013 5 DecisionTaskScheduled 
Fri Feb 22 22:22:26 GMT+000 2013 6 DecisionTaskStarted 
Fri Feb 22 22:22:27 GMT+000 2013 7 DecisionTaskCompleted 
Fri Feb 22 22:22:27 GMT+000 2013 8 ActivityTaskScheduled 
Fri Feb 22 22:22:29 GMT+000 2013 9 ActivityTaskStarted 
Fri Feb 22 22:22:30 GMT+000 2013 10 ActivityTaskCompleted 
... 

Pierwszym zadaniem decyzja została natychmiast zaplanowane (co jest spodziewane) i zacząć od razu (to rzekomo wysłane do rewanżu, choć nie decider został uruchomiony). W międzyczasie rozpocząłem decyzję, ale przepływ pracy nie przesunął się do czasu przekroczenia limitu czasu pierwotnego zadania decyzyjnego, 5 minut później. Nie mogę wymyślić scenariusza, w którym byłoby to pożądane zachowanie.Dwie możliwe mechanizmy obrony przed tym: przed rozpoczęciem nowej egzekucji należy podjąć decyzje lub ustawić dopuszczalnie niski limit czasu na zadaniu decyzyjnym (zadania te powinny być natychmiastowe).

Kwestia upadłego aktora (decydenta lub pracownika) to taka, którą znam. Krótki tle pierwsza uwaga:

zarówno aktywności oraz decyzja zadania recored przez serwis w 3 etapach:

• Planowana = gotowy do odbioru przez uczestnika.
• Rozpoczęty = już odebrany przez aktora.
• Wykonane/Nieudane lub Przekroczono czas = aktor lub zakończono nie powiodło się lub nie ukończyło zadania w terminie.

Gdy aktor odebrał zadanie i rozbił, to oczywiście nie zamierza zgłosić coś z powrotem do służby (chyba jest w stanie odzyskać i wciąż pamięta zadanie żeton od wysłanej zadania - ale najbardziej upadający aktorzy nie byliby tacy inteligentni). Następnym razem, gdy zaplanowane zostanie zadanie decyzyjne, nastąpi przekroczenie limitu czasu ostatnio wysłanego zadania, dlatego wszyscy aktorzy wydają się być zablokowani na czas trwania limitu czasu zadania. Jest to właściwie pożądane zachowanie: usługa nie może wiedzieć, czy zadanie jest w toku, czy nie, dopóki pracownik nadal pracuje w wyznaczonym terminie. Jest prosty sposób, aby sobie z tym poradzić: dopasuj swoich aktorów do bloku try-catch i nie wykonuj zadania, gdy dojdzie do niespodziewanej awarii. Odradzałbym używania oddzielnych list zadań dla każdego testu integ. Zamiast tego zaleciłbym pominięcie zadania w bloku teardown(). SWF pozwala określić reason na niepowodzenie zadania, które jest jednym ze sposobów rejestrowania błędów i przeglądania ich później za pośrednictwem konsoli AWS.