0

I use pub-sub com.google.apis:google-api-services-pubsub:v1-rev357-1.22.0 for comunication between different App Engine modules.

I have a subscription that push in given endpoint when new message is received. If delivery of message fails PubSub retry sending of message.

When redeploy version while AppEngine create instance for given microservice requests are routed to default microservice. In my default microservice i has processing of _ah/push_handlers/* path and after this microservice says 200, PubSub accept that message is delivered.

Where can i read what happens with requests to a given microservice while new instance is being created?

Guillem Xercavins
  • 6,938
  • 1
  • 16
  • 35
S.Ivanova
  • 7
  • 3
  • Your question is a little unclear. You have push subscribers that do not receive messages even if you haven't sent back a 200 response? This tends to happen when you deploy a new version of your App Engine module? – Kamal Aboul-Hosn Feb 20 '18 at 13:16
  • I have subscriber that push into given endpoint and i want pubsub to retry while success response is retrieved from servlet that receive messages. If error is received pubsub retry, but if i deploy new version of appengine retry stop though is not received status ```200``` – S.Ivanova Feb 20 '18 at 14:09
  • So you want Pub/Sub to retry the delivery of your message when a success response (a 200 response) is received? I'm still not clear. You say " i want pubsub to retry while success response is retrieved" but then say "if i deploy new version of appengine retry stop though is not received status 200." It is still unclear whether you are asking for Cloud Pub/Sub to retry when a success happens or when a failure happens. – Kamal Aboul-Hosn Feb 20 '18 at 14:25
  • Yes. I want Pub/Sub to retry the delivery of the message while a success response (a 200 response) is received. My problem is that when deploy a new version of the appengine PubSub stops to retry. Is a clear now? – S.Ivanova Feb 20 '18 at 14:48
  • Pub/Sub treats a 200 as an acknowledgement, meaning it will not retry delivery of a messages (other than edge cases of redelivery given Pub/Sub's at-least-once delivery guarantee). Are you saying that prior to redeployment, Pub/Sub continually delivers messages for which you returned a 200 and then after deployment does not? – Kamal Aboul-Hosn Feb 20 '18 at 14:57
  • After redeployment, PubSub stops develery of not received message (message with status 500) , i.e. last response CloudPubSub-Google /_ah/push-handlers/pubsub POST 500 9.29 KB 68 ms CloudPubSub-Google , but Pub/Sub not retry, i.e i not receive message. – S.Ivanova Feb 20 '18 at 16:36
  • My push endpoint was ```https://test-dot-testapp.appspot.com/_ah/push-handlers/...``` and after remove ```_ah``` from path all working as expected, i.e. PubSub delevery message while message is not received. I am not sure why ```_ah``` in push endpoint affect of PubSub retry. – S.Ivanova Feb 21 '18 at 05:33
  • This sounds like it was something perhaps in the AppEngine deployment, not in Pub/Sub. Perhaps the endpoint moved in the new deployed version? There isn't any Pub/Sub client software when using a push endpoint, so you didn't pick up any new code of that nature. But perhaps something changed with your AppEngine environment. – Kamal Aboul-Hosn Feb 21 '18 at 12:54
  • You are right. The reason for this problem is that while appengine create instance of a new microservice after redeploy, requests from PubSub are routed to default microservice. In my default microservice i has processing of _ah/push_handlers/* and after this microservice says 200, PubSub accept that message is delivered. But i don't know why while AppEngine create instance to given microservice , requests are routed to default microservice? Any ideas? – S.Ivanova Feb 22 '18 at 12:18
  • One possible reason, as explained in Dan's answer [here](https://stackoverflow.com/questions/44178971/what-purpose-does-the-default-service-serve-in-googles-app-engine), is that the `default` service acts as "the fallback destination for routing a request using a dispatch.yaml file if none of the routing rules is matched". So it can be that it is routed while there is no instance to serve traffic for the microservice. – Guillem Xercavins Feb 27 '18 at 13:20

0 Answers0