Cool, that all makes sense, I think I understand what /_ah/background means now. So to clarify, every time I create a background thread, what actually happens is the AppEngine sends a request to /_ah/background on the same instance to execute that thread, and I should expect to see log output from that thread in the /_ah/background request rather than in the log from the original request? This seems to match what I see with Firebase - the trace shows that it connects to a socket for exactly 60s, then the request completes. I assume this is Firebase choosing to connect for 60s at a time rather than AppEngine killing it.
The modules API looks like it's on the right track, but it doesn't seem to have a "shut down the current instance" method. It only has methods to start and stop all instances for a version or to change the number of instances for a manually scaled app, which doesn't quite do what I need. Am I reading it correctly? I'm using Firebase's newish JVM client (described a bit here <https://cloud.google.com/solutions/mobile/firebase-app-engine-android-studio>), which has explicit support for App Engine. It looks like it's pretty much the same as the Android client with some reflection magic to figure out if it's running on GAE and adjust its thread creation strategy accordingly. I'm still trying to figure out exactly how it manages its thread (talking to them here <https://groups.google.com/forum/?utm_medium=email&utm_source=footer#!msg/firebase-talk/Yl-Gcbo8ogQ/UAGrxIo2EAAJ>), but I believe they're used to listen on web sockets for changes to remote data to invoke user callbacks. I think I'll try running some tests on a basic scaling module capped at one instance to try and deduce exactly what it's doing. As long as you're submitting docs feedback, one other thing that I couldn't find described anywhere is how basic scaling instances handle concurrent requests. I assume it caps the number of current request in the same way autoscaling does, but the cap doesn't seem to be configurable like it is for autoscaling and it's not documented anywhere. I was getting what looked like a lot of CPU contention on my instances that I was only able to resolve by setting threadsafe to false, which was a bit more extreme than I would have preferred. On Wednesday, December 9, 2015 at 4:51:00 PM UTC-8, Nick (Cloud Platform Support) wrote: > > ... and to clarify, by "fixed" in the docs I mean that it should be > mentioned there. The behaviour makes sense - the reason is that each > background thread actually enqueues a long-running request not governed by > the same execution timeline as a normal request. When it finally > terminates, you'll see that it leaves a log line with a timestamp of its > *termination, > *however the milliseconds spent on the request will show its actual > duration, which should be subtracted from the time of the log line to > determine when the process started. Since this request (to /_ah/background) > is "being handled" and "has not returned yet", the instance stays up. > > On Wednesday, December 9, 2015 at 7:23:46 PM UTC-5, Nick (Cloud Platform > Support) wrote: >> >> Hey Erik, >> >> Yes, background threads yet to terminate will cause the instance to >> remain standing, regardless of the idle timeout. I've just submitted a docs >> feedback which will hopefully see this fixed shortly in the "Modules in >> Python" docs page. You can, as Christian suggests, use the modules controls >> to manually turn-down an instance. I'm curious which Firebase library >> you're using, by the way, and how it uses background threads? >> >> On Wednesday, December 9, 2015 at 4:17:16 AM UTC-5, Erik Kuefler wrote: >>> >>> The description of basic scaling >>> <https://cloud.google.com/appengine/docs/java/modules/#Java_Instance_scaling_and_class> >>> >>> is a little vague about the exact conditions that cause an instance created >>> with basic scaling to be shut down. It says an instance is evicted when it >>> "has not received a request for more than `idle-timeout`", but it's not >>> clear to me whether this includes background threads and the >>> "/_ah/background" request that they generate. >>> >>> My problem is that my machines are staying alive longer than I expect >>> them to and I suspect a background thread might be the culprit. I'm using a >>> library (Firebase) that creates background threads but provides no way of >>> shutting them down. Will this cause my machines to never be evicted? If so, >>> is there a way for me to either forcibly terminate all background threads, >>> or to shut down the instance from my own background thread (so I can >>> implement my own idle timeout)? >>> >> -- You received this message because you are subscribed to the Google Groups "Google App Engine" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/google-appengine. To view this discussion on the web visit https://groups.google.com/d/msgid/google-appengine/24554753-06d3-43fe-a518-21146c9212e5%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
