Open marians opened 11 years ago
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.
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.
Aktuell werden auf dem Server einige Batch-Jobs im Hintergrund ausgeführt. Dazu gehören als wichtigste:
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.
Ü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.