Deferred tasks no longer executing?

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Defer a task to a backend.
2. Error appears

What is the expected output? What do you see instead?

With 0.5.2 of the server, my code ran fine. Now I get this:

ERROR    2013-02-06 21:46:07,052 taskqueue_stub.py:1909] An error occured while 
sending the task "nIaDqLtHRXDvVXlq2GSL-batch-0_1" (Url: "/_ah/queue/deferred") 
in queue "default". Treatin
g as a task error.
Traceback (most recent call last):
  File "/opt/appengine-devappserver2-experiment/google/appengine/api/taskqueue/taskqueue_stub.py", line 1897, in ExecuteTask
    connection.endheaders()
  File "/usr/lib/python2.7/httplib.py", line 954, in endheaders
    self._send_output(message_body)
  File "/usr/lib/python2.7/httplib.py", line 814, in _send_output
    self.send(msg)
  File "/usr/lib/python2.7/httplib.py", line 776, in send
    self.connect()
  File "/usr/lib/python2.7/httplib.py", line 757, in connect
    self.timeout, self.source_address)
  File "/usr/lib/python2.7/socket.py", line 553, in create_connection
    for res in getaddrinfo(host, port, 0, SOCK_STREAM):
gaierror: [Errno -2] Name or service not known

What version of the product are you using? On what operating system?
0.6.0 on Arch Linux (64-bit)

Please provide any additional information below.

Original issue reported on code.google.com by prat...@referabuyer.com on 6 Feb 2013 at 9:48

[GoogleCodeExporter]

I don't think that it worked with 0.5.2 - the task was incorrectly run on the 
frontend.

The taskqueue stub does not work correctly with backends.

Original comment by bquin...@google.com on 7 Feb 2013 at 1:54

[GoogleCodeExporter]

Well that I knew, but at least in 0.5.2 the task still ran even if it was on 
the wrong target. In 0.6.0 it doesn't run at all (just produces the error given 
above). 

Original comment by someone1@gmail.com on 7 Feb 2013 at 6:10

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

I'm having this error, too. I'm running on the trunk copy from Google Code, new 
to a couple of days ago. My tasks have an ETA for a few seconds in the future. 
Tasks that are run automatically based on the time are producing the errors. 
Tasks that I immediately go to the Admin and press "Run" on are executed 
without error.

I have one backend (named "worker") and one frontend, and am targetting my 
backend. I am not using deferred tasks at all. The error will occur for every 
task that is left to be run per my ETA.

If you run repr() on the task object, you get the following:

[App Instance] [0] [web.py:26] INFO TASK: Task<eta=datetime.datetime(2013, 3, 
7, 4, 42, 19, 657644, tzinfo=_UTCTimeZone()), headers={'Host': 
'worker.localhost:9000', 'X-AppEngine-Current-Namespace': '', 'content-type': 
'application/x-www-form-urlencoded'}, method='POST', 
name='Test-20130307-044149', payload='aa=55', queue_name=None, 
retry_options=None, size=133, target='worker', url='/task/process', 
was_deleted=False, was_enqueued=False>

Notice the "Host" header: worker.localhost:9000 . 

Some more debugging shows that during the header processing, it attempts to 
resolve this, which fails. Obviously, this resolution makes sense in the 
context of production (where the FQDN of the backend machine would be 
"worker.<application ID>.appspot.com", but doesn't make any when in development.

Is there any way that we can omit the "Host" header, since it probably isn't 
even necessary in development (we're not concerned about virtual-hosts, I don't 
think), and it's broken, anyway. Either that, or use "localhost", or verifying 
that the right names have been added to the system's name resolution 
(/etc/hosts, etc..) and displaying a message if they haven't.

Dustin Oprea

Original comment by myselfasunder@gmail.com on 7 Mar 2013 at 5:06

[GoogleCodeExporter]

This is also an error on the regular dev server bundled in 1.7.5, so I'm not 
sure if this issue lies within the scope of devappserver2. I can fix this by 
setting the target to "None" if i'm in the development server just for the sake 
of testing, and switch it back to its actual target while in production. It'd 
be nice if it behaved nicely no matter what target was specified, even if it 
only ran everything on the "frontend" dev server

Original comment by prat...@condorcapital.com on 7 Mar 2013 at 6:31

[GoogleCodeExporter]

We are working on a fix for this.

Original comment by bquin...@google.com on 10 Mar 2013 at 10:12

• Changed state: Started

[GoogleCodeExporter]

Original comment by bquin...@google.com on 11 Mar 2013 at 6:27

• Changed state: Fixed