0

I am building a rich app on GAE using Canoo's RIA Suite. This package splits Java Swing components into server-side and client-side parts. On the server, it looks like a 'desktop' Java application. The client keeps its own map between these halves. When GAE starts a new instance, the client-side parts don't know about it -- if the next request they send is routed to the wrong instance bad things happen.

I figure I could get around this problem if I did one of two things:

  1. Forced a GAE instance to serve exactly one HTTP session.
  2. Directed each HTTP request to a specific GAE instance.

My question is, in the GAE environment, can either of these be done?

Tony Carter
  • 11
  • 3

2 Answers2

1

Neither of these two options will solve your problem, because an App Engine instance can die and be replaced at any moment.

If you can save a state of your server-side "half" in a datastore, you can load it when a request hits the "wrong" instance, but it's probably not a very efficient solution.

You may be better off using a Compute Engine instance.

Andrei Volgin
  • 40,755
  • 6
  • 49
  • 58
  • Thanks for the suggestions. I already cache most GUI information inside the HTTP session object, some other information in memcache and still other pieces in the datastore. If I set the pending latencies to some rather high number things work semi-well. But there are still vexing situations where a request takes a bit too long and a new instance is spawned or where (like you point out) an instance just dies (these are becoming somewhat rarer). – Tony Carter Jun 09 '14 at 17:24
  • I am not sure why you chose this framework. I use GWT, which is stateless and has none of such problems. – Andrei Volgin Jun 09 '14 at 19:01
  • @Tony Carter there is no way you will reliably work around these issues you describe. You will need to change your model to deal with instances that go away. This is fundamental to appengine. (Unless you want to pay for a backend for each user) – Tim Hoffman Jun 09 '14 at 23:21
0

I agree that neither of those two options will work for you. The implication of your current design is that you are storing state in memory on an instance, which will not work with GAE (or any autoscaling distributed system). You should put any state into some distributed data store, whether that is memcache (which is volatile), the datastore or cloudSQL

GAE/J has built in support for java sessions, the session state is persisted in the datastore across requests so that it is valid on any instance. For this to work, everything stored in your session will need to be serializable.

You can enable this by following these instructions.

Otherwise you can manage persisting server state yourself into the datastore accelerated by memcache, and linking it to a 'session' with a cookie. If you go down this road make sure you understand the implications of eventual consistency in the GAE datastore.

Nick
  • 1,822
  • 10
  • 9