Testing multiple AppEngine services with task queues












0















I have an AppEngine app with 2 services, where Service A is queueing tasks for Service B using the task (push) queue. How do I test this using the development server? When running multiple services with the development server, each service gets a unique port number, and the task queue can't resolve the URL because the target URL is actually running on another port, i.e. Service A is on port 8080 and Service B is on port 8081. This all works great in production where everything is on the same port, but how do I go about testing this locally?










share|improve this question

























  • push or pull task queue?

    – Dan Cornilescu
    Nov 26 '18 at 16:32











  • Push. I just updated the description to reflect this.

    – Kieran W.
    Nov 26 '18 at 19:30











  • Can you show your queue.yaml config?

    – Dan Cornilescu
    Nov 26 '18 at 21:33











  • I'm using the default queue, so I don't have a queue config file

    – Kieran W.
    Nov 27 '18 at 7:09
















0















I have an AppEngine app with 2 services, where Service A is queueing tasks for Service B using the task (push) queue. How do I test this using the development server? When running multiple services with the development server, each service gets a unique port number, and the task queue can't resolve the URL because the target URL is actually running on another port, i.e. Service A is on port 8080 and Service B is on port 8081. This all works great in production where everything is on the same port, but how do I go about testing this locally?










share|improve this question

























  • push or pull task queue?

    – Dan Cornilescu
    Nov 26 '18 at 16:32











  • Push. I just updated the description to reflect this.

    – Kieran W.
    Nov 26 '18 at 19:30











  • Can you show your queue.yaml config?

    – Dan Cornilescu
    Nov 26 '18 at 21:33











  • I'm using the default queue, so I don't have a queue config file

    – Kieran W.
    Nov 27 '18 at 7:09














0












0








0








I have an AppEngine app with 2 services, where Service A is queueing tasks for Service B using the task (push) queue. How do I test this using the development server? When running multiple services with the development server, each service gets a unique port number, and the task queue can't resolve the URL because the target URL is actually running on another port, i.e. Service A is on port 8080 and Service B is on port 8081. This all works great in production where everything is on the same port, but how do I go about testing this locally?










share|improve this question
















I have an AppEngine app with 2 services, where Service A is queueing tasks for Service B using the task (push) queue. How do I test this using the development server? When running multiple services with the development server, each service gets a unique port number, and the task queue can't resolve the URL because the target URL is actually running on another port, i.e. Service A is on port 8080 and Service B is on port 8081. This all works great in production where everything is on the same port, but how do I go about testing this locally?







google-app-engine task-queue






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Nov 26 '18 at 19:29







Kieran W.

















asked Nov 26 '18 at 16:19









Kieran W.Kieran W.

388




388













  • push or pull task queue?

    – Dan Cornilescu
    Nov 26 '18 at 16:32











  • Push. I just updated the description to reflect this.

    – Kieran W.
    Nov 26 '18 at 19:30











  • Can you show your queue.yaml config?

    – Dan Cornilescu
    Nov 26 '18 at 21:33











  • I'm using the default queue, so I don't have a queue config file

    – Kieran W.
    Nov 27 '18 at 7:09



















  • push or pull task queue?

    – Dan Cornilescu
    Nov 26 '18 at 16:32











  • Push. I just updated the description to reflect this.

    – Kieran W.
    Nov 26 '18 at 19:30











  • Can you show your queue.yaml config?

    – Dan Cornilescu
    Nov 26 '18 at 21:33











  • I'm using the default queue, so I don't have a queue config file

    – Kieran W.
    Nov 27 '18 at 7:09

















push or pull task queue?

– Dan Cornilescu
Nov 26 '18 at 16:32





push or pull task queue?

– Dan Cornilescu
Nov 26 '18 at 16:32













Push. I just updated the description to reflect this.

– Kieran W.
Nov 26 '18 at 19:30





Push. I just updated the description to reflect this.

– Kieran W.
Nov 26 '18 at 19:30













Can you show your queue.yaml config?

– Dan Cornilescu
Nov 26 '18 at 21:33





Can you show your queue.yaml config?

– Dan Cornilescu
Nov 26 '18 at 21:33













I'm using the default queue, so I don't have a queue config file

– Kieran W.
Nov 27 '18 at 7:09





I'm using the default queue, so I don't have a queue config file

– Kieran W.
Nov 27 '18 at 7:09












1 Answer
1






active

oldest

votes


















1














The push queue configuration allows for specifying the target service by name, which the development server understands. From Syntax:




target (push queues)



Optional. A string naming a service/version, a frontend version, or a
backend, on which to execute all of the tasks enqueued onto this
queue.



