Skip to content
This repository was archived by the owner on Jan 7, 2019. It is now read-only.

Warteschlange für asynchrone Aufgaben #63

Open
marians opened this issue Oct 26, 2012 · 2 comments
Open

Warteschlange für asynchrone Aufgaben #63

marians opened this issue Oct 26, 2012 · 2 comments
Labels

Comments

@marians
Copy link
Owner

marians commented Oct 26, 2012

Aktuell werden auf dem Server einige Batch-Jobs im Hintergrund ausgeführt. Dazu gehören als wichtigste:

  • Thumbnails für neu hinzugekommene/geänderte Attachments erstellen
  • Neue/geänderte Dokumente für die Suche indexieren

Diese Jobs laufen nicht unbedingt effizient ab, weil beide immer umfangreiche Stapel sämtlicher Dokumente bzw. sämtlicher Dateien abarbeiten. Dies dauert mitunter mehrere Stunden oder Tage. Dieses System ist auch nicht besonders fehlertolerant. Schlägt z.B. die Erstellung der Thumbnails für eine Datei fehl, wird dies nicht registriert und der nächste Versuch erfolgt erst bei erneuter Bearbeitung des gesamten Stapels.

Zukünftig sind weitere Jobs denkbar, die zum teil automatisiert, zum Teil auch teilautomatisch oder ganz manuell bearbeitet werden könnten. Dazu gehören z.B. die OCR-Verarbeitung von gescannten Dateien, die Prüfung eines neuen Anhangs auf Urheberrechtsverletzung, das erneute Abspeichern eines gedrehten Dokuments, die Benachrichtigung eines E-Mail-Abonnenten über ein neues Dokument etc.

Eventuell wäre hierfür eine Job-Warteschlange hilfreich. Darin sollten die benötigten Jobs erstellt werden, z.B. wenn ein neues Attachment hinzukommt oder eines ausgetauscht wird. Also z.B.

  • Thumbnails für Datei X in Größe Y erstellen.
  • Dokument Z neu indexieren

Übernimmt ein Prozess die Bearbeitung eines Jobs, wird dessen Status geändert (pending -> active). Bei erfolgreicher Bearbeitung wird der Status in "done" geändert, der Job kann im Nachhinein gelöscht werden. Schlägt die Bearbeitung fehl, wird der Status auf "pending" zurückgesetzt.

Informationen, die bei der Fehlerbehebung helfen können (Logs) können ebenfalls dem Job angehängt werden.

Die beschriebene Logik hätte den Vorteil, dass die Ausführung von Jobs in kleineren Portionen, eventuell sogar verteilt passieren könnte.

Die einzelnen Jobs sollten neben einigen gemeinsamen Feldern (Datum, Status, Typ) ein freies Schema unterstützen, da jeder Jobtyp andere Daten notwendig machen kann. Zugriff auf die Jobs sollte z.B. sortiert bzw. gefiltert nach Datum, Typ und Status erfolgen können. Denkbar ist eine MySQL-Tabelle mit JSON-basierten Objekten. Flexibler wäre z.B. ElasticSearch oder MongoDB.

@marians
Copy link
Owner Author

marians commented Oct 26, 2012

Für die Thumbnail-Erzeugung bräuchte es ein spezielles Format zum Hinterlegen eines "Erledigungs-Versuchs", in dem stehen könnte, mit welchen Parametern der Versuch unternommen wurde.

{
    memory_limit: 524288000,
    cpu_time_limit: 600,
    result: 'fail',
    start_date: '2012-12-01T12:00:00Z',
    duration: 3586
}

So könnte der nächste Versuch mit angepassten Parametern unternommen werden.

@marians
Copy link
Owner Author

marians commented Sep 19, 2013

Im Repository https://github.com/marians/scrape-a-ris gibt es schon das Python-Modul "queue" für solche Aufgaben. Es ist zu überlegen, wie man es hinkriegt, dass man den Code auch für die Web-App bzw. Scripte in diesem Repository nutzten kann, ohne Code zu duplizieren.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

1 participant