All the servlets on App Engine are being timed Out. And they throw SocketTimeOut Exception.
Same Happens for Google App Script.
Since no information has been provided about the environment it's difficult to suggest a course of action.
However, if you're using the Python standard environment on App Engine, note that this environment has quotas on sockets depending upon your package. If you hit these then you may start to experience SocketTimeOut exceptions.
Related
I can't find any documentation on how gcp scheduler works under the hood. An App Engine is needed in the project, so I assume that the Http calls or Pub/Sub messages are started from the App Engine.
Currently I can use a cloud scheduler even without an App Engine in the project. Apparently a compute engine that also contains a permanently running VM is also sufficient. Could someone confirm my assumptions please or does anyone have sources on this?
I can't tell you how work Cloud Scheduler under the hood. I can just tell you that works well!
I'm sure there is a VM, or a cluster of VM, on Google serverless environment, and your Cloud Scheduler job is set on it. It's serverless, the under the hood doesn't matter, it works, and it's what I want!
Now, the relation with App Engine can be confusing. In fact, there is no longer relation between the product now, but you need the App Engine API activated on your project to use Cloud Scheduler. This strange things is normal if you have been using Google Cloud for a while. At the beginning, only App Engine existed, and Datastore, Cloud Task, Cloud Scheduler was all "modules" of App Engine. Years, after years, google has refactored and extracted these modules to create independent products, as you can see them today. However, some relations are still present, like the API activation.
I was in process of deploying my flask web app using google app engine and for achieving this step, I followed the below steps
Creating the code for the application (Web Based)
Creating a lib folder where all the packages are installed using the requirements.txt file
Created appengine_config.py where the lib folder is added.
Created the file app.yaml to test the application on the local system before deploying on the google app engine.
I was successful in these 4 steps. After the completion of these steps,
I run the below command
/usr/lib/google-cloud-sdk/bin/dev_appserver.py --admin_port=9000 --port=9999 app.yaml
As a result, I found the google app engine is running successfully on the local server. Please see the screenshot for this from here but when I tried to run the code at port 9999 on local server, I got the below error
import multiprocessing
File "/usr/lib/python2.7/multiprocessing/__init__.py", line 65, in <module>
from multiprocessing.util import SUBDEBUG, SUBWARNING
File "/usr/lib/python2.7/multiprocessing/util.py", line 41, in <module>
from subprocess import _args_from_interpreter_flags
ImportError: cannot import name _args_from_interpreter_flags
To resolve this error, I searched on the internet about this error and came up with the below conclusion
"You can't use multiprocessing on appengine. Multiprocessing is for
creating and coordinating sub processes for parallelism.
That is not an option on appengine. Appengine has other facilities like
async methods, task queues and backends (which can use traditional
threading)."
From my research on internet, above error is caused by multiprocessing and subprocess.py and google cloud engine does not support this.
My worry is if this is exactly the same as I understand then what is the way to tackle this as this would not let the code to be deployed on the google cloud engine.
Any ideas or solution is highly appreciated.
The conclusion that you have reached is absolutely correct in regards to App Engine Standard, which you seem to be using (based on the error that you are getting).
Due to how it’s implemented, App Engine Standard does not allow for multiprocessing. You can also check this Google Groups post for additional background.
Alternatively, you can use the Python runtime with App Engine Flex. That runtime uses Gunicorn, which uses workers to handle requests. With App Engine Flex, you will be able to configure the number of CPU cores for your application.
Keep in mind that App Engine Flex will incur costs based on usage rather than instance hours.
I'm trying to run a simple Ktor server on Google App Engine Standard. If I run their sample code on github it works well, but fails as soon as I call any App Engine API with the following message:
Can't make API call memcache.Set in a thread that is neither the original request thread nor a thread created by ThreadManager
All App Engine APIs trigger similar error messages. Is this related to how Ktor handles requests, and is there a way to make them work?
I think that the Google Cloud java library doesn't have this threading limitation, but unfortunately I can't use it. I need to access the App Engine Memcache service, which is only available through the App Engine APIs.
The Nginx load balancer of Google Cloud App Engine Flexible Environment (with custom runtime) logs remote IP addresses etc. to its access logs. What if I wanted to disable that behavior? Is it possible in any way? Docs don't say anything about configuring Nginx by yourself. Haven't find anything from the console either.
In order to disable any IP logging, you have to disable the Google Cloud Load Balancer logs and also any logging done by NGINX.
In order to disable the ones done by the Load Balancer of Google Cloud, this page of their official documentation explains how to do it. You would need select "Disable log source" from the cloud HTTP Load Balancer.
On the other hand, to configure NGINX, apparently the only way to do so is modifying the nginx.conf file.
Because this you are using App Engine Flex and it's not possible to access these virtual machines/containers once the App had been deployed, you would need make sure to change the configuration before executing the deployment.
I've found a Serverfault post which does explain how to disable NGINX logging, and another article which does explain the NGINX configurations with better depth in case they might be of use for you.
I believe this won't be possible. As per this Logging docs page:
The App Engine flexible environment produces the following logs:
Request logs record requests sent to all App Engine apps. The request
log is provided by default and you cannot opt out of receiving it.
App logs record activity by software within the App Engine app. The
log is provided by default and you cannot opt out of receiving it.
Runtime logs are provided from the flexible environment using a
preinstalled Logging agent.
My team and I are working on the Trendy Lights Tutorial.
We have set up all the files and also have converted the .p12 key to .pem key but failed to run the app on the Google Cloud Platform and constantly got the error message saying:
You do not have permission to access project [...] and service
"cloudbuilt.googleapis.com" is not for consumer..."
We have already whitelisted our service account for the use of Earth Engine. Does anyone know what the problem might be?
Thank you so much!
I see that you are attempting to deploy your application to the App Engine Flexible Environment.
The Flexible environment differs from the Standard environment in that it gives you more control over the individual instances that are running your deployed application. It does this by hosting your application within Docker on Compute Engine virtual machines.
Therefore, you will need to enable the Compute Engine API for your project so that the GCloud tool can start new Compute Engine virtual machines when you deploy your application.
Note: Since the Flexible environment uses Compute Engine resources, you will also need to enable billing for your project.
If after performing the above you still experience the 'cloudbuild.googleapis.com' error, I ask that you run gcloud components update, then ensure that the value of account seen in the output of the command gcloud info has Owner or Editor permissions in your project.
If it still persists after all of the above, you should then open a Public Issue Tracker to inform our backend team of the issue.