Creating Tasks

This page describes how to create tasks and place them in push queues. When you want to run a task, you must create a new task and place it on a queue. You can explicitly specify the service and handler that processes the task, and optionally pass task-specific data along to the handler.

Creating a new task

To create and enqueue a task, get a Queue using the QueueFactory, and call its add() method. You can get a named queue specified in the queue.xml file using the getQueue() method of the factory, or you can get the default queue using getDefaultQueue(). You can call the Queue's add() method with a TaskOptions instance (produced by TaskOptions.Builder, or you can call it with no arguments to create a task with the default options for the queue.


// Add the task to the default queue.
Queue queue = QueueFactory.getDefaultQueue();
queue.add(TaskOptions.Builder.withUrl(“/url/path“).param(“some-user-data”, 17));

Specifying the worker service

When a task is popped off its queue, the Task Queue service sends it on to a worker service. Every task has a target and a url, which determine what service and handler will ultimately perform the task.


The target specifies the service that will receive the HTTP request to perform the task. It is a string that specifies a service/version/instance in any one of the canonical forms. The most often-used ones are:


The target string is prepended to the domain name of your app. There are three ways to set the target for a task:

  • Explicity declare the target when you construct the task.

  • Include a target directive when you define a queue in the queue.xml, as in the definition of queue-blue above. All tasks added to a queue with a target will use that target, even if a different target was assigned to the task at construction time.

  • If no target is specified according to either of the previous two methods, then the task's target is the version of the service that enqueues it. Note that if you enqueue a task from the default service and version in this manner, and the default version changes before the task executes, it will run in the new default version.


The url selects one of the handlers in the target service, which will perform the task.

The url should match one of the handler URL patterns in the target service. The url can include query parameters if the tasks's method is GET or PULL. If no url is specified the default URL /_ah/queue/[QUEUE_NAME] is used, where [QUEUE_NAME] is the name of the task's queue.

Passing data to the handler

You can pass data to the handler as query parameters in the task's URL—but only if you set the task's method to GET or PULL.

TaskOptions.Builder constructor has methods to add data as the payload of the HTTP request, and as parameters, which are added to the URL as query parameters.

Do not specify params if you are using the POST method along with a payload, or if you are using the GET method and you've included a url with query parameters.

Naming a task

When you create a new task, App Engine assigns the task a unique name by default. You can assign your own name to a task by using the name parameter.

A task name must be unique within a queue. If you try to add another task with the same name to a the queue, the operation will fail. After a task is removed from a queue you can't insert a task with the same name into the queue until 10 days have passed. A task name can contain uppercase and lowercase letters, numbers, underscores, and hyphens. The maximum length for a task name is 500 characters.

Recommended: Let App Engine generate task names automatically.

Adding tasks asynchronously

By default, the Task Queue API calls are synchronous. For most scenarios, synchronous calls work fine. For instance, adding a task is usually a fast operation: the median time to add a task is 5 ms and 1 out of every 1000 tasks can take up to 300 ms. Periodic incidents, such as back-end upgrades, can cause spikes to 1 out of every 1000 tasks taking up to 1 second.

If you are building an application that needs low latency, the Task Queue API provides asynchronous calls that minimize latency.

Consider the case where you need to add 10 tasks to 10 different queues (thus you cannot batch them). In the worst case, calling queue.add() 10 times in a loop could block up to 10 seconds, although it's very rare. Using the asynchronous interface to add tasks to their respective queues in parallel, you can reduce the worst-case latency to 1 second.

If you want to make asynchronous calls to a task queue, use the asynchronous methods provided by the Queue class. Call get on the returned Future to force the request to complete. When asynchronously adding tasks in a transaction, you should call get() on the Future before committing the transaction to ensure that the request has finished.

Enqueuing tasks in Cloud Datastore transactions

You can enqueue a task as part of a Google Cloud Datastore transaction, such that the task is only enqueued—and guaranteed to be enqueued—if the transaction is committed successfully. Tasks added in a transaction are considered to be a part of it and have the same level of isolation and consistency.

An application cannot insert more than five transactional tasks into task queues during a single transaction. Transactional tasks must not have user-specified names.

The following code sample demonstrates how to insert transactional tasks into a push queue as part of a Cloud Datastore transaction:

DatastoreService ds = DatastoreServiceFactory.getDatastoreService();
Queue queue = QueueFactory.getDefaultQueue();
try {
    Transaction txn = ds.beginTransaction();

    // ...


    // ...
} catch (DatastoreFailureException e) {

Using the DeferredTasks instead of a worker service

Setting up a handler for each distinct task (as described in the previous sections) can be cumbersome, as can serializing and deserializing complex arguments for the task—particularly if you have many diverse but small tasks that you want to run on the queue. The Java SDK includes an interface called DeferredTask. This interface lets you define a task as a single method. This interface uses Java serialization to package a unit of work into a Task Queue. A simple return from that method is considered success. Throwing any exception from that method is considered a failure.

 * A hypothetical expensive operation we want to defer on a background task.
public static class ExpensiveOperation implements DeferredTask {
  public void run() {
    System.out.println("Doing an expensive operation...");
    // expensive operation to be backgrounded goes here

 * Basic demonstration of adding a deferred task.
 * @param request servlet request
 * @param resp servlet response
public void doGet(final HttpServletRequest request,
    final HttpServletResponse resp) throws IOException {
  // Add the task to the default queue.
  Queue queue = QueueFactory.getDefaultQueue();

  // Wait 5 seconds to run for demonstration purposes
  queue.add(TaskOptions.Builder.withPayload(new ExpensiveOperation())
      .etaMillis(System.currentTimeMillis() + DELAY_MS));

  resp.getWriter().println("Task is backgrounded on queue!");

Working with tasks in a multi-tenant application

By default, push queues use the current namespace as set in the namespace manager at the time the task is created. If your application uses multitenancy, see the Namespaces Java API.

What's next