Google AppEngine

I made some code public that does what you describe: it is a simple   cache interface that has implementations for in-memory, memcache and   the datastore.  You get about 100MB of heap space to use which can   significantly speed up your caching. There is also a CompositeCache class that allows you to layer the   caches so that it first checks in-memory, then memcache , then the   datastore.  Puts go to all levels and cache hits refresh the higher   levels.  e.g. if an item is not in-memory and has been flushed from   memcache but is still present in the datastore then the other two will   be updated.

Well, in AppEngine your primary key is the key for the object(Entity) and it can either be a generated ID or a unique string your application provides.  "Google App Engine" by Dan Sanderson has a lot of examples on this.  If you don't use a key_name property, then when you save with a put(), an ID is generated, but if you pass in key_name='thisIsMyKey' into the constructor, then you manually set the key for the object.  You can use the method, id_or_name() to return either the object's key name or its ID, which ever one it has and has_id_or_name() would return a boolean about it, and if it's not saved and your not using key_name, then the ID would not exists yet.  Also you can get the Entity(Object) from the datastore by using the get(k) method where k is a key object and the key object has two parts: kind and ID or key_name.  Additionally you can fetch an object from the datastore with get_by_id() and get_by_key_name()

Right now, when the user removes the GWT/App Engine nature from the project, if they have a SDK container on their build path, it is collapsed into its individual jars, and they are added to the classpath. In some cases, users do not expect this behavior (for example, if they mistakingly added the wrong nature).

There's a 30 second deadline for web requests, and a 10 second deadline for URLFetch requests. You'll want to make sure you aren't exceeding either of these.

Cold-start latency is determined by the time it takes to load all the classes needed to handle the request. If you upload a JAR file, but nothing references it, it won't be loaded, and thus won't affect your cold-start latency.

Only those jars under WEB-INF/lib will be uploaded to GAE. You can prevent GWT jars from being uploaded by not placing them under WEB-INF/lib, rather by externally linking to them in your project build path.

You must have two things in consideration: the appid and version must match, and you should enable datastore writes.

Once you've enabled OpenID authentication for your app, a few things change: URLs generated by create_login_url without a federated_identity parameter specified will redirect to the OpenID login page for Google Accounts. URLs that are protected by "login: required" in app.yaml or web.xml will result in a redirect to the path "/_ah/login_required", with a "continue" parameter of the page originally fetched. This allows you to provide your own openid login page. URLs generated by create_login_url with a federated_identity provider will redirect to the specified provider.

many users, when asked for their "openid URL" will simply look at you in puzzlement. What we need is a solution that avoids the need for most users to enter their URL themselves, while still allowing savvy users to do just that. Fortunately, there are a number of such solutions. One of them is clickpass. After signing in there and setting up an entry for your site, they'll provide you with code for a button that you can embed in your login page, and which allows users to choose from a number of well-known identity providers, including Hotmail, Yahoo!, Google, and Facebook, as well as entering their own URL.

Originally my application started out using Spring MVC and JDO. The first use of JDO took my application about 5 seconds to get everything set up.  Similarily, Spring MVC added around 6 seconds to the cold start  time

 If you are not using either JDO or JPA, you can safely delete all related libraries (ones that have JDO, JPA, or Datanucleus in their name) and use the command line tool to upload your app. Deleting these libraries shaves about 400ms off of cold start time.

this tip can cut a few hundred milliseconds or more off of your cold start time. Using JSPs slows you down in two ways: If you have a file with a .jsp extension, anywhere in your website directory, appcfg will detect that you use JSP, and it will add 8 libraries that are used for processing JSPs into your lib directory before uploading to the app engine.  These libraries total two megabytes in size, and simply having them in your lib directory slows your cold starts down by a few hundred milliseconds. If you are interested in what libraries these are, you can see them in the temporary folder appcfg creates while uploading your app. The first JSP file accessed after a cold start, even an empty one, will take a few hundred additional milliseconds to be processed.  I'm not sure what causes this, maybe it has to do with initializing the JSP processor.

build-time substitution. Here’s our appengine-web.xml: <?xml version="1.0" encoding="utf-8"?> <appengine-web-app xmlns="http://appengine.google.com/ns/1.0"> <application>${gae.app.name}</application> <version>${friendlyversion}</version> <system-properties> <property name="java.util.logging.config.file" value="WEB-INF/logging.properties"/> </system-properties> </appengine-web-app>

At build time, I use the AntRun plugin (lines 97-118) to create a small file under the target directory that holds a ‘sanitized’ version of the standard Maven version. (I.e. “1.0-SNAPSHOT” becomes GAE-friendly “1-0-snapshot”.) I then use the Maven filter functionality available in the WAR plugin (lines 80-96) to copy the appengine-web.xml into its proper directory with the version substituted in.

disabling session id in code will not stop the cookie from saving session id. When you enable session in app engine xml file than you are telling the framework that you don't want to save sessions in cookies (client side), instead you want to save them on server i.e. using _ah_session. Cookies JSession id is default behavior of Java session mgmt. And it is nothing to do with APP engine framework.*

