Leitfaden: Uploads (erweitert)

Einführung

Der zuverlässige Upload von Assets ist die Kernfunktion jeder C2C-Integration.Dieser Leitfaden enthält erweiterte Techniken und Best Practices für die Erstellung eines robusten, widerstandsfähigen und effizienten Upload-Systems, das selbst in schwierigen Umgebungen gute Leistungen erbringt.

Voraussetzungen

Wenn Sie es noch nicht getan haben, lesen Sie bitte den Leitfaden C2C implementieren: Einrichtung, bevor Sie fortfahren.Sie benötigen den access_token, den Sie während des Authentifizierungs- und Autorisierungsprozesses erhalten haben.Wir verwenden weiterhin das gleiche Test-Asset aus dem Leitfaden zu einfachen Uploads.

Erweiterte Asset-Parameter

Beim Erstellen von Assets in Frame.io können Sie mehrere erweiterte Parameter verwenden, um das Upload-Verhalten anzupassen.Der Parameter offset ist für eine korrekte Integration besonders wichtig.

Offset (Versatz) – Umgang mit angehaltenen Geräten

Die Angabe eines genauen offset-Werts ist von entscheidender Bedeutung.Dieser Parameter gibt an, wann ein Medium erstellt wurde, und stellt sicher, dass das Gerät keine Inhalte hochlädt, die nicht freigegeben werden sollen.Wenn ein Gerät in Frame.io angehalten wird, bedeutet dies, dass während der Pause erstellte Medien nicht hochgeladen werden sollen.Weitere Informationen finden Sie in unserem Leitfaden zur Pause-Funktion.

Zusätzliche Vorteile des Parameters „offset“

Der Parameter offset bietet einen weiteren signifikanten Vorteil bei der Organisation von Medien mit Frame.io.Beim Hochladen von Inhalten, die zu einem früheren Zeitpunkt aufgenommen wurden, z. B. wenn ein Benutzender ein Foto auswählt, das während der Wiedergabe in der vorherigen Woche aufgenommen wurde, stellt der offset sicher, dass dieses Medium in Ordnern angezeigt wird, die dem ursprünglichen Aufnahmedatum entsprechen und nicht dem aktuellen Upload-Datum.Diese chronologische Organisation verwaltet eine logische Timeline in der Frame.io-Projektstruktur.Ohne den Parameter offset würden historische Medien fälschlicherweise mit den heutigen Inhalten gruppiert angezeigt, was zu Verwechslungen für Editierende und andere Mitwirkende führen könnte.In diesem Fall können Sie den Benutzenden über Ihre Benutzeroberfläche eine Auswahl zur Verfügung stellen.Wenn Benutzende alle Uploads nach dem aktuellen Datum organisieren möchten, unabhängig davon, wann das Medium erfasst wurde, können Sie einfach den Parameter offset weglassen, da er bei Nichtangabe standardmäßig auf 0 gesetzt ist.

Dank unseres API-Designs muss Ihr Gerät den Pause-Status nicht mehr verfolgen.Stattdessen geben Sie beim Upload einer Datei an, wie viele Sekunden vor der Erstellung der Datei vergangen sind.Unser Server vergleicht dies mit Pausenzeiträumen und lehnt den Upload ab, wenn er während einer Pause erstellt wurde.

Um diese Funktion zu demonstrieren, pausieren Sie das Gerät über das Drei-Punkte-Menü auf der Registerkarte „C2C-Verbindungen“.

Versuchen Sie nun, ein Asset hochzuladen:

$
{
>
curl -X POST https://api.frame.io/v2/devices/assets \
>
    --header 'Authorization: Bearer [access_token]' \
>
    --header 'Content-Type: application/json' \
>
    --header 'x-client-version: 2.0.0' \
>
    --data-binary @- <<'__JSON__' 
>
        {
>
            "name": "C2C_TEST_CLIP.mp4", 
>
            "filetype": "video/mp4", 
>
            "filesize": 21136250,
>
            "offset": 0
>
        }
>
__JSON__
>
} | python -m json.tool

Sie erhalten den folgenden Fehler:

