Is there anyway that I can manage the appengine versions and instances through API calls?
What I mean by managing is to start/stop/delete versions deployed to the appengine through API calls.
Is that possible by using gcloud sdk commands from command line ?
Another question , does google provide APIs (or commands) to check the status of running instances ? check if the instance is idle or not and how long its being idle
There is a beta API for managing versions and services here:
https://cloud.google.com/appengine/docs/admin-api/
The API is still beta because it's under active development; there are still a few methods and fields which aren't implemented. Shortly after those are complete, the API will be marked "v1", though v1beta4 and v1beta5 will continue to be supported for several months in transition.
For example, the API doesn't yet include operations on instances, but I expect that List/Get/Delete will be available fairly soon. Since App Engine automatically creates instances for you, there is no create instance API.
I just noticed that the most recent documentation re-skin seems to have hidden the documentation for the REST interface, so I'll drop that link there so you that you can find the currently implemented methods. (Version.Update is also implemented for a few fields, so that documentation update should be coming out very soon.)
2020 UPDATE: You can do it using the apps.services.versions api. You can stop/start a version with the PATCH method, setting the mask to "servingStatus" and in the body set the "servingStatus" field to "STOPPED"/"SERVING".
Similarly, you can use the delete/create methods to launch and remove new versions
Reference:
https://cloud.google.com/appengine/docs/admin-api/reference/rest/v1/apps.services.versions/patch
Related
Will 'confidential' messages/threads automatically be prevented from getting returned in API search results, or are there any code changes we need to make to prevent apps from breaking?
When new features like this get added to Gmail, it would be nice if the API release notes were simultaneously updated with an explanation of how the changes will impact the API. E.g. 2+ years later, there is still no explanation of whether or not gmailified inboxes can be accessed via the API.
Just trying the API to see what gets returned isn't useful, because then it's not clear whether or not you're building on an officially supported feature or just an undocumented implementation that's subject to change without warning.
As of now, there's not much info about changes in Gmail API with the coming of new features like confidential mode. But, you can stay updated with the official Gmail Blog about this.
Is it possible to have multiple user profiles—with separate cookies, history, local storage, etc.—running at the same time in one CEF (Chromium Embedded Framework) instance? The goal is to allow multiple browsing "sessions" side-by-side in one window (it's actually an OpenGL app).
There are two possible solutions I've looked into, each with its own problems:
Using CefCookieManager
This is possible to do for just cookies by creating multiple CefCookieManagers. However, there does not seem to be similar API for history and local storage, which are now still shared.
Using CefSettings::cache_path
CefSettings settings;
CefString(&settings.cache_path).FromASCII("C:\\CefCache");
CefInitialize(args, settings, app, nullptr);
The problem here is that CefSettings is associated with the global CEF instance rather than with each browser/client.
Is there a way to do this that I have not discovered?
If it's only about cookies and local storage, and you host content using custom scheme handler or request interception, then you could use different domains/subdomains for each profile. See this topic for reference: http://www.magpcss.org/ceforum/viewtopic.php?f=6&t=11695 .
Regarding history, you could implement history on your own by using the OnBeforeBrowse callback.
In the topic referenced above it is also mentioned that it's technically possible to specify a different cache path per CefRequestContext (can be provided during browser creation). So working on a patch for CEF may be another option.
EDIT: CEF revision 2040 adds support for complete isolation of storage and permissions per request context, see comment #7 in Issue 1044: https://code.google.com/p/chromiumembedded/issues/detail?id=1044#c7
I am using the warmup service to carry out precaching/etc. The request gets called with self.request.host being prefixed with a version of the app.
All other handler requests are coming with the expected host name for the app.
So if the app name is myapp - then all requests are called with self.request.host set to myapp.appspot.com, whereas for "_ah/warmup" call it is getting set to nnn.myapp.appspot.com.
My code is expecting the self.request.host to be always 'myapp.appspot.com'. Is this by design or am I missing something.
Thanks.
I think this is by design because the warmup service is for a specific version. All other requests are going straight to your main app URL, which is just "aliased" to whatever version happens to be the default version at the time.
By the way, it is documented that you can access all deployed versions of your app by prefixing the version number to the domain name, so you should be aware that any users could access any version if they know about this, and if you haven't taken countermeasures! So you should definitely support this - it's an official feature of App Engine.
I created one google app engine project. There I configured DWR(DirectWebRemoting).
I have created one ajax functionality which will checks the username and password of the user. But it does give me any output rather it gives Error:
dwr is not defined
Source File: http://localhost:8081/dwr.jsp
Line: 16
Where as it works fine in Tomcat web application.
So My question is that does Google app engine not support DWR configuration?
DWR is compatible with GAE according to "Will it play in Java" (broken link. possibly: a list of GAE-compatible java libraries) page.
Several links to threads with proof of success and potential limitations:
thread about "DWR 3 RC1" from "users#dwr.java.net"
StackOverflow question "DWR sometimes die on the GAE server"
Most useful post in "DWR 3 RC1" thread is this one (about potential problems).
Do you require reverse ajax? (Current implementation uses a thread to clean up expired sessions. Current implementation uses javax.swing.event.EventListenerList which is blacklisted by GAE/J.)
Do you require file upload? (Can potentially write to disk)
Do you require file download? (Current implementation uses a thread to clean up expired downloads)
If you don't need anything from the above, then you could replace problematic classes with dummy implementation.
I don't think this is supported, but the same functionality is offered by channels :
https://developers.google.com/appengine/docs/java/channel/
I've looked at http://code.google.com/appengine/docs/java/urlfetch/overview.html
but the code does not show a pooling example,
i mean if i want to fetch www.example.com/1.html, www.example.com/3.html, www.example.com/3.html, ...., www.example.com/1000.html
I'd have to open 1000 connection and close 1000 connections.
I think I could just open 1 connection 'keep-alive', and issue 1000 request and then close it.
that should be faster.
but i have no idea how to do that using url.openStream()
The URLFetch service operates at a higher level of abstraction than individual connections, and the native Python and Java libraries that use it are modified to use this service. As such, you have no direct control over connections - but you can expect that the underlying service will keep connections open when it deems it appropriate.
Unfortunately, as the docs for Java App Engine say, at this time "The Java API for the URL Fetch service only supports synchronous requests". The Python version of App Engine does support async requests, so, if porting to Python is just unthinkable, you may wait in the reasonable hope that such functionality will eventually be in the Java side too. After all, the Python version has been around for a year more, so of course it's more mature, stable, and function-rich.