You don't have to add each class individually to the black list. They are all regex patterns, so just do this: <extend-configuration-property name="rpc.blacklist" value="com.google.gwt.user.client.ui.*Collection"/> In my case I wanted even finer grained control over which collections get included, so I did this: <extend-configuration-property name="rpc.blacklist" value="-.*List"/> <extend-configuration-property name="rpc.blacklist" value="-.*Map"/> <extend-configuration-property name="rpc.blacklist" value="-.*Collection"/> <extend-configuration-property name="rpc.blacklist" value="+java.util.HashMap"/> <extend-configuration-property name="rpc.blacklist" value="+java.util.LinkedHashMap"/> <extend-configuration-property name="rpc.blacklist" value="+java.util.ArrayList"/>

This tutorial concerns using Google Accounts to maintain the existence of your users in a Google App Engine application. Google App Engine provides the class UserServiceFactory to facilitate that. UserServiceFactory is then used to generate UserService object, which in turn provides the following features createLoginURL createLogoutURL getCurrentUser isUserAdmin isUserLoggedIn You would use UserService object to generate the login URL for the browser. The browser would be directed/redirected to this URL. On reaching this URL, the Google log-in prompt would be displayed by Google's server.

public class DatastoreUploadAction extends AppEngineUploadAction {         @Override         public String executeAction(HttpServletRequest request, List<FileItem> sessionFiles) throws UploadActionException {                 String out = super.executeAction(request, sessionFiles);                 for(FileItem imgItem : sessionFiles) {                         PersistenceManager pm = ContentServiceImpl.getPersistenceManager();                         Transaction tx = pm.currentTransaction();                         try {                             // Start the transaction                             tx.begin();                             InputStream imgStream = imgItem.getInputStream();                                 Blob blob = new Blob(IOUtils.toByteArray(imgStream));                                 ImageBlob imageBlob = new ImageBlob(imgItem.getName(), blob);                             pm.makePersistent(imageBlob);                             // Commit the transaction, flushing the object to the datastore                             tx.commit();                         }                         catch(Exception e) {                                 e.printStackTrace();                         }                         finally {                             if(tx.isActive()) {                                 tx.rollback();                             }                             pm.close();                         }                 }             return out;         } }

to write a string to a twitter account. Here’s my original java code:

About loading request/performance, there're lots of discussions that you can find in the groups, please just try google it. Here are some notes based on reading those. Latency causes by 1- time to start new JVM 2- time to load your application To reduce load time by 1) others star request to a) pay to reserve JVM b) request Google to load your app before start dispatch request to that instance c) accept the situation For 2) we try to a- try to use/replace frameworks with light-weight ones: datastore access framework, MVC framework,... b- try to limit calculation in your index page to alleviate the impact of loading request c- design your object model based on your need, so that you do calculation at insert time, not at query time. For example, in my app, if I want to report on year and quarter, then I have 5 summary "record" for those, instead of querying and computing those d- caching result. For example, If I know 1 one 5 piece of data above would be read frequently, then I will read those 5 all, and put into memcache for later use ... So it's application-specific, I don't know if each of above can help you. But only you who can know if which one of your code can be cached and how...

Personally, I would recommend using the blobstore API for this since it is officially supported by google and means it won't break in the future. It also has nice bindings into the imageservice. http://code.google.com/appengine/docs/java/blobstore/overview.html

The Blobstore API provides two types of functions:   An ability to upload and save the blob automaticallyThe BlobstoreService which is provided by the com.google.appengine.api.blobstore.BlobstoreService allows us to specify a URL where users can upload their large files. You can think of this url as the action element in the HTML form. The implementation at this URL is internal to the BlobstoreService. But what it does is significant. It will extract out the file contents that you uploaded and store it as a Blob in the database. Each blob that is stored in the database is associated with the a Blob Key. This Blob key is then provided to your url and you can then use the Blob Key to do anything within your application. In our case, we form a url that is tweeted to the users who can then view the picture that we uploaded. An ability to serve or retrieve the blob.The BlobstoreService also provides an ability to serve or retrieve the blob that was saved successfully. It will provide the blob as a response that could then use as a source in an <img> element for example. All you need to do is provide it the Blob Key and the response stream and in return, it will provide the content properly encoded as per its type that you could then use.

This article studies the proxy technique first and then turns to the Google AJAX Feed API method, giving you a chance to intermix Java™and JavaScript coding.

You need a service that, when given a feed URL, connects to that site, downloads its contents, and sends them back to the caller. (For a shell-line parallel, consider the wget or curl command.) You can do this many ways, and Listing 2 shows a simple way to accomplish the task. Because I decided to call my remote proxy RemoteProxy, the server-side class had to be called RemoteProxyImpl; Impl stands for "Implementation."

The SOP won't let your code get data from another site, but there's an exception: You can download and execute JavaScript code using the <script ... /> tag. If the code you download happens to include data and calls a function of yours that puts the data to good use, then you have managed to bypass the SOP. Here's the idea behind the Google AJAX Feed API: It uses the <script ... /> tag to call a Google site that works as a proxy. The remote site gets the feed data and returns it in the form of JavaScript code. The downloaded JavaScript code calls your function so you can process the incoming XML

Just so you know, because it isn't documented, you can choose the tag name of the root element with UiBinder (the HTMLPanel(String,String) constructor), just use a tag="" attribute, e.g. <g:HTMLPanel>This will use a div element</g:HTMLPanel> <g:HTMLPanel tag='p'>While this will use a p element</g:HTMLPanel> You can then use an HTMLPanel as the root of your UiBinder and build your widget as a Composite, passing the HTMLPanel built by UiBinder to the initWidget method.