-1

I am importing contacts from a CSV file, and using the blobstore service of the google app engine to save the blob and i send the blobkey as a parameter to the task queue url. So that the task queue url can use the blob key to parse the CSV file and save it in the datastore.

This here is my java code for creating a task queue.

Queue queue = QueueFactory.getDefaultQueue();

queue.add(TaskOptions.Builder.withUrl("/queuetoimport").param("contactsToImport", contactsDetail));

The Task queue actually gets executed but it does not end. It endlessly keep on saving the same contact to the datastore until i manually delete it.

What could be the reason.

Karthik Amar
  • 217
  • 5
  • 17
  • 3
    What HTTP status code is your task handler returning? If it's a status code outside the range 200..299, the task will be retried, per https://cloud.google.com/appengine/docs/python/taskqueue/overview-push#task_deadlines – Dave W. Smith Jan 23 '15 at 04:48
  • Thanks for the info. The issue is solved. It was because of the carriage return i failed to notice at the end of the CSV file causing the task handler to throw an exception resulting in the retries without ending. – Karthik Amar Jan 23 '15 at 05:59

1 Answers1

2

This is done for error recovery. Suppose, for example, that your task was fetching a JSON feed from the network, parsing it, and storing it in a database... in the event that the network connection failed, timed out, etc. or the feed that was returned happened to be bad temporarily and failed to parse or any other number of intermittent, probabilistic sources of failure, this automatic retrying behavior (with exponential back off) would ensure that the task eventually completed successfuly (assuming that the failure is one that could be fixed by retrying and not a programmer error that would guarantee failure each and every time). The HTTP status code of the task is used to determine how the task completed (successfully or unsuccessfully) to determine if it needs to be retried. If you don't want the task to be retried, make sure it completes succesfully (and lets App Engine know about it by using a success status code, which is any of the 2xx-level codes).

If you consider the contacts example, ensuring that the contact is saved (even if there is a temporary glitch in the task handler for it), is much better than silently dropping user data.

Michael Aaron Safyan
  • 93,612
  • 16
  • 138
  • 200
  • Thanks for the info. The issue is solved. It was because of the carriage return i failed to notice at the end of the CSV file causing the task handler to throw an exception resulting in the retries without ending. – Karthik Amar Jan 23 '15 at 05:59