It's why you don't put any significant payload in the Task. You put it in
a Datastore entity and use the key as the payload.
Or if you really don't care if it fails, put it in Memcache and use the key
as the payload.
On Tuesday, May 24, 2016 at 5:33:06 PM UTC-5, barryhunter wrote:
>
> Possibly
Possibly no real advantage, just an alternative :)
I suppose, there is a small risk of exceeding the Task Queue storage free
quota, but seems unlikely.
On 24 May 2016 at 22:59, 'Alex Martelli' via Google App Engine <
google-appengine@googlegroups.com> wrote:
> Not sure what advantage you'd envis
Not sure what advantage you'd envision for XMPP here -- this kind of job
(handing out a task to a worker) is exactly what task queues were designed
for.
Alex
On Tue, May 24, 2016 at 2:51 PM, Barry Hunter
wrote:
> Or maybe even use XMPP, to 'chat' with itself.
> https://cloud.google.com/appengin
Or maybe even use XMPP, to 'chat' with itself.
https://cloud.google.com/appengine/docs/java/xmpp/
The front end just sends a chat message.
The backend worker subscribes to the channel, and performs the POSTs
On 24 May 2016 at 22:44, Barry Hunter wrote:
> Maybe you could use the Task Queue? ins
Maybe you could use the Task Queue? inserts should generally by quick.
Then a 'worker' can process tasks in background - performing the actual
POSTs
On 24 May 2016 at 09:17, Ashley Finney <2dea...@gmail.com> wrote:
> In GAE I want to fire a Post message at a URL but I do not want to wait
> for t
In GAE I want to fire a Post message at a URL but I do not want to wait for
the response, the call should be as quick and cheap (cpu/memory/cost) as
possible. All I'm doing is using this to send a message to another server.
I don't mind if I lose messages.
Instead of using "appengine/urlfetch"