1
{
2
    "code": 409,
3
    "errors": [
4
        {
5
            "code": 409,
6
            "detail": "The channel you're uploading from is currently paused.",
7
            "status": 409,
8
            "title": "Channel Paused"
9
        }
10
    ],
11
    "message": "Channel Paused"
12
}

Wenn Sie die Pause des Geräts aufheben und es mit derselben Anfrage erneut versuchen, wird das Asset erstellt.

Wenn das Asset jedoch während des Pausenzeitraums erstellt wurde, müssen Sie den Parameter offset so einstellen, dass er dem tatsächlichen Zeitpunkt der Erstellung entspricht:

$
{
>
curl -X POST https://api.frame.io/v2/devices/assets \
>
    --header 'Authorization: Bearer [access_token]' \
>
    --header 'Content-Type: application/json' \
>
    --header 'x-client-version: 2.0.0' \
>
    --data-binary @- <<'__JSON__' 
>
        {
>
            "name": "C2C_TEST_CLIP.mp4", 
>
            "filetype": "video/mp4", 
>
            "filesize": 21136250,
>
            "offset": 60
>
        }
>
__JSON__
>
} | python -m json.tool

Dies teilt Frame.io mit, dass das Asset vor 60 Sekunden (während der Pause) erstellt wurde, wodurch der Fehler Channel Paused ordnungsgemäß ausgelöst wird.Genaue offset-Werte sind unerlässlich, um das Hochladen sensibler Inhalte gegen die Wünsche des Benutzenden zu verhindern, einschließlich geschützten geistigen Eigentums, sensiblen Materials oder anderen eingeschränkten Materials.

Auf einen bestimmten Kanal hochladen

Wenn Ihr Gerät über mehrere Kanäle verfügt, können Sie festlegen, welcher Kanal verwendet werden soll:

$
{
>
curl -X POST https://api.frame.io/v2/devices/assets \
>
    --header 'Authorization: Bearer [access_token]' \
>
    --header 'Content-Type: application/json' \
>
    --header 'x-client-version: 2.0.0' \
>
    --data-binary @- <<'__JSON__' 
>
        {
>
            "name": "C2C_TEST_CLIP.mp4", 
>
            "filetype": "video/mp4", 
>
            "filesize": 21136250,
>
            "offset": -10,
>
            "channel": 2
>
        }
>
__JSON__
>
} | python -m json.tool

Wenn keine Angabe gemacht wird, ist der Standardkanal 0.Bei den meisten Integrationen muss dieser Wert nicht geändert werden.

Selbstdefinierte Chunk-Anzahl anfordern

Standardmäßig teilt das Backend von Frame.io Dateien in Chunks von ca. 25 MB auf.Bei Netzwerken mit hoher Auslastung bevorzugen Sie möglicherweise kleinere Chunks.Sie können eine bestimmte Anzahl von Chunks mit dem Parameter parts anfordern:

$
{
>
curl -X POST https://api.frame.io/v2/devices/assets \
>
    --header 'Authorization: Bearer [access_token]' \
>
    --header 'Content-Type: application/json' \
>
    --header 'x-client-version: 2.0.0' \
>
    --data-binary @- <<'__JSON__'
>
        {
>
            "name": "C2C_TEST_CLIP.mp4",
>
            "filetype": "video/mp4",
>
            "filesize": 21136250,
>
            "offset": 0,
>
            "parts": 4
>
        }
>
__JSON__
>
} | python -m json.tool

Die Antwort enthält vier Upload-URLs:

1
{
2
    ...
3
    "upload_urls": [
4
        "https://frameio-uploads-production.s3-accelerate.amazonaws.com/parts/[part-01-path]",
5
        "https://frameio-uploads-production.s3-accelerate.amazonaws.com/parts/[part-02-path]",
6
        "https://frameio-uploads-production.s3-accelerate.amazonaws.com/parts/[part-03-path]",
7
        "https://frameio-uploads-production.s3-accelerate.amazonaws.com/parts/[part-04-path]"
8
    ],
9
    ...
10
}

Die Chunk-Größe ist:

1
math.ceiling(float(21136250) / float(4))
2
# 5284063 bytes

Der letzte Chunk ist 5.284.061 Byte (berechnet als 21136250 - 5284063 * 3).Beachten Sie bei der Anfrage von selbstdefinierten Chunk-Zählungen die Einschränkungen beim mehrteiligen Upload in AWS S3:

