An easy way to skip the redundant part in this scenario is add -o at the end of your command.

E.G: mvn install -o

It simply means I don’t have internet now, don’t bother to connect any outside source, just do your real stuff.

The first one to mention about is running Maven unit test against a single class. Most of the time, the test failures are only happening for a small sets of classes, and when you try to fix them after and would like to test again, you don’t want to run all those tests again which may be time-consuming in some extreme cases.

Luckily, Maven provides a simple way to specify classes that you would like to test against:

mvn test -Dtest=TestClassName.

In the case of multiple classes are needed, you can append the class name at the end of the TestClassName with a coma as delimiter.

Some highlighted points here which I have learned from the research:

1) For static files, the cache is being set in the appengine-web.xml file, you can specify how long it is going to expire within the file.
The cache here is if you don’t declare your static file here, then quite possibly you will not be able to render your static file well. Google use a different source to serve static files, as a result you have to explicitly tells AppEngine that “these are the types of static files I am using, and you need to serve it”. An alternative is to add those static files into your web.xml as a servlet or a filter, which will then be caught by the servlet/filter chain, however, this is not the recommended way to go.

2) You can use a filter to add “cache-control” header to static files request/response, but Google will not honor it. To be precisely, Google will always return a private cache-control for your static files regardless what kind of setting you provided. Hence these static files will only available in your private cache pool (local browser), and will expire after your specified length.

3) However, we can use above mentioned method to add “cache-control” header to dynamic generated pages, such as jsp file. This is particularly useful for files that rarely change, such as front-page or some introduction pages. And this time, Google will honor your setting in your cache-control header with the right expire time.

4) The way current browser working is a little bit weird but understandable:
If you click a link on a page, then browser will always first check if there is a local cache available, if not then goes to the server to fetch.
If you press F5/Refresh the page, the the browser will just ignore your local browser cache at all, but goes directly to the server. This time, it will use the “is-modified-since” header to compare whether the content on the server side is still valid, if it is, then a 304 will return and you will still use your local cache, otherwise a new version will be retrieved.

In short, if you click the link, then it is possible that client will not talk to the server at all, but if you refresh, then the client will always talk to the server.

5) Both Chrome and Firefox have good tools for debugging HTTP Request, see how the cache is working and diagnose each of the specific request.

After struggling with it more than one day, I eventually found out the culprit of this failure is because of the file extension.

The rule is: you can not make the file extension in CAPITAL/UPPERCASE/BIG case, otherwise CloudFront won’t recognize those files thus failed to streaming it.

So, if you want to play with CloudFront streaming, make sure that your file is not xxx.FLV or xxx.MP4, but please name it xxx.flv or xxx.mp4.

Basically, what you need to do is modify the memory configurations in the file:

{IDEA_HOME}/bin/idea.vmoptions

Change the the value to the size you wish to have. In my case, I update the -Xmx to 1536M and -XX:MaxPermSize=500M, which speed up the process and responsiveness of Idea quite a bit.

Anyway, to clean the session in the AppEngine database is a basic requirement for any real product running on it. If you don’t clean it, unless you are not using session anywhere, there is definitely one day your datastore will blow out.

Once you have a session hanging around, you will easily detect them under the Datastore Viewer. It is actually a table called _ah_session. (Yep, whenever you see _ah, it means Google is playing some magic background stuff). It will list all current sessions in the app and its expire date as well as the size of it (well, actually it’s the value, but most of the time, the value is not easy to be displaying there)

Apparently, the most direct way and easiest way is using your hand, tick all those boxes before the sessions, and click the DELETE button, and then yep, all sessions just cleared. Easy right, what if you have 100 sessions? Some one may argue that, you can append &limit=SOME_MAGIC_MAXIMUM_NUMBER_TO_BE_DISPLAYED at the end of the link in the browser, refresh the page, and then clear them all at once. But as far as I know, the maximum number you can set is 200, which means if there are 1000 entries, then you have to go through all 5 pages.

This manual process sounds boring and lack of the self satisfactory as a software developer, don’t you think? As a programmer, we always look down those guys who has to use mouse and keyboard instead of using their mind to delete stuff. All right, so Google does provides a way to clean the session, it is a servlet, part of the Google Code infrastructure (Being aware of Google’s BigTable). Basically what you need to do is declare the servlet: SessionCleanupServlet in your web.xml, and get a cron job to call it periodically based on your traffic.

This article explains well how to integrate the servlet and cron job into your app to delete the sessions. But you should be aware that each of the servlet run can only remove 100 sessions at most, that means if you have a huge traffic and huge sessions, you have to set the servlet/cron job runs more frequently but also make sure you won’t interrupt any current user’s activities.

OK, it seems all working well except some bugs may happen. One of the issues we have detect is that we have some very very very old sessions being around, maybe one year (Before we include the clean session mechanism), and obviously no matter how many times of the session being cleaned by the servlet, those sessions will always survive from all bullets. While, we have no explaination about it and they are always so trivial to be neglect until a 500 error comes up when a new version being released.

One bug we recently have is after we change one of the property in a class type from String to Date, and accordingly some of the related methods are being updated as well. But those ghost sessions still have String in their hearts, and when app initialized, everything just crashed because of this catch. Consequently, we are thinking about maybe it is worthwhile to clean the cache whenever a new version being released, and this cannot being relied on the servlet provided by Google, but rather our own code to delete all of them. This thread elegantly handles above problem by deleting all sessions and caches using a customized code, and you can now have a clean environment whenever you want.

So once you have integrated above two points into your projects, you should no longer worry about any session issues, and hopefully Google will someday bring us a better built-in solution to handle all this issues. For now, let’s just work harder.

The fix for using standard upload is simple that add the provided parameter to the end of the command is fine.

For maven part, what you need to modify is your pom.xml:

<plugin>
<groupId>net.kindleit</groupId>
<artifactId>maven-gae-plugin</artifactId>
<version>${maven.gae.plugin.version}</version>
<configuration>
<splitJars>true</splitJars>
</configuration>
<dependencies>
<dependency>
<groupId>net.kindleit</groupId>
<artifactId>gae-runtime</artifactId>
<version>${gae.version}</version>
<type>pom</type>
</dependency>
</dependencies>
</plugin>

The one with the red color is the thing that you need to add, are maven plugin will use the split jar pattern to upload the application.