What are the pros of enabling Concurrent Requests over the current scaling algorithm GAE uses?? Guess the billing on CPU time about loading requests will be lower. I didn't know http requests were actually handled serially (each by an entirely new instance of the app).
So by enabling threadsafe I will be able to handle more requests with less instances and less warm requests and less loading requests??
Java technology is built on the premise that Servlets/JSP are multi-threaded by by default - it is the developer's responsibility to synchronize single-threaded code. Multi-tier webapps are most often architected to be thread safe: from DAO's in the data access tier to Service classes in the business tier and Controller classes in the presentation tier. Popular web frameworks like Spring MVC and Struts are built thread-safe.
Not treating Servlets/JSPs as threadsafe increases compute resource utilization (costs) and hurts performance.
I'm really surprised to hear that GAE has been serializing HTTP requests to Java webapps all this time. Or am I missing something here. Does the appengine-web.xml element "<threadsafe>true</threadsafe>" mean something else?
GAE/j really wasn't multi-threaded until now? What's required once you turn on multi-threading? Is it just the standard servlet behaviour of a single servlet instance getting multiple concurrent calls to doGet() or doPost()? If so, I'm surprised this hasn't been the default this whole time.
Damian: That's exactly correct. Enabling concurrent requests should decrease the number of loading requests, and therefore your overall CPU usage. It may also make local heap-based caches more effective. The only potential cons are that you may run into concurrency issues in your own code or frameworks or libraries that you depend on. If you are using a large amount of heap space for the duration of each request you may also run into memory contention that was not previously possible.
Safi: I would hope that you are correct (that almost everyone can safely turn on ), especially considering that the DevAppServer has always executed requests concurrently. However, we cannot rule out the possibility of deadlocks or other concurrency bugs in widely-used libraries built for App Engine so we decided to make this an opt-in feature.
s, Steve: We expected this to be somewhat surprising to many Java developers. However, please keep in mind that we have always scaled your application out to a potentially very large number of processes and machines, depending on its load. Executing in multiple threads within each process just allows us to do so with less RAM usage (something that we don't currently charge for) and with fewer loading requests.
I'm trying to use File API to store files to Blobstore but keep getting java.lang.ClassNotFoundException: com.google.appengine.api.files.FileServiceFactory on my local development server.
Any ideas?
Good work with including File API btw! Hopefully it works on dev. server too.
I am trying to use the Remote API for java and I get the following error: java.lang.NoClassDefFoundError: Could not initialize class com.google.appengine.tools.remoteapi.RemoteApiInstaller
Follow
The ability to download production code would be really great. Looking forward for that!
ReplyDeleteGreat news! The ability to write to Blobstore will save me a lot of time, and make obsolete my hand made in-memory/datastore file storage.
ReplyDeleteCongratunations AppEngine Team!
Great!
ReplyDeleteExcellent Thanks!
ReplyDeleteseriously, still waiting JDBC. It seems crippled without it.
ReplyDeleteGood Job!!! I'm looking forward to the blob reader.
ReplyDeletehttp://code.google.com/p/gwt-examples/wiki/DemoGAEMultiFileBlobUpload
Thank you for Blobstore. You guys are seriously awesome.
ReplyDeleteWhat are the pros of enabling Concurrent Requests over the current scaling algorithm GAE uses??
ReplyDeleteGuess the billing on CPU time about loading requests will be lower.
I didn't know http requests were actually handled serially (each by an entirely new instance of the app).
So by enabling threadsafe I will be able to handle more requests with less instances and less warm requests and less loading requests??
Having a link to this page or some other release notes in the Google Software Update notifier would be nice, rather than forcing me to google it....
ReplyDeleteIs there any news about integration GAE + Google Storage For Developers?
ReplyDeleteAgain... awesome!
ReplyDeleteGood work, I have also noticied that java deployment takes less time..
ReplyDeleteThank you guys! Awesome work as always, looking forward to using the Testbed and the new blobstore API.
ReplyDeleteI didn't know http requests were actually handled in a Single-Thread Model on GAE. o_O
ReplyDeleteI guess very few has written/deployed code that requires (is based on) a STM. Thus almost everybody could simply enable <threadsafe>, right?
Java technology is built on the premise that Servlets/JSP are multi-threaded by by default - it is the developer's responsibility to synchronize single-threaded code. Multi-tier webapps are most often architected to be thread safe: from DAO's in the data access tier to Service classes in the business tier and Controller classes in the presentation tier. Popular web frameworks like Spring MVC and Struts are built thread-safe.
ReplyDeleteNot treating Servlets/JSPs as threadsafe increases compute resource utilization (costs) and hurts performance.
I'm really surprised to hear that GAE has been serializing HTTP requests to Java webapps all this time. Or am I missing something here. Does the appengine-web.xml element "<threadsafe>true</threadsafe>" mean something else?
GAE/j really wasn't multi-threaded until now? What's required once you turn on multi-threading? Is it just the standard servlet behaviour of a single servlet instance getting multiple concurrent calls to doGet() or doPost()? If so, I'm surprised this hasn't been the default this whole time.
ReplyDeleteThe update seems that it takes a day or two to make it to the eclipse update channel.
ReplyDeletehttp://gwt-examples.googlecode.com
Damian: That's exactly correct. Enabling concurrent requests should decrease the number of loading requests, and therefore your overall CPU usage. It may also make local heap-based caches more effective. The only potential cons are that you may run into concurrency issues in your own code or frameworks or libraries that you depend on. If you are using a large amount of heap space for the duration of each request you may also run into memory contention that was not previously possible.
ReplyDeleteSafi: I would hope that you are correct (that almost everyone can safely turn on ), especially considering that the DevAppServer has always executed requests concurrently. However, we cannot rule out the possibility of deadlocks or other concurrency bugs in widely-used libraries built for App Engine so we decided to make this an opt-in feature.
s, Steve: We expected this to be somewhat surprising to many Java developers. However, please keep in mind that we have always scaled your application out to a potentially very large number of processes and machines, depending on its load. Executing in multiple threads within each process just allows us to do so with less RAM usage (something that we don't currently charge for) and with fewer loading requests.
Regarding the concurrent request - does anyone know how the python environment is handled at the moment?
ReplyDeleteI'm trying to use File API to store files to Blobstore but keep getting java.lang.ClassNotFoundException: com.google.appengine.api.files.FileServiceFactory on my local development server.
ReplyDeleteAny ideas?
Good work with including File API btw! Hopefully it works on dev. server too.
GREAT!
ReplyDeleteConcurrent requests? Holy crap!
ReplyDelete... You guys rock!
I am trying to use the Remote API for java and I get the following error: java.lang.NoClassDefFoundError: Could not initialize class com.google.appengine.tools.remoteapi.RemoteApiInstaller
ReplyDeleteAnyone knows why?
I want to use "like %word%" in Database.
ReplyDeleteIs it any reason?