Since I upgraded my Gradle build to deploy my App Engine application with SDK 1.9.46, I get deployment conflict messages, like the one below.
Beginning interaction for module admin...
0% Created staging directory at: '/var/folders/m8/6z4h4k2x11s3whxrqmd79lym0000gn/T/appcfg2292422843793738444.tmp'
5% Scanning for jsp files.
8% Generated git repository information file.
20% Scanning files on local disk.
25% Scanned 250 files.
28% Scanned 500 files.
31% Scanned 750 files.
33% Scanned 1000 files.
34% Initiating update.
Nov 13, 2016 11:11:41 AM com.google.appengine.tools.admin.AbstractServerConnection send1
WARNING: Error posting to URL: https://appengine.google.com/api/appversion/create?module=admin&app_id=the-outdoor-game&version=dev&
409 Conflict
There is an operation pending for this application: AppLock held for "Updating engine_version_id='dev' within engine_id='default'." acquired by Peter.Fortuin at 2016-11-13 09:15:05.482616 GMT. Please wait and try again or use 'appcfg rollback' to attempt to cleanly abort the current operation.
This is try #0
A rollback if not solving the problem. The only thing that seems to work is downgrading the App Engine SDK to 1.9.44. But that gives me other problems that I don't want to solve.
Anybody has any idea how to solve this? Can it be that this is a bug in the 1.9.46 SDK? Anybody else seeing the same thing?
I have resolved this problem by changing 'service' to 'module' in appengine-web.xml of my module.
See https://github.com/GoogleCloudPlatform/gradle-appengine-plugin/issues/268 for more information.
Related
Today we start recieving this message when trying to deploy.
...
Scanned 8750 files.
Scanned 9000 files.
Scanned 9250 files.
Scanned 9500 files.
Scanned 9750 files.
Initiating update.
Cloning 711 static files.
Cloning 9233 application files.
Cloned 2000 files.
Cloned 4000 files.
Cloned 6000 files.
Cloned 8000 files.
Deploying:
Uploading 0 files.
Initializing precompilation...
Deploying new version.
Rolling back the update.
com.google.appengine.tools.admin.HttpIoException: Error posting to URL: https://appengine.google.com/api/appversion/deploy?app_id=facturanube&version=1&
500 Internal Server Error
<h3>Server Error</h3><p>A server error has occurred.</p>
Debugging information may be found in C:\Users\usuario\AppData\Local\Temp\appengine-deploy6314649189927600314.log
Debugging information file contents:
Unable to update:
com.google.appengine.tools.admin.HttpIoException: Error posting to URL: https://appengine.google.com/api/appversion/deploy?app_id=si-nube&version=1&
500 Internal Server Error
<h3>Server Error</h3><p>A server error has occurred.</p>
at com.google.appengine.tools.admin.AbstractServerConnection.send1(AbstractServerConnection.java:303)
at com.google.appengine.tools.admin.AbstractServerConnection.send(AbstractServerConnection.java:254)
at com.google.appengine.tools.admin.AbstractServerConnection.post(AbstractServerConnection.java:233)
at com.google.appengine.tools.admin.LoggingClientDeploySender.send(LoggingClientDeploySender.java:47)
at com.google.appengine.tools.admin.AppVersionUpload.send(AppVersionUpload.java:1100)
at com.google.appengine.tools.admin.AppVersionUpload.deploy(AppVersionUpload.java:949)
at com.google.appengine.tools.admin.AppVersionUpload.commit(AppVersionUpload.java:850)
at com.google.appengine.tools.admin.AppVersionUpload.uploadFilesTransaction(AppVersionUpload.java:176)
at com.google.appengine.tools.admin.AppVersionUpload.doUpload(AppVersionUpload.java:151)
at com.google.appengine.tools.admin.AppAdminImpl.doUpdate(AppAdminImpl.java:474)
at com.google.appengine.tools.admin.AppAdminImpl.update(AppAdminImpl.java:55)
at com.google.appengine.eclipse.core.proxy.AppEngineBridgeImpl.deploy(AppEngineBridgeImpl.java:400)
at com.google.appengine.eclipse.core.deploy.DeployProjectJob.runInWorkspace(DeployProjectJob.java:148)
at org.eclipse.core.internal.resources.InternalWorkspaceJob.run(InternalWorkspaceJob.java:38)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)
Important considerations:
The appengine-web.xml file has no errors.
We tried deploying in different versions with no success.
The application can be deployed in another appengine application, but not in our production application.
We have no cuota-related problems. Our payments have no
problems.
Our current versions:
GWT SDK 2.4.0
App Engine 1.9.54
Java 7
Update
I was able to deploy today (2018/03/18) with no changes to code or configuration files. I guess Google did something to solve the issue.
500 A server error has occurred on deployment is usually related to malformed configs, including app.yaml and cron.yaml (and Java equivalents). Or if unsupported stanzas are included. Please check your GAE app configs and attempt to strip them down to the essentials just to narrow down which stanzas/flags are messing up the deployment.
I have a basic appengine project with multiple modules and a dispatch.yaml:
my-project/boxes/app.yaml (default module)
my-project/users/app.yaml (users module)
my-project/dispatch.yaml
I'm trying to configure a single hourly cronjob with the following definition:
cron:
- description: hourly box purging
url: /api/boxes.purge
schedule: every 1 hours
target: default
I've tried adding it to the module it concerns, so put the above definition in file: 'my-project/boxes/cron.yaml' and running appcfg.py cron_info boxes/. My terminal seems to indicate all went well:
hourly box purging:
URL: /api/boxes.purge
Schedule: every 1 hours (UTC)
2015-04-30 10:08:00Z, 0:59:55 from now
2015-04-30 11:08:00Z, 1:59:55 from now
2015-04-30 12:08:00Z, 2:59:55 from now
2015-04-30 13:08:00Z, 3:59:55 from now
2015-04-30 14:08:00Z, 4:59:55 from now
Ye the Appengine Developer console fails to reflect this and cron jobs are not run. It does show on the local development panel.
Putting the definition in the root of the projects (besides dispatch.yaml) yields the same results. Other things i've tried (in vain): Redeploying all code, appcfg.py update_dispatch, waiting a while before refreshing the developer console.
Hopefull someone is able to help me find the obvious mistake, or confirm that their is some bug.
In the Configuration section of the doc it's stated:
Optional application-level configuration files (dispatch.yaml,
cron.yaml, index.yaml, and queue.yaml) are included in the top level
app directory.
I agree, the paragraph context appears to leave room for interpretation (typically...). But the quoted text also indicates that these files are considered app-level configs. So I'd keep them at the top.
About the update: I noticed, for example, that the index.yaml file was NOT uploaded with the rest of the multi-module app at my first deployment, I had to explicitly use appcfg.py update_indexes. This was not happening with a single module app. Maybe appcfg.py update_cron also needs to be explicit?
Currently the GAE Managed VMs feature is broken for any project with a name longer than 27 characters.
The underlying issue is that Docker restricts image namespace to between 4-30 chars. This has been fixed (https://github.com/docker/docker/issues/10392) but is still awaiting a release at time of writing.
It seems when deploying a Managed VM to GAE that the namespace is automatically generated from your project name plus _m_ prefix. This leads to error when attempting to deploy the vm:
DEBUG: "POST /v1.10/images/gcr.io/_m_<my project name>/<my project name>.default.20150330t140211/push HTTP/1.1" 500 111
INFO: Exception 500 Server Error: Internal Server Error ("Invalid namespace name (_m_<my project name>). Cannot be fewer than 4 or more than 30 characters.") thrown in ProgressHandler. Retrying.
The obvious solution would be for GAE gcloud tools to respect the underlying limit via some auto-truncation or hashing scheme.
Does anyone know a way around this? Or I have to wait for Google to fix or Docker to release a new version and Google to update?
We're aware of the issue and we're working on a long-term fix. For now, you can switch to an old version of gcloud. You can do this by setting this variable to point to an old version (0.9.51):
gcloud config set --scope=installation component_manager/fixed_sdk_version 0.9.51
then run "gcloud components update"
Then run "gcloud config set app/hosted_registry false"
and you should be able to deploy. I'll update this answer when we've fixed the naming issue.
UPDATE:
The naming issue has been fixed as of this week's release (0.9.57).
my python27 app deployment is failing for some reasons:
2012-03-09 16:46:25 Running command: "['C:\\Python27\\pythonw.exe', '-u', 'C:\\Program Files (x86)\\Google\\google_appengine\\appcfg.py', '--no_cookies', u'--email=malartre#scolab.com', '--passin', 'update', 'C:\\Users\\XXXXXXXXXXXXXX\\GoogleAppEngine\\XXXXXXXXXXXXXX']"
Application: XXXXXXXXXXXXXX; version: 1
Host: appengine.google.com
Starting update of app: XXXXXXXXXXXXXXX, version: 1
Getting current resource limits.
Password for malartre#scolab.com: Scanning files on local disk.
Scanned 500 files.
Scanned 1000 files.
Scanned 1500 files.
Scanned 2000 files.
Scanned 2500 files.
Cloning 2973 static files.
Cloned 100 files.
Cloned 200 files.
Cloned 300 files.
Cloned 400 files.
Cloned 500 files.
Cloned 600 files.
Cloned 700 files.
Cloned 800 files.
Cloned 900 files.
Cloned 1000 files.
Cloned 1100 files.
Cloned 1200 files.
Cloned 1300 files.
Cloned 1400 files.
Cloned 1500 files.
Cloned 1600 files.
Cloned 1700 files.
Cloned 1800 files.
Cloned 1900 files.
Cloned 2000 files.
Cloned 2100 files.
Cloned 2200 files.
Cloned 2300 files.
Cloned 2400 files.
Cloned 2500 files.
Cloned 2600 files.
Cloned 2700 files.
Cloned 2800 files.
Cloned 2900 files.
Cloning 3 application files.
Uploading 4 files and blobs.
Uploaded 4 files and blobs
Compilation starting.
Compilation completed.
Starting deployment.
Rolling back the update.
Error 400: --- begin server output ---
Client Error (400)
The request is invalid for an unspecified reason.
--- end server output ---
2012-03-09 16:47:14 (Process exited with code 1)
You can close this window now.
How can I debug that?
Thanks,
Carl
Just recording my experience in this related question.
I got a 'Client Error 400/unspecified reason' because my app.yaml error handlers were pointing to files in a static directory.
I moved the error files to a separate directory and updated app.yaml paths.
Update worked properly.
i know this is an old question, but i thought i would provide the solution that worked for me. Select Control from the GAE Launcher, then Clear Deployment Credential. Deploy again. The deployment script will open a web page where GAE is requesting access to use your Google account to authenticate. the answer from Jen Tong helped me get to my solution.
This is a fall-back error message that is triggered when your deployment sends very unexpected data to App Engine during deployment.
In other words, there's no quick fix here, but there are a couple things you can check:
Check your apps metadata in app.yaml for Python and appengine-web.xml for Java. Double check each field. If the application name is very wrong, it may trigger this error.
Make sure that your deployment credentials are valid. If you're authenticating with OAuth 2.0, try using password based authentication.
Deleting some files worked for me. Looks like there may be a 1000 file hard limit for apps on GAE, and this obscure error code is at least in part used to document being over the limit.
http://www.adampresley.com/2011/06/gae-and-client-error-400.html
I has this because I had an rogue ) in my app.yaml. I'd check the last thing(s) you did for errors because although your app may upload, an error may cause the application not to deploy.
One of the causes of this error is having more than 1000 files in a folder.
For me I had about 1k images but then 9 folders and I think that put it over the top. I haven't checked if the limitation also exists for folder counts but I imagine it does.
I work on a folder and tomcat recognizes the folder. But, when I shutdown and restart tomcat it is taking time to recognize the same folder. Can anybody tell me why?
I see the error report in catalina.out. It gives a list of errors but finally says
Nov 22, 2009 2:08:58 PM org.apache.catalina.startup.Catalina start
INFO: Server startup in 1403 ms
I pressume 'folder' is your webapp. I takes time starting your wabapp, because tomcat has to load.parse configuration files for that app. Additionaly if your webapp contains JSP pages those get most likely recompiled on the restart.
I guess you are referring to application deployment time. The most time consuming process is to scan the jars for TLDs. If you don't use JSP tags, you can speed up the deployment time by adding this to your context,
<Context processTlds="false" ... />