• Jeder Teil muss mindestens 5 MiB (5.242.880 Byte) groß sein, mit Ausnahme des letzten Teils
• Es dürfen nicht mehr als 10.000 Teile vorhanden sein

Wenn Ihre Anfrage diese Einschränkungen verletzt, wird Ihnen der Fehler 500: INTERNAL SERVER ERROR angezeigt:

{
    "code": 500,
    "errors": [
        {
            "code": 500,
            "detail": "There was a problem with your request",
            "status": 500,
            "title": "Something went wrong"
        }
    ],
    "message": "Something went wrong"
}

Vergewissern Sie sich immer, dass die Anzahl der selbstdefinierten Teile den Anforderungen von S3 entspricht.

Effiziente Uploads

C2C-Geräte arbeiten oft in anspruchsvollen Netzwerkumgebungen, daher ist Effizienz entscheidend.Nachfolgend finden Sie Strategien zur Maximierung des Durchsatzes.

Wiederverwendung/Pooling der TCP-Verbindung

Der Aufbau verschlüsselter Verbindungen erfordert einen erheblichen Verhandlungsaufwand.Verwenden Sie für einen effizienten Betrieb TCP-Verbindungen erneut, wenn Sie mehrere Anfragen stellen.Die meisten HTTP-Bibliotheken stellen eine Client- oder Session-Abstraktion bereit, die persistente Verbindungen aufrecht erhält.

Der Verhandlungsprozess für eine neue HTTPS-Verbindung umfasst kryptografische Handshakes und die Zertifikatvalidierung.Durch die Wiederverwendung von Verbindungen führen Sie diesen Overhead nur einmal statt für jede Anfrage aus.

Um die Wiederverwendung von Verbindungen mit curl zu demonstrieren, erstellen Sie zunächst ein neues Asset in Frame.io, wie im Leitfaden zu einfachen Uploads beschrieben.

Teilen Sie als Nächstes die Datei zum Testen in separate Chunks auf:

$
head -c 10568125 ~/Downloads/C2C_TEST_CLIP.mp4 > "C2C_TEST_CLIP-Chunk01"
$
tail -c 10568125 ~/Downloads/C2C_TEST_CLIP.mp4 > "C2C_TEST_CLIP-Chunk02"

Laden Sie nun beide Chunks über eine einzige TCP-Verbindung mit dem curl-Parameter --next hoch:

$
curl -X PUT https://frameio-uploads-production.s3-accelerate.amazonaws.com/parts/[part-1-path] \
>
        --include \
>
        --header 'content-type: video/mp4' \
>
        --header 'x-amz-acl: private' \
>
        --data-binary @C2C_TEST_CLIP-Chunk01 \
>
--next -X PUT https://frameio-uploads-production.s3-accelerate.amazonaws.com/parts/[part-2-path] \
>
        --include \
>
        --header 'content-type: video/mp4' \
>
        --header 'x-amz-acl: private' \
>
        --data-binary @C2C_TEST_CLIP-Chunk02

Vergleichen Sie dies mit separaten Verbindungen:

$
curl -X PUT https://frameio-uploads-production.s3-accelerate.amazonaws.com/parts/[part-1-path] \
>
        --include \
>
        --header 'content-type: video/mp4' \
>
        --header 'x-amz-acl: private' \
>
        --data-binary @C2C_TEST_CLIP-Chunk01 \
>
&& curl -X PUT https://frameio-uploads-production.s3-accelerate.amazonaws.com/parts/[part-2-path] \
>
        --include \
>
        --header 'content-type: video/mp4' \
>
        --header 'x-amz-acl: private' \
>
        --data-binary @C2C_TEST_CLIP-Chunk02

Bei Tests verbessert die Wiederverwendung von Verbindungen in der Regel die Leistung für sequenzielle Uploads um 15–20 %.

Parallele Uploads

Für einen noch höheren Durchsatz laden Sie mehrere Chunks gleichzeitig hoch:

$
curl -X PUT https://frameio-uploads-production.s3-accelerate.amazonaws.com/parts/[part-1-path] \
>
        --include \
