Was passiert mit laufenden Prozessen auf einem fortlaufenden Azure WebJob, wenn die Website erneut bereitgestellt wird?

Question

Ich habe über anmutige Shutdowns here mit der WEBJOBS_SHUTDOWN_FILE und here mit Cancellation Tokens gelesen, so verstehe ich die Voraussetzung der anmutigen Shutdowns, aber ich bin mir nicht sicher, wie sie WebJobs beeinflussen, die mitten in der Verarbeitung einer Warteschlange Nachricht sind.

Also hier ist das Szenario:

1. Ich habe einen WebJob mit Funktionen Warteschlangen zu hören.
2. Die Nachricht wird zur Warteschlange hinzugefügt und der Job beginnt mit der Verarbeitung.
3. Während der Verarbeitung versucht jemand, sich zu entwickeln und eine erneute Bereitstellung auszulösen.

Angenommen, ich habe meine WebJobs süchtig auf git bereitstellen drückt, wird diese deploy auch die WebJobs auslösen aktualisiert werden, die (soweit ich verstehen) wird eine Art Abschaltung Workflow in den Jobs pfiffen. Also habe ich ein paar Fragen daraus.

1. Werden Jobs, die mitten in der Verarbeitung einer Warteschlangennachricht sind, die Verarbeitung der Nachricht beenden, bevor der Job beendet wird? Oder wird eine Benachrichtigung zum Herunterfahren im Wesentlichen so behandelt, als würde "diese Hündin kurz vor dem Herunterfahren stehen. Wenn Sie nichts damit zu tun haben, sind Sie SOL."
2. Wenn wir SOL sind, ist unsere beste Option, Shutdowns im Wesentlichen so zu behandeln, dass Sie alles, was Sie tun, in DB-Transaktionen umwandeln und Ihren Shutdown-Handler so implementieren, dass alle Änderungen beim Herunterfahren zurückgesetzt werden.
3. Wenn eine Warteschlangennachricht gerade verarbeitet wird und der WebJob beendet wird, wird diese Nachricht erneut gesendet? Wenn nicht, bedeutet das, dass mein Shutdown-Handler die Nachricht erneut anfragen muss?
4. Ist es für Funktionen, die Warteschlangen hören, möglich, weitere Warteschlangennachrichten abzurufen, nachdem der Job benachrichtigt wurde, dass er heruntergefahren werden muss?

Jede Führung hier wird sehr geschätzt! Außerdem, wenn jemand andere nützliche Links hat, wie man Job-Shutdowns außer denen, die ich erwähnt habe, behandelt, wäre es großartig, wenn Sie diese teilen könnten.

Answer 1

Nach nicht wenigen Tests, denke ich, habe ich die Antworten auf meine Fragen gefunden und ich hoffe, dass jemand anderes einen Einblick aus meiner Erfahrung gewinnen kann.

HINWEIS: Alle diese Szenarios wurden mit .NET Console-Apps und Azure-Warteschlangen getestet. Daher weiß ich nicht, wie Blobs oder Tabellenspeicher oder verschiedene Arten von Job-Dateitypen mit diesen verschiedenen Szenarien umgehen.

1. Nach einem Job die ausgelösten Funktionen verlassen markiert wurde, dass die konfigurierte Zeitspanne (Karenzzeit) haben laufen werden (5 Sekunden standardmäßig, aber ich denke, dass configurable by using a settings.job file ist), bevor sie zu beenden sind aufgeregt. Wenn sie in der Kulanzfrist nicht enden, wird die Funktion beendet. Main() (oder die Datei, die Sie host.RunAndBlock() in) deklariert haben, beendet jedoch die Ausführung von Code nach host.RunAndBlock() für die verbleibende Zeit in der Gnadenfrist (ich bin nicht sicher, wie das bei Ihnen funktionieren würde) verwendet eine Endlosschleife anstelle von RunAndBlock). Was den Umgang mit dem Quit in Ihren Funktionen angeht, können Sie im Wesentlichen das CancellationToken "hören", das Sie an Ihre ausgelösten Funktionen für IsCancellationRequired übergeben und dann entsprechend behandeln können. Außerdem sind Sie nicht SOL, wenn Sie das nicht selbst erledigen. Hurra! Siehe Punkt 3.

2. Während Sie nicht SOL sind, wenn Sie nicht mit dem Beenden umgehen (siehe Punkt # 3), denke ich, es ist eine gute Idee, alle Ihre Aufträge in Transaktionen zu verpacken, die Sie nicht verpflichten, bis Sie ' absolut sicher, dass der Job seinen Lauf genommen hat. Auf diese Weise müssen Sie sich weniger um beschädigte Daten sorgen, wenn Ihre Funktion mitten im Prozess beendet wird. Ich kann mir ein paar Szenarien vorstellen, in denen Sie Transaktionen bei der Übergabe festschreiben möchten (z. B. Stapeljobs). Sie müssen jedoch Ihre Daten oder Logik so strukturieren, dass zuvor verarbeitete Elemente nach dem Neustart des Jobs nicht erneut verarbeitet werden.

3. Sie sind nicht in Schwierigkeiten, wenn Sie den Job nicht selbst erledigen. Mein Verständnis von dem, was unter der Decke passiert, ist praktisch nicht existent, aber ich bin mir der Ergebnisse sicher. Wenn eine Funktion mitten in der Verarbeitung einer Warteschlangennachricht ist und gezwungen wird, zu beenden, bevor sie beendet werden kann, HABE KEINE ANGST! Wenn der Job die zu verarbeitende Nachricht ergreift, wird sie für eine bestimmte Zeit im Wesentlichen in der Warteschlange verborgen. Wenn Ihre Funktion während der Verarbeitung der Nachricht beendet wird, wird diese Nachricht nach x Zeit wieder sichtbar, und sie wird erneut erfasst und mit dem möglicherweise aktualisierten Code ausgeführt, der gerade bereitgestellt wurde.

4. So habe ich etwa 90% Vertrauen in meine Ergebnisse für # 4. Und ich sage das, weil der Versuch, es zu testen, ein schnelles Wechseln zwischen Fenstern beinhaltete, während man nicht wirklich sicher war, was mit bestimmten Stücken vor sich ging. Aber hier ist, was ich gefunden habe: auf die Chance, dass eine Warteschlange eine neue Nachricht hinzugefügt hat in der Gnadenfrist b4 einen Job beendet, ich denke, eines von zwei Dingen kann passieren: Wenn die Funktion nicht diese Warteschlange vor dem Job abfragt beendet, dann bleibt die Nachricht in der Warteschlange und wird beim Neustart des Jobs gepackt. Wenn die Funktion DOES jedoch die Nachricht aufnimmt, wird sie wie jede andere Nachricht behandelt, die unterbrochen wurde: sie wird wieder in der Warteschlange sichtbar und wird beim Neustart des Jobs erneut ausgeführt.

Das fasst es ziemlich zusammen. Ich hoffe, dass andere Leute das nützlich finden. Lassen Sie mich wissen, wenn Sie etwas davon erklärt haben wollen und ich werde es gerne versuchen. Oder wenn ich voll davon bin und Sie viele Korrekturen haben, sind diese wahrscheinlich willkommener!