I’ve just watched a video from Google IO where Martin Fowler and Rebecca Parsons went through some of the aspects that involves the development of an application for the cloud - focusing on the JVM.
In terms of the Google App Engine, you don’t have access to a relational database, thing I found out when I first tried it. Instead you get a Big Table.
Martin put out a good analogy and you can just think of it as a nested hash map. It’s certainly a shift on how we think these days, but layers of abstraction like google’s DataStore and the Java Persistence API will help in the transition.
Another interesting bit about the presentation was on how concurrency works on GAE.
Essentially, in an standard Java application you have a single memory space where you have at least one running thread. You can create threads on the fly, which will share the same memory space, thus making it easy to share data.
On the app engine, things work differently. What you have are separate memory spaces with a single thread on each one. Any attempt to create a new thread will result in an exception. The solution for sharing information in this case? Use the nested hash map (big table).
Now, whereas you might not be worried about this since your application doesn’t span any threads, as well pointed by Martin Fowler, it’s the code you don’t see that you need to be careful with. Any Java application uses a number of 3rd party libraries that might span out threads of their own, which will result in your application blowing up.
That rang a bell. Again, back when I was trying the app engine, one of the configuration bits shared by Ola Bini looked like this:
config.webxml.jruby.min.runtimes = 1 config.webxml.jruby.max.runtimes = 1 config.webxml.jruby.init.serial = true
I think the properties are pretty much self-explanatory but I didn’t quite understand the reason for setting it back then.
If you happen to have bigger values for the number of runtimes you want, you need to set the serial property to true, otherwise JRuby will span several threads to create the runtimes.
This is a really good example of things that might fail whether you’re migrating or developing a new app to deploy on the App Engine. Luckily for us, JRuby has a smart and neat way to handle this - the configuration I’ve just shown, but most of the libraries out there that might rely on threads are not prepared.
Martin and Rebecca’s opinion on this is that new releases of these same libraries will start to take it into account, since a bigger adoption of the Cloud seem to be on the way.
Make sure you watch the video. I certainly left a lot of interesting stuff out.
I find it extremely unlikely that there is just one thread per JVM. Just because you can’t create threads doesn’t mean you’re don’t run in a worker thread of the servlet container as it’s standard in JEE.
Hello unnamed user
Note that I didn’t say one thread per JVM. I said that each thread has it’s own memory space, which makes things work differently as I described.
Each request to your app is handled by a different web server, to allow google to scale it easily. And multiple requests from the same user might be going to complete distinct servers.
Part of the reason for which your app cannot spawn thread is that the request should be able to complete within a few seconds at most. long running thread will be killed.
You can also refer to this to check the restrictions imposed by the Google App Engine.
Cheers
Each process having it’s own memory space is certainly not the case. That would mean they are processes. That would break almost everything of JEE starting with static variables which clearly work.
What is the case is that GAE doesn’t support sticky sessions. But that’s a holly different issue.
I might be misunderstanding something here but aren’t sticky sessions a way to improve session replication?
Anyway, what happens on GAE is that your application is just not allowed to create threads as stated in the link I mentioned in my last reply, and that’s what I highlighted in the post,since you might be using libraries that are likely not to be ready for such an environment.
I never questioned that you’re not allowed to create threads in GAE. I question that in GAE each thread has it’s own address space. If that was true everything of JEE would fall apart. You couldn’t have context listeners, you couldn’t have servlets or filters, you couldn’t have a servlet context, you name it. And you would violate the Java language spec. I highly doubt this is the case.
I further question that not being able to create threads breaks a whole lot of libraries. In my experience it has broken none. What however breaks many libraries is that GAE doesn’t allow access to certain standard Java packages like stax, jaxb and jndi. BTW not being able to create threads is in line with Java Exterprise tier restrictions [1].
Sticky sessions are a way to associate an http session with a JVM resulting in all requests of that session to hit the same JVM. If you don’t have this each request can hit a different JVM which is exactly the semantics of GAE. This means that GAE has to replicate all sessions (put them in the data store) which hurts performance.
[1] http://java.sun.com/blueprints/qanda/ejb_tier/restrictions.html
Hi again!
Tks for the interesting discussion. I haven’t had any experiences with breaking libraries either, it’s just something to consider.
And regarding the restriction, they seem to be specific to EJB’s… which is a whole different story I guess. It’s common to have Web Java apps that make no use of EJB’s, using Spring or something similar instead.
Do these restriction apply in such environment?
Spring is just a way to wire your java objects together. That is orthogonal to using EJBs.
If you use Spring to configure Java Web applications a lot of the restrictions make sense. For example you wouldn’t want an application to create widgets, shut down the VM, work around access restrictions, access “forbidden” classes (com.sun, …) and so forth.