>
        --header 'content-type: video/mp4' \
>
        --header 'x-amz-acl: private' \
>
        --data-binary @C2C_TEST_CLIP-Chunk01 \
>
& \
>
curl -X PUT https://frameio-uploads-production.s3-accelerate.amazonaws.com/parts/[part-2-path]\
>
        --include \
>
        --header 'content-type: video/mp4' \
>
        --header 'x-amz-acl: private' \
>
        --data-binary @C2C_TEST_CLIP-Chunk02 \
>
&

Bei ausreichender Bandbreite dauern parallele Uploads in etwa so lange wie der langsamste einzelne Upload.

Für eine optimale Parallelität gilt als Faustregel: zwei gleichzeitige Uploads pro CPU-Kern.Eine Überschreitung dieses Verhältnisses kann zu Ressourcenkonflikten und abnehmenden Ausgaben führen.

Beide Ansätze kombinieren

Für maximale Effizienz kombinieren Sie Verbindungspooling mit parallelen Uploads.Erstellen Sie mehrere Prozesse, von denen jeder Verbindungspooling für seine eigene Upload-Reihenfolge verwendet:

$
curl -X PUT https://frameio-uploads-production.s3-accelerate.amazonaws.com/parts/[asset01-chunk01] \
>
        --include \
>
        --header 'content-type: video/mp4' \
>
        --header 'x-amz-acl: private' \
>
        --data-binary @C2C_TEST_CLIP-Chunk01 \
>
--next -X PUT https://frameio-uploads-production.s3-accelerate.amazonaws.com/parts/[asset01-chunk02] \
>
        --include \
>
        --header 'content-type: video/mp4' \
>
        --header 'x-amz-acl: private' \
>
        --data-binary @C2C_TEST_CLIP-Chunk02 \
>
& \
>
curl -X PUT https://frameio-uploads-production.s3-accelerate.amazonaws.com/parts/[asset02-chunk01] \
>
        --include \
>
        --header 'content-type: video/mp4' \
>
        --header 'x-amz-acl: private' \
>
        --data-binary @C2C_TEST_CLIP-Chunk01 \
>
--next -X PUT https://frameio-uploads-production.s3-accelerate.amazonaws.com/parts/[asset02-chunk02] \
>
        --include \
>
        --header 'content-type: video/mp4' \
>
        --header 'x-amz-acl: private' \
>
        --data-binary @C2C_TEST_CLIP-Chunk02 \
>
&

Den Upload-Fortschritt verfolgen

Ihre Integration muss den Benutzenden eine grundlegende Fortschrittsanzeige bieten.Die Granularität auf Chunk-Ebene ist akzeptabel. Bei einem Drei-Chunk-Upload kann der Fortschritt von 0 % → 33 % → 66 % → 100 % erhöht werden, wenn jeder Chunk abgeschlossen wird.

Die feingranulierte Fortschrittsberichterstattung hängt von den Fähigkeiten Ihrer HTTP-Bibliothek ab.Wenden Sie sich an unser Team, wenn Sie Unterstützung bei der Implementierung einer detaillierteren Fortschrittskontrolle benötigen.

Upload-Zuverlässigkeit

Eine zuverlässige Fehlerbehandlung finden Sie in unserem Leitfaden zu Fehlern.In den folgenden Abschnitten wird davon ausgegangen, dass Sie die dort beschriebenen Fehlerbehandlungsstrategien implementiert haben.

Das Erstellen eines Uploaders in Produktionsqualität erfordert neben der Bearbeitung einzelner Anfragefehler zusätzliche Überlegungen.

Upload-Warteschlangen erstellen

In der Praxis kann es vorkommen, dass Ihr Gerät Medien schneller erstellt, als es hochladen kann, oder dass es zu längeren Verbindungsunterbrechungen kommt.Durch die Implementierung eines Warteschlangensystems wird die Medienerstellung von der Upload-Verwaltung getrennt.

Ziehen Sie eine Architektur mit zwei Warteschlangen in Betracht:

1. Eine Medienwarteschlange zum Registrieren lokaler Dateien mit Frame.io
2. Eine Chunk-Warteschlange für das Hochladen einzelner Datei-Chunks

