Questa pagina mostra come creare un gestore di attività di App Engine,
del worker che gestisce un'attività di App Engine. Cloud Tasks
invia richieste HTTP al gestore delle attività. Dopo il completamento di
in fase di elaborazione, il gestore deve inviare un codice di stato HTTP tra 200
e 299
di nuovo in coda. Qualsiasi altro valore indica che l'attività non è riuscita e la coda
riprova a eseguire l'attività.
Le richieste della coda di attività di App Engine vengono inviate dall'indirizzo IP 0.1.0.2
.
Consulta anche
Intervallo IP per le richieste inviate all'ambiente App Engine.
C#
Vai
Java
Node.js
PHP
Python
Ruby
Timeout
Le attività di App Engine hanno timeout specifici che dipendono tipo di scalabilità del servizio che li esegue.
Per i servizi worker in esecuzione nell'ambiente standard:
- Scalabilità automatica: l'elaborazione delle attività deve terminare entro 10 minuti.
- Scalabilità manuale e di base: le richieste possono essere eseguite fino a 24 ore.
Per i servizi worker in esecuzione nell'ambiente flessibile: tutti i tipi hanno una durata di 60 minuti timeout.
Se il gestore non rispetta la scadenza, la coda presuppone che l'attività non sia riuscita. in un nuovo tentativo.
Lettura delle intestazioni delle richieste di attività di App Engine
Richieste inviate al gestore App Engine da un gestore Cloud Tasks hanno intestazioni speciali, che contengono informazioni specifiche sull'attività potrebbe voler utilizzare.
Queste intestazioni sono impostate internamente. Se una di queste intestazioni è presente in un richiesta di utenti esterni alla tua app, vengono sostituiti da quelli interni. ad eccezione delle richieste da parte di amministratori dell'applicazione che hanno effettuato l'accesso, che sono può impostare intestazioni a scopo di test.
Le richieste di attività di App Engine contengono sempre le seguenti intestazioni:
Intestazione | Descrizione |
---|---|
X-AppEngine-QueueName |
Il nome della coda. |
X-AppEngine-TaskName |
Lo "Short" nome dell'attività o, se non è stato specificato alcun nome al momento della creazione, un ID univoco generato dal sistema. Questo è il 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 nuovi tentativi 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 dal gestore. Poiché Cloud Tasks elimina l'attività dopo aver ricevuto una risposta positiva, tutte le risposte precedenti dei gestori sono errori. Questo numero non include gli errori 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ò presupponi che si tratti di una richiesta Cloud Tasks.
Inoltre, le richieste da 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 hai eseguito di nuovo l'attività. |
X-AppEngine-FailFast |
Indica che un'attività non riesce immediatamente se un'istanza esistente non è disponibile. |
Routing di destinazione
Nelle attività di App Engine, sia la coda che il gestore di attività vengono eseguite all'interno lo stesso progetto Google Cloud. Il traffico viene criptato durante il trasporto e mai lascia i data center Google. Non puoi impostare esplicitamente il protocollo (ad ad esempio HTTP o HTTPS). La richiesta al gestore, tuttavia, apparirà hanno utilizzato il protocollo HTTP.
Le attività possono essere inviate a gestori di attività sicuri, non sicuri e
a runtime supportati, gli URI con restrizioni
login: admin
Poiché le attività non vengono eseguite come nessun utente, non possono essere inviate agli URI
limitato con login: required
.
Inoltre, gli invii di attività non seguono i reindirizzamenti.
Passaggi successivi
- Scopri di più sulle attività, consulta il riferimento delle API RPC.
- Scopri di più sulle attività nel riferimento dell'API REST.