Posted on

App Engine Downtime Notices

App Engine downtime and maintenance notices are posted to the Google Group google-appengine-downtime-notify, located at https://groups.google.com/forum/#!forum/google-appengine-downtime-notify . It’s a good idea to monitor this list for any issues with the App Engine platform.

It’s especially important to subscribe to these notices if your application is still on the M/S datastore. The M/S datastore is occasionally moved into a read-only state for maintenance, and these maintenance periods are announced over the downtime list.

Subscribing to the google-appengine-downtime-notify list is easy: go to the above linked address and click on the button marked Join Group. As you can see from the below pictures, this list is extremely low-traffic (less than 1 email a day).

Posted on

App Engine System Status

The App Engine system status console is located at https://code.google.com/status/appengine . It’s a good idea to keep this page bookmarked to monitor GAE’s performance.

Here’s how the status page looks like when everything is running well:

Here’s an example of how performance issues are reported:

Posted on

100% Logs Stored Data On Free Tier Applications

Some heavily-trafficked free tier applications may find themselves with a full Logs quota bar, similar to the below screen:

For free tier applications, App Engine will retain 1 GB of logs over the last 90 days. This quota doesn’t reset on a daily basis like other quotas do; instead, it shows how much logging data has been retained over the last 90 days. In this example screenshot the demonstration application has 1 GB of logging data stored, so the logs quota shows a full red bar.

App Engine will pop up a billing notice whenever there is a full quota bar (as in the above screen) and it’s a good idea to enable billing if you need to retain more logs for a longer period of time. However, if you’re only interested in the recent logs, you don’t need to enable billing. App Engine implements logs as a FIFO queue: new logs are added in, and old logs are deleted out.

In short: if your application’s logs quota is full, you only need to enable billing to retain the older logs. The logs for fresh/recent requests will always be available.

Posted on

AccessControlException Resulting From RuntimePermission: modifyThreadGroup

While using certain libraries on App Engine, you may encounter the following exception notice:

javax.servlet.ServletContext log: 
    Exception while dispatching incoming RPC call
threw an unexpected exception: 
    java.security.AccessControlException: 
    access denied (java.lang.RuntimePermission modifyThreadGroup)

If you see this exception message, your application or (more frequently the case) a library is attempting to create a new thread. App Engine doesn’t allow frontend instances to spawn threads, so any attempt to start up a thread will result in AccessControlExceptions.

However, App Engine does allow backend threads: threads which run within backend instances. If your application absolutely needs to run threads, run the threading component within a backend or a backend module.

Posted on

DatastoreFailureException: Internal Error Exception Messages

On rare occasions, an application may spawn errors similar to the below:

com.google.appengine.api.datastore.DatastoreFailureException: 
    internal error.
at com.google.appengine.api.datastore.DatastoreApiHelper.translateError     (DatastoreApiHelper.java:50)
at com.google.appengine.api.datastore.DatastoreApiHelper$1.convertException     (DatastoreApiHelper.java:70)

As the exception message suggests, this log indicates that the datastore encountered an internal error while handling the datastore operation. Unfortunately, there’s nothing that a developer can do to fix this error since it’s an internal App Engine issue.

Generally this type of exception fixes itself sooner or later; if it persists, file an issue at the App Engine bug tracker: https://code.google.com/p/googleappengine/issues/entry?template=Production%20issue

Posted on

Datastore Query Cursor: ExQ

While using JDO or another datastore helper library, applications may encounter a value of ExQ when requesting a query cursor. This value means that there are no more results (entities) to display for that query, and consequently that there are no more query pages to return.

All applications using query cursors should check for an invalid or end of query results marker, and handle this in an application-specific way. A query cursor string that is null or empty (zero length) generally denotes the end of query results. The cursor value ExQ can be handled in the same way.

A word of warning: some third-party datastore helper libraries spawn an exception or error condition when applications attempt to access invalid cursors, or attempt to request a cursor when end of results has already been reached. When using these libraries, it’s important to fully read the documentation and understand how these libraries interact with the App Engine datastore.

Posted on

Transitioning To 1.8.8

A few days ago, App Engine finished transitioning to the 1.8.8 runtime. Here’s a screenshot of an application in the middle of the transition (note that one instance is running 1.8.7, while the other is running 1.8.8):

My favorite part of this patch is the new ability to edit PHP strings in memcache:

Posted on

Logging In PHP

A quick note: here’s how to write a line of text into logging on the PHP runtime:

syslog(LOG_INFO, "Log Text: " . $variable_to_log);

The first argument can be replaced with standard PHP logging levels, such as LOG_WARNING.

A reminder: App Engine ignores calls to openlog() and closelog() . While you can still call these functions (for instance if you have legacy code), they will not affect logging.

Posted on

Counting Entities In The App Engine Datastore.

In SQL, the COUNT statement is available for counting the number of rows returned by a SELECT query. Here’s an example:

SELECT COUNT(*) FROM foods WHERE name="apple";

Unfortunately, the App Engine datastore offers no equivalent to the COUNT statement. To count the number of entities, an application has two options:

  1. Count the entities in a separate counter as they’re added to the datastore. For superior performance, the counter can be sharded and temporarily stored in memcache.
  2. Query for entities and count the number of entities returned. To help speed up this query, a keys-only request can be configured. However, this option can be slow and expensive.
Posted on

Mapping Servlets To App Engine XMPP Requests

Here’s an example of how to configure servlets to accept XMPP requests. The XML below should be added to the web.xml file in the /war/WEB-INF directory.

This XML snippet configures three servlets: ChatServlet (handles inbound XMPP chat messages), PresenceServlet (handles requests for the application’s presence information, and presence info for other clients) and SubscribeServlet (when other XMPP users grant the application access to their presence information).

<!-- Handles the chat part of XMPP. -->
<servlet>
    <servlet-name>Chat</servlet-name>
    <servlet-class>com.example.xmpp.ChatServlet</servlet-class>
</servlet>
<servlet-mapping>
    <servlet-name>Chat</servlet-name>
    <url-pattern>/_ah/xmpp/message/chat/</url-pattern>
</servlet-mapping>
<!-- Handles the presence part of XMPP. -->
<servlet>
    <servlet-name>Presence</servlet-name>
    <servlet-class>com.example.xmpp.PresenceServlet</servlet-class>
</servlet>
<servlet-mapping>
    <servlet-name>Presence</servlet-name>
    <url-pattern>/_ah/xmpp/presence/*</url-pattern>
</servlet-mapping>  
<!-- Handles the subscription part of XMPP. -->
<servlet>
    <servlet-name>Subscribe</servlet-name>
    <servlet-class>com.example.xmpp.SubscribeServlet</servlet-class>
</servlet>
<servlet-mapping>
    <servlet-name>Subscribe</servlet-name>
    <url-pattern>/_ah/xmpp/subscription/*</url-pattern>
</servlet-mapping>