Hier eine vereinfachte Implementierung:

1
# Where we are going to queue new files.
2
FILE_QUEUE = Queue()
3
4
# Where we are going to queue new chunks.
5
CHUNK_QUEUE = Queue()
6
7
# The http session that will handle TCP 
8
# connection pooling for us.
9
HTTP_SESSION = http.Session()
10
11
def take_picture():
12
    """Snaps a picture for the user."""
13
14
    image = MY_DEVICE.capture()
15
    file_path = MY_DEVICE.write_image(image)
16
    FILE_QUEUE.add(file_path)
17
18
def task_register_assets():
19
    """
20
    Pulls snapped pictures from the FILE_QUEUE, registers
21
    with Frame.io, and adds the chunks to the CHUNK_QUEUE.
22
    """
23
    while True:
24
        # Get the latest file added to the queue and register 
25
        # a C2C Asset for it.
26
        new_file = FILE_QUEUE.get()
27
        asset = c2c.crete_asset_for_file(HTTP_SESSION, new_file)
28
29
        # Calculate the size for each chunk
30
        chunk_size = c2c.calculate_chunk_size(asset, new_file)
31
32
        # Create a message for each chunk with it's parameters 
33
        # and add it to the 
34
        # queue.
35
        chunk_start = 0
36
        for chunk_url in asset.upload_urls:
37
            message = {
38
                "file_path": new_file,
39
                "chunk_url": chunk_url,
40
                "chunk_start": chunk_start,
41
                "chunk_size": chunk_size,
42
            }
43
44
            # Put the message in the queue and 
45
            CHUNK_QUEUE.put(message)
46
            chunk_start += chunk_size
47
48
def task_upload_chunk():
49
    """Takes a chunks and uploads them."""
50
51
    while True:
52
        info = CHUNK_QUEUE.get()
53
        c2c.upload_chunk(HTTP_SESSION, info)
54
55
def launch_upload_tasks():
56
    """Lauches our Frame.io upload tasks."""
57
    # Create a list to hold all of our tasks.
58
    tasks = list()
59
60
    # Create one task for registering assets.
61
    asset_task = run_task_in_thread(task_register_assets)
62
    tasks.append(asset_task)
63
64
    # Create 2 tasks per CPU core for uploading chunks.
65
    for _ in range(0, GET_CPU_COUNT() * 2):
66
        chunk_task = run_task_in_thread(task_upload_chunk)
67
        tasks.append(chunk_task)
68
69
    # Run these tasks until shutdown
70
    run_forever(tasks)

Persistente Warteschlangen über Ein- und Ausschaltzyklen hinweg

Der Ansatz mit der In-Memory-Warteschlange funktioniert gut, solange das Gerät eingeschaltet bleibt, aber was passiert, wenn die Stromversorgung ausfällt, bevor der Upload abgeschlossen ist?Um eine wirklich ausfallsichere Integration zu schaffen, müssen wir sicherstellen, dass das Gerät nach einem Neustart dort weitermachen kann, wo es aufgehört hat.

Dazu muss der Status der Warteschlange über Ein- und Ausschaltzyklen hinweg im Speicher erhalten bleiben.Eine integrierte Datenbank wie SQLite bietet eine ausgezeichnete Grundlage für diese Funktionalität.

Ihre persistente Warteschlangenimplementierung sollte folgende Schlüsselvorgänge unterstützen:

• Neu erstellte Dateien werden der Upload-Warteschlange hinzugefügt
• Nachverfolgung, wenn Assets erfolgreich in Frame.io erstellt wurden
• Aufzeichnung, wenn die Erstellung eines Assets aufgrund von Fehlern fehlschlägt
• Datei-Chunk-Informationen für Upload-Aufgaben werden gespeichert
• Der nächste hochzuladende Chunk wird abgerufen
• Chunks werden als erfolgreich hochgeladen markiert
• Chunk-Upload-Fehler werden protokolliert
• Dateistatusinformationen für die Benutzeranzeige werden bereitgestellt

So können wir unser vorheriges Beispiel anpassen, um ein persistentes Speichersystem zu verwenden:

1
# Our persistence layer for queuing uploads, potentially using SQLite 
2
# or another embedded database
3
C2C_UPLOAD_STORE = NewC2CUploadStore()
4
5
# HTTP session for connection pooling
6
HTTP_SESSION = http.Session()
7
8
def take_picture():
9
    """Captures an image and adds it to the upload queue."""
10
    image = MY_DEVICE.capture()
11
    file_path = MY_DEVICE.write_image(image)
12
13
    # Register the file with our persistent store
14
    C2C_UPLOAD_STORE.add_file(file_path)
15
16
def task_register_assets():
17
    """
18
    Processes files from persistent storage and registers
19
    them with Frame.io for upload.
20
    """
21
    while True:
22
        # Get the next available file from our store
23
        file_record = C2C_UPLOAD_STORE.get_file()
24
25
        try:
26
            # Register the asset with Frame.io
27
            asset = c2c.create_asset_for_file(HTTP_SESSION, file_record)
28
            chunk_size = c2c.calculate_chunk_size(asset, file_record)
29
30
            # Create entries for each chunk in our persistent store
31
            chunk_start = 0
32
            for chunk_url in asset.upload_urls:
33
                message = {
34
                    "file_path": file_record,
35
                    "chunk_url": chunk_url,
36
                    "chunk_start": chunk_start,
37
                    "chunk_size": chunk_size,
38
                }
39
                
40
                C2C_UPLOAD_STORE.new_chunk(message)
41
                chunk_start += chunk_size
42
                
43
        except BaseException as error:
44
            # Record the error in our persistent store
45
            C2C_UPLOAD_STORE.file_asset_create_error(file_record, error)
46
        else:
47
            # Mark the asset as successfully created
48
            C2C_UPLOAD_STORE.file_asset_created(file_record)
49
50
def task_upload_chunk():
51
    """Uploads individual file chunks from the persistent queue."""
52
    while True:
53
        # Get the next chunk, marking it as "in progress" to prevent 
54
        # other tasks from processing it simultaneously
55
        chunk_record = C2C_UPLOAD_STORE.get_chunk()
56
57
        try:
58
            c2c.upload_chunk(HTTP_SESSION, chunk_record)
59
        except BaseException as error:
60
            # Record the error for potential retry
61
            C2C_UPLOAD_STORE.chunk_error(chunk_record, error)
62
        else:
63
            # Mark successful completion
64
            C2C_UPLOAD_STORE.chunk_success(chunk_record)
65
66
def launch_upload_tasks():
67
    """Launches Frame.io upload processing tasks."""
68
    tasks = []
69
70
    # Asset registration task
71
    asset_task = run_task_in_thread(task_register_assets)
72
    tasks.append(asset_task)
73
74
    # Multiple parallel chunk upload tasks
75
    worker_count = GET_CPU_COUNT() * 2
76
    for _ in range(worker_count):
77
        chunk_task = run_task_in_thread(task_upload_chunk)
78
        tasks.append(chunk_task)
79
80
    # Run indefinitely
81
    run_forever(tasks)

Mit diesem persistenten Speicheransatz ist Ihre Integration widerstandsfähig gegenüber Stromausfällen.Wenn das Gerät neu gestartet wird, setzt es die Verarbeitung einfach aus dem zuletzt gespeicherten Zustand fort.Diese Architektur bietet auch die Grundlage für die Implementierung erweiterter Funktionen, wie Fehlerverfolgung und Erkennung von verzögerten Uploads.

Upload-Fehler nachverfolgen

Ein robustes Upload-System muss Fehler sorgfältig nachverfolgen.Nachdem Sie einen Vorgang mit den Strategien im Leitfaden zu Fehlern wiederholt haben, notieren Sie diese Fehler in Ihrem persistenten Speicher.Dadurch kann Ihr System:

1. Problematische Uploads depriorisieren, um zu verhindern, dass sie die gesamte Warteschlange blockieren
2. Benutzenden genaue Statusinformationen zur Verfügung stellen
3. Administrative Eingriffe für persistente Probleme aktivieren

Wenn ein schwerwiegender Fehler auftritt, markieren Sie das Element, um unnötige Wiederholungsversuche zu verhindern.

Verzögerte Uploads verwalten

