Questa pagina mostra come creare un gestore delle attività App Engine, il codice worker che gestisce un'attività App Engine. La coda Cloud Tasks invia richieste HTTP al gestore delle attività. Al termine dell'elaborazione, il gestore deve inviare alla coda un codice di stato HTTP compreso tra 200
e 299
. Qualsiasi altro valore indica che l'attività non è riuscita e la coda la riprova.
Le richieste di coda di lavoro App Engine vengono inviate dall'indirizzo IP 0.1.0.2
.
Fai riferimento anche all'intervallo IP per le richieste inviate all'ambiente App Engine.
C#
Vai
Java
Node.js
PHP
Python
Ruby
Timeout
Le attività App Engine hanno timeout specifici che dipendono dal tipo di scalabilità del servizio che le esegue.
Per i servizi di lavoro in esecuzione nell'ambiente standard:
- Scalabilità automatica: l'elaborazione delle attività deve essere completata in 10 minuti.
- Scalabilità manuale e di base: le richieste possono essere eseguite per un massimo di 24 ore.
Per i servizi di worker in esecuzione nell'ambiente flessibile: tutti i tipi hanno un timeout di 60 minuti.
Se il gestore non rispetta la scadenza, la coda presume che l'attività non sia riuscita e lo ritenta.
Lettura delle intestazioni di richiesta delle attività App Engine
Le richieste inviate all'handler di App Engine da una coda Cloud Tasks hanno intestazioni speciali che contengono informazioni specifiche dell'attività che l'handler potrebbe voler utilizzare.
Queste intestazioni vengono impostate internamente. Se una di queste intestazioni è presente in una richiesta di un utente esterno alla tua app, viene sostituita da quella interna, tranne per le richieste degli amministratori dell'applicazione che hanno eseguito l'accesso e che sono autorizzati a impostare le intestazioni a scopo di test.
Le richieste di attività App Engine contengono sempre le seguenti intestazioni:
Intestazione | Descrizione |
---|---|
X-AppEngine-QueueName |
Il nome della coda. |
X-AppEngine-TaskName |
Il nome "breve" dell'attività o, se non è stato specificato alcun nome al momento della creazione, un ID univoco generato dal sistema. Si tratta del valore my-task-id nel nome completo dell'attività, ad esempio task_name = projects/my-project-id/locations/my-location/queues/my-queue-id/tasks/my-task-id . |
X-AppEngine-TaskRetryCount |
Il numero di volte in cui è stato eseguito un nuovo tentativo per l'attività. Per il primo tentativo, questo valore è 0 . Questo numero include i tentativi in cui l'attività non è riuscita a causa della mancanza di istanze disponibili e non ha mai raggiunto la fase di esecuzione. |
X-AppEngine-TaskExecutionCount |
Il numero di volte in cui l'attività è stata eseguita e ha ricevuto una risposta dall'handler. Poiché Cloud Tasks elimina l'attività dopo aver ricevuto una risposta positiva, tutte le risposte precedenti dell'handler sono errori. Questo numero non include i fallimenti dovuti alla mancanza di istanze disponibili. Tieni presente che X-AppEngine-TaskExecutionCount può essere uguale a X-AppEngine-TaskRetryCount se viene aggiornato prima del tentativo di esecuzione. |
X-AppEngine-TaskETA |
L'ora di pianificazione dell'attività, specificata in secondi dal 1° gennaio 1970. |
Se il gestore delle richieste trova una delle intestazioni elencate in precedenza, può assumere che si tratti di una richiesta Cloud Tasks.
Inoltre, le richieste di Cloud Tasks potrebbero contenere le seguenti intestazioni:
Intestazione | Descrizione |
---|---|
X-AppEngine-TaskPreviousResponse |
Il codice di risposta HTTP del tentativo precedente. |
X-AppEngine-TaskRetryReason |
Il motivo per cui riprovare a eseguire l'attività. |
X-AppEngine-FailFast |
Indica che un'attività non va a buon fine immediatamente se non è disponibile un'istanza esistente. |
Routing target
Nelle attività App Engine, sia la coda sia il gestore delle attività vengono eseguiti nello stesso progetto Google Cloud . Il traffico viene criptato durante il trasporto e non esce mai dai data center di Google. Non puoi impostare esplicitamente il protocollo (ad esempio HTTP o HTTPS). Tuttavia, la richiesta al gestore sembrerà aver utilizzato il protocollo HTTP.
Le attività possono essere inviate a gestori di attività sicuri, gestori di attività non sicuri e, nei runtime supportati, a URI limitati con login: admin
.
Poiché le attività non vengono eseguite come qualsiasi utente, non possono essere inviate a URI con limitazioni con login: required
.
Anche le spedizioni delle attività non seguono i reindirizzamenti.
Passaggi successivi
- Scopri di più sulle attività nel riferimento all'API RPC.
- Scopri di più sulle attività nel riferimento all'API REST.