The string is prepended to the domain name of your app when
constructing the HTTP request for a task. For example, if your app ID
is my-app and you set the target to my-version.my-service, the
URL hostname will be set to
my-version.my-service.my-app.appspot.com.



If target is unspecified, then tasks are invoked on the same version
of the application where they were enqueued. So, if you enqueued a
task from the default application version without specifying a target
on the queue, the task is invoked in the default application version.
Note that if the default application version changes between the time
that the task is enqueued and the time that it executes, then the task
will run in the new default version.



If you are using services along with a dispatch file, your task's
HTTP request might be intercepted and re-routed to another service.




For example a basic queue.yaml would be along these lines:



queue:

- name: service_a
target: service_a

- name: service_b
target: service_b


I'm not 100% certain if this alone is sufficient, personally I'm also using a dispatch.yaml file as I need to route requests other than tasks. But for that you need to have a well-defined pattern in the URLs as host-name based patterns aren't supported in the development server. For example if the Service A requests use /service_a/... paths and Service B use /service_b/... paths then these would do the trick:



dispatch:

- url: "*/service_a/*"
service: service_a

- url: "*/service_b/*"
service: service_b


In your case it might be possible to achieve what you want with just a dispatch file - i.e. still using the default queue. Give it a try.






share|improve this answer
























  • Excellent, thank you very much!

    – Kieran W.
    Nov 28 '18 at 8:19











Your Answer






StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");

StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});


}
});














draft saved

draft discarded


















StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53485180%2ftesting-multiple-appengine-services-with-task-queues%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown

























1 Answer
1






active

oldest

votes








1 Answer
1






active

oldest

votes









active

oldest

votes






active

oldest

votes









1














The push queue configuration allows for specifying the target service by name, which the development server understands. From Syntax:




target (push queues)



Optional. A string naming a service/version, a frontend version, or a
backend, on which to execute all of the tasks enqueued onto this
queue.



The string is prepended to the domain name of your app when
constructing the HTTP request for a task. For example, if your app ID
is my-app and you set the target to my-version.my-service, the
URL hostname will be set to
my-version.my-service.my-app.appspot.com.



If target is unspecified, then tasks are invoked on the same version
of the application where they were enqueued. So, if you enqueued a
task from the default application version without specifying a target
on the queue, the task is invoked in the default application version.
Note that if the default application version changes between the time
that the task is enqueued and the time that it executes, then the task
will run in the new default version.



If you are using services along with a dispatch file, your task's
HTTP request might be intercepted and re-routed to another service.




For example a basic queue.yaml would be along these lines:



queue:

- name: service_a
target: service_a

- name: service_b
target: service_b


I'm not 100% certain if this alone is sufficient, personally I'm also using a dispatch.yaml file as I need to route requests other than tasks. But for that you need to have a well-defined pattern in the URLs as host-name based patterns aren't supported in the development server. For example if the Service A requests use /service_a/... paths and Service B use /service_b/... paths then these would do the trick:



dispatch:

- url: "*/service_a/*"
service: service_a

- url: "*/service_b/*"
service: service_b


In your case it might be possible to achieve what you want with just a dispatch file - i.e. still using the default queue. Give it a try.






share|improve this answer
























  • Excellent, thank you very much!

    – Kieran W.
    Nov 28 '18 at 8:19
















1














The push queue configuration allows for specifying the target service by name, which the development server understands. From Syntax:




target (push queues)



Optional. A string naming a service/version, a frontend version, or a
backend, on which to execute all of the tasks enqueued onto this
queue.



The string is prepended to the domain name of your app when
constructing the HTTP request for a task. For example, if your app ID
is my-app and you set the target to my-version.my-service, the
URL hostname will be set to
my-version.my-service.my-app.appspot.com.



If target is unspecified, then tasks are invoked on the same version
of the application where they were enqueued. So, if you enqueued a
task from the default application version without specifying a target
on the queue, the task is invoked in the default application version.
Note that if the default application version changes between the time
that the task is enqueued and the time that it executes, then the task
will run in the new default version.



If you are using services along with a dispatch file, your task's
HTTP request might be intercepted and re-routed to another service.




For example a basic queue.yaml would be along these lines:



queue:

- name: service_a
target: service_a

- name: service_b
target: service_b


I'm not 100% certain if this alone is sufficient, personally I'm also using a dispatch.yaml file as I need to route requests other than tasks. But for that you need to have a well-defined pattern in the URLs as host-name based patterns aren't supported in the development server. For example if the Service A requests use /service_a/... paths and Service B use /service_b/... paths then these would do the trick:



dispatch:

- url: "*/service_a/*"
service: service_a

- url: "*/service_b/*"
service: service_b


In your case it might be possible to achieve what you want with just a dispatch file - i.e. still using the default queue. Give it a try.






share|improve this answer
























  • Excellent, thank you very much!

    – Kieran W.
    Nov 28 '18 at 8:19














1












1








1







The push queue configuration allows for specifying the target service by name, which the development server understands. From Syntax:




target (push queues)



Optional. A string naming a service/version, a frontend version, or a
backend, on which to execute all of the tasks enqueued onto this
queue.



The string is prepended to the domain name of your app when
constructing the HTTP request for a task. For example, if your app ID
is my-app and you set the target to my-version.my-service, the
URL hostname will be set to
my-version.my-service.my-app.appspot.com.



If target is unspecified, then tasks are invoked on the same version
of the application where they were enqueued. So, if you enqueued a
task from the default application version without specifying a target
on the queue, the task is invoked in the default application version.
Note that if the default application version changes between the time
that the task is enqueued and the time that it executes, then the task
will run in the new default version.



If you are using services along with a dispatch file, your task's
HTTP request might be intercepted and re-routed to another service.




For example a basic queue.yaml would be along these lines:



queue:

- name: service_a
target: service_a

- name: service_b
target: service_b


I'm not 100% certain if this alone is sufficient, personally I'm also using a dispatch.yaml file as I need to route requests other than tasks. But for that you need to have a well-defined pattern in the URLs as host-name based patterns aren't supported in the development server. For example if the Service A requests use /service_a/... paths and Service B use /service_b/... paths then these would do the trick:



dispatch:

- url: "*/service_a/*"
service: service_a

- url: "*/service_b/*"
service: service_b


In your case it might be possible to achieve what you want with just a dispatch file - i.e. still using the default queue. Give it a try.






share|improve this answer













The push queue configuration allows for specifying the target service by name, which the development server understands. From Syntax:




target (push queues)



Optional. A string naming a service/version, a frontend version, or a
backend, on which to execute all of the tasks enqueued onto this
queue.



The string is prepended to the domain name of your app when
constructing the HTTP request for a task. For example, if your app ID
is my-app and you set the target to my-version.my-service, the
URL hostname will be set to
my-version.my-service.my-app.appspot.com.



If target is unspecified, then tasks are invoked on the same version
of the application where they were enqueued. So, if you enqueued a
task from the default application version without specifying a target
on the queue, the task is invoked in the default application version.
Note that if the default application version changes between the time
that the task is enqueued and the time that it executes, then the task
will run in the new default version.



If you are using services along with a dispatch file, your task's
HTTP request might be intercepted and re-routed to another service.




For example a basic queue.yaml would be along these lines:



queue:

- name: service_a
target: service_a

- name: service_b
target: service_b


I'm not 100% certain if this alone is sufficient, personally I'm also using a dispatch.yaml file as I need to route requests other than tasks. But for that you need to have a well-defined pattern in the URLs as host-name based patterns aren't supported in the development server. For example if the Service A requests use /service_a/... paths and Service B use /service_b/... paths then these would do the trick:



dispatch:

- url: "*/service_a/*"
service: service_a

- url: "*/service_b/*"
service: service_b


In your case it might be possible to achieve what you want with just a dispatch file - i.e. still using the default queue. Give it a try.







share|improve this answer












share|improve this answer



share|improve this answer










answered Nov 27 '18 at 10:38









Dan CornilescuDan Cornilescu

28.8k113564




28.8k113564













  • Excellent, thank you very much!

    – Kieran W.
    Nov 28 '18 at 8:19



















  • Excellent, thank you very much!

    – Kieran W.
    Nov 28 '18 at 8:19

















Excellent, thank you very much!

– Kieran W.
Nov 28 '18 at 8:19





Excellent, thank you very much!

– Kieran W.
Nov 28 '18 at 8:19




















draft saved

draft discarded




















































Thanks for contributing an answer to Stack Overflow!


  • Please be sure to answer the question. Provide details and share your research!

But avoid



  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.


To learn more, see our tips on writing great answers.




draft saved


draft discarded














StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53485180%2ftesting-multiple-appengine-services-with-task-queues%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown





















































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown

































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown







Popular posts from this blog

Contact image not getting when fetch all contact list from iPhone by CNContact

count number of partitions of a set with n elements into k subsets

A CLEAN and SIMPLE way to add appendices to Table of Contents and bookmarks