Implementieren Sie Sicherheitsmaßnahmen gegen zeitlich unbegrenzte blockierte Uploads.Legen Sie eine maximale Dauer (z. B. 30 Minuten) fest, nach der eine Chunk-Upload-Aufgabe beendet und neu gestartet werden soll.Dadurch werden Szenarien verhindert, in denen alle Upload-Worker durch nicht responsive Vorgänge blockiert werden.

Nach stillen Fehlern wiederherstellen

Systemabstürze, Stromausfall oder Prozessabbruch können die normale Fehlerberichterstattung verhindern.Wenn Sie Artikel aus Ihrer Warteschlange abrufen, notieren Sie die Zeit für den Checkout.Wenn ein Element über einen angemessenen Zeitraum (z. B. 30 Minuten) hinweg im Status „In Bearbeitung“ verbleibt, ohne dass Erfolg oder Misserfolg gemeldet wird, soll es automatisch in den Pool der verfügbaren Elemente zurückgeführt werden, damit es von einem anderen Bearbeitenden bearbeitet werden kann.

Beschädigte Uploads abschwächen

Ein „beschädigtes“ Warteschlangenelement schlägt aufgrund inhärenter Probleme mit den Daten oder der Umgebung ständig fehl.Wenn diese Elemente ständig in die Warteschlange gestellt werden, können sie Ihr gesamtes Upload-System blockieren.Berücksichtigen Sie die folgenden Strategien für den Umgang mit solchen Fällen:

• Nach mehreren Fehlern müssen Sie die Priorität des Elements herabstufen, damit neuere Inhalte fortgesetzt werden können
• Sowohl explizite Fehler als auch die Anzahl der Verarbeitungsversuche verfolgen
• Befolgen Sie die Best Practices für Verbindung und Autorisierung, um zwischen vorübergehenden Umgebungsproblemen und intrinsischen Dateiproblemen zu unterscheiden
• Führen Sie eskalierende Wiederholungsgrenzen ein (z. B. 10 Wiederholungsversuche für einzelne Vorgänge innerhalb von jeweils 3 Jobversuchen, insgesamt also 30 Versuche)
• Stellen Sie eine Benutzeroberfläche bereit, über die problematische Uploads manuell zurückgesetzt werden können, sobald die Umgebungsprobleme behoben sind

Beschädigte Uploads können folgende Ursache haben:

• Korrupte Dateidaten verursachen I/O-Fehler
• Schwerwiegende Prozessfehler, die eine Fehlerberichterstattung verhindern
• Normalerweise behebbare Fehler, die durch dauerhafte zugrunde liegende Umstände ausgelöst werden

Nach Neustart des Systems erneut versuchen

Bevor Sie problematische Uploads endgültig abbrechen, markieren Sie sie für einen letzten Versuch nach dem nächsten Systemneustart.Dies betrifft Fälle, in denen Uploads aufgrund vorübergehender Systemprobleme im Zusammenhang mit Arbeitsspeicher, Treibern oder der Ressourcenzuweisung fehlschlagen.Wenn ein Upload nach einem sauberen Neustart weiterhin fehlschlägt, können Sie ihn sicherer als dauerhaft problematisch markieren.

Warteschlange löschen

Denken Sie daran, nicht verfügbare Dateien aus Ihrer Warteschlange zu entfernen.Wenn Medien physisch entfernt oder Dateien gelöscht werden, löschen Sie die entsprechenden Einträge aus der Upload-Warteschlange, um unnötige Fehler zu vermeiden.

Wichtig: Sie müssen Ihre Upload-Warteschlange leeren, wenn Sie eine Verbindung zu einem neuen Projekt herstellen. Medien, die für ein Projekt in der Warteschlange stehen, sollten niemals in einem anderen Projekt erscheinen.Wenn ein Benutzender das Gerät mit einem anderen Projekt verbindet, überprüfen Sie, ob sich das Projekt geändert hat, und löschen Sie in diesem Fall die vorhandene Warteschlange vollständig.

Nächste Schritte

Wir empfehlen Ihnen, sich bei Fragen an unser Team zu wenden und mit dem Leitfaden zu erweiterten Uploads fortzufahren.Wir freuen uns darauf, Ihren Integrationsprozess zu unterstützen.