Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

Abfrage-Richtlinien konfigurieren

Informationen zum Konfigurieren von Polling-Richtlinien für Vorgänge mit langer Ausführungszeit DieGoogle Cloud -Clientbibliotheken für Rust bieten Hilfsfunktionen, um die Fortschrittsüberwachung von Vorgängen mit langer Ausführungszeit (Long-Running Operations, LROs) zu vereinfachen. Diese Helfer verwenden Richtlinien, um die Abfragehäufigkeit zu konfigurieren und zu bestimmen, welche Abfragefehler vorübergehend sind (und sicher wiederholt werden können) und welche nicht behoben werden können.

Das Verhalten der LRO-Schleifen wird durch zwei Richtlinien gesteuert:

Die Polling-Backoff-Richtlinie steuert, wie lange die Schleifen warten, bevor sie den Status eines LRO abfragen, der noch in Bearbeitung ist.
Die Richtlinie für Abfragefehler steuert, was bei einem Abfragefehler zu tun ist. Einige Abfragefehler sind nicht behebbar und weisen darauf hin, dass der Vorgang abgebrochen wurde oder der Aufrufer keine Berechtigungen hat, den Status des LRO zu prüfen. Andere Polling-Fehler sind vorübergehend und weisen auf ein temporäres Problem im Clientnetzwerk oder im Dienst hin.

Sie können jede dieser Richtlinien unabhängig festlegen. Außerdem können Sie eine Richtlinie auf alle LROs anwenden, die auf einem Client gestartet wurden, oder die Richtlinie für eine einzelne Anfrage ändern.

Vorbereitung

In diesem Leitfaden wird der Cloud Storage-Dienst verwendet, um die Code-Snippets konkret zu halten. Die gleichen Konzepte gelten jedoch für jeden anderen Dienst, der LROs verwendet.

Bevor Sie diese Anleitung verwenden, folgen Sie der Anleitung unter Cloud Storage mit Rust verwenden, um die Cloud Storage API zu aktivieren und zu authentifizieren.

Eine vollständige Einrichtungsanleitung für die Rust-Bibliotheken finden Sie unter Entwicklungsumgebung einrichten.

Abhängigkeiten

Fügen Sie der Datei Cargo.toml die folgenden Abhängigkeiten hinzu:

cargo add google-cloud-storage google-cloud-lro

Abfragehäufigkeit für alle Anfragen in einem Client konfigurieren

Wenn Sie dieselbe Polling-Backoff-Richtlinie für die meisten Anfragen mit demselben Client verwenden möchten, sollten Sie die Richtlinie als Clientoption festlegen. In diesem Codebeispiel wird die Abfragehäufigkeit für alle Anfragen an den Cloud Storage-Dienst konfiguriert.

pub async fn client_backoff(bucket: &str, folder: &str, dest: &str) -> Result<()> {
    // Use a type that implements the `PollingBackoffPolicy` trait, in this case
    // `ExponentialBackoffBuilder`.
    use google_cloud_gax::exponential_backoff::ExponentialBackoffBuilder;
    use google_cloud_lro::Poller;
    use std::time::Duration;

    let client = StorageControl::builder()
        // Initialize the policy with a chosen delay duration.
        .with_polling_backoff_policy(
            ExponentialBackoffBuilder::new()
                .with_initial_delay(Duration::from_millis(250))
                .with_maximum_delay(Duration::from_secs(10))
                .build()?,
        )
        .build()
        .await?;

    // Initiate an LRO using polling.
    let response = client
        .rename_folder()
        .set_name(format!("projects/_/buckets/{bucket}/folders/{folder}"))
        .set_destination_folder_id(dest)
        .poller()
        .until_done()
        .await?;

    println!("LRO completed, response={response:?}");

    Ok(())
}

Sofern Sie die Richtlinie nicht mit einer Einstellung pro Anfrage überschreiben, bleibt sie für alle vom Client gestarteten Vorgänge mit langer Ausführungszeit in Kraft.

Bei folgendem Aufruf wird beispielsweise diese Richtlinie verwendet:

    let mut operation = client
        .rename_folder()
        /* more stuff */
        .send()
        .await?;

Bei diesem Beispielaufruf wartet die Clientbibliothek nach dem ersten Polling-Versuch 250 ms und nach dem zweiten Versuch 500 ms. Bei nachfolgenden Versuchen wird 1 s, 2 s, 4 s und 8 s gewartet. Bei allen weiteren Versuchen wird 10 s gewartet.

Abfragehäufigkeit für eine bestimmte Anfrage konfigurieren

Sie können die Abfragehäufigkeit für eine einzelne Anfrage konfigurieren. Dadurch wird jede auf Clientebene festgelegte Richtlinie überschrieben. Beispiel:

pub async fn rpc_backoff(bucket: &str, folder: &str, dest: &str) -> Result<()> {
    // Use a type that implements the `PollingBackoffPolicy` trait, in this case
    // `ExponentialBackoffBuilder`.
    use google_cloud_gax::exponential_backoff::ExponentialBackoffBuilder;
    use std::time::Duration;

    // To configure the request, bring the RequestOptionsBuilder trait into
    // scope.
    use google_cloud_gax::options::RequestOptionsBuilder;
    use google_cloud_lro::Poller;

    let client = StorageControl::builder().build().await?;
    // Create the request builder.
    let response = client
        .rename_folder()
        // Configure the polling backoff policy.
        .with_polling_backoff_policy(
            ExponentialBackoffBuilder::new()
                .with_initial_delay(Duration::from_millis(250))
                .with_maximum_delay(Duration::from_secs(10))
                .build()?,
        )
        .set_name(format!("projects/_/buckets/{bucket}/folders/{folder}"))
        .set_destination_folder_id(dest)
        // Issue the polling request as normal.
        .poller()
        .until_done()
        .await?;

    println!("LRO completed, response={response:?}");

    Ok(())
}

Wiederholbare Polling-Fehler für alle Anfragen in einem Client konfigurieren

Verwenden Sie zum Konfigurieren von wiederholbaren Fehlern einen Typ, der das PollingErrorPolicy-Trait implementiert. Die Clientbibliotheken bieten mehrere Richtlinien. Eine konservative Wahl ist Aip194Strict. Wenn Sie planen, dieselbe Polling-Richtlinie für die meisten Anfragen mit demselben Client zu verwenden, sollten Sie die Richtlinie als Clientoption festlegen.

In diesem Codebeispiel werden die wiederholbaren Polling-Fehler für alle Anfragen an den Cloud Storage-Dienst konfiguriert:

pub async fn client_error_policy(bucket: &str, folder: &str, dest: &str) -> Result<()> {
    // Use a type that implements the `PollingErrorPolicy` trait, in this case
    // `Aip194Strict`.
    use google_cloud_gax::polling_error_policy::Aip194Strict;
    use google_cloud_gax::polling_error_policy::PollingErrorPolicyExt;
    use google_cloud_lro::Poller;
    use std::time::Duration;

    // Add the polling policy that you want to use for all long-running
    // operations.
    let client = StorageControl::builder()
        .with_polling_error_policy(
            Aip194Strict
                .with_attempt_limit(100)
                .with_time_limit(Duration::from_secs(300)),
        )
        .build()
        .await?;

    // Initiate an LRO using polling.
    let response = client
        .rename_folder()
        .set_name(format!("projects/_/buckets/{bucket}/folders/{folder}"))
        .set_destination_folder_id(dest)
        .poller()
        .until_done()
        .await?;

    println!("LRO completed, response={response:?}");

    Ok(())
}

Während die Richtlinie für Polling-Fehler Fehler während der LRO-Warteschleife behandelt, können Sie auch eine Standardrichtlinie für Wiederholungsversuche hinzufügen, um vorübergehende Fehler zu beheben, die beim ersten Senden der Anfrage zum Starten des LRO auftreten können:

    let client = StorageControl::builder()
        .with_retry_policy(
            retry_policy::Aip194Strict
                .with_attempt_limit(100)
                .with_time_limit(Duration::from_secs(300)),
        )
        .build()
        .await?;

Sofern Sie die Richtlinie nicht mit einer Einstellung pro Anfrage überschreiben, bleibt sie für alle vom Client gestarteten Vorgänge mit langer Ausführungszeit in Kraft. Wenn Sie beispielsweise den folgenden Aufruf ausführen:

    let mut operation = client
        .rename_folder()
        /* more stuff */
        .send()
        .await?;

Hinweis:In der Clientbibliothek wird nur UNAVAILABLE (siehe AIP-194) als Fehler behandelt, der wiederholt werden kann. Das Polling wird nach 100 Versuchen oder 300 Sekunden beendet, je nachdem, was zuerst eintritt.

Wiederholbare Polling-Fehler für eine bestimmte Anfrage konfigurieren

Sie können wiederholbare Polling-Fehler für eine bestimmte Anfrage konfigurieren, indem Sie einen Typ verwenden, der das PollingErrorPolicy-Trait implementiert, und das RequestOptionsBuilder-Trait in den Bereich aufnehmen.

In diesem Codebeispiel werden wiederholbare Polling-Fehler für eine bestimmte Anfrage an den Cloud Storage-Dienst konfiguriert.

pub async fn rpc_error_policy(bucket: &str, folder: &str, dest: &str) -> Result<()> {
    // Use a type that implements the `PollingErrorPolicy` trait, in this case
    // `Aip194Strict`.
    use google_cloud_gax::polling_error_policy::Aip194Strict;
    use google_cloud_gax::polling_error_policy::PollingErrorPolicyExt;
    // Bring `RequestOptionsBuilder` into scope.
    use google_cloud_gax::options::RequestOptionsBuilder;
    use std::time::Duration;
    use google_cloud_lro::Poller;

    let client = StorageControl::builder().build().await?;

    // Create the request builder.
    let response = client
        .rename_folder()
        // Configure the polling error policy.
        .with_polling_error_policy(
            Aip194Strict
                .with_attempt_limit(100)
                .with_time_limit(Duration::from_secs(300)),
        )
        .set_name(format!("projects/_/buckets/{bucket}/folders/{folder}"))
        .set_destination_folder_id(dest)
        // Initialize the request.
        .poller()
        .until_done()
        .await?;

    println!("LRO completed, response={response:?}");

    Ok(())
}

Sie können auch eine Richtlinie für Wiederholungsversuche hinzufügen, falls die ursprüngliche Anfrage zum Starten des LRO fehlschlägt:

    let client = StorageControl::builder()
        .with_retry_policy(
            retry_policy::Aip194Strict
                .with_attempt_limit(100)
                .with_time_limit(Duration::from_secs(300)),
        )
        .build()
        .await?;

Abfrage-Richtlinien konfigurieren Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.