[dyuproject] Scaling to multiple servers on GAE and the pitfall

10 views
Skip to first unread message

Phuong Nguyen

unread,
Apr 26, 2010, 11:53:02 AM4/26/10
to dyuproject
Hi,
I notice one thing, when ever my app restart, then user have to login
again.
It concerns me when I think about this scenario:
Normally, my app run on Server #1
When traffic increase, then the cloud will start my app on Server
#2 and forward request alternatively between Server #1 and Server #2.
Imagine one user has logged in and his session is stored on #1. Now
his request is forwarded to Server #2 and he has to login again. And
now his request is forwarded to Server #1 again, Server #1 cannot
understand his session (since it is stored on Server #2) and request
him to login again. And again, again.

Is this the stuff that will happen? Can you suggest a work around for
it?

Thanks

--
You received this message because you are subscribed to the Google Groups "dyuproject" group.
To post to this group, send email to dyupr...@googlegroups.com.
To unsubscribe from this group, send email to dyuproject+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/dyuproject?hl=en.

David Yu

unread,
Apr 27, 2010, 2:10:04 AM4/27/10
to dyupr...@googlegroups.com
On Mon, Apr 26, 2010 at 11:53 PM, Phuong Nguyen <phuon...@gmail.com> wrote:
Hi,
I notice one thing, when ever my app restart, then user have to login
again.
It concerns me when I think about this scenario:
  Normally, my app run on Server #1
  When traffic increase, then the cloud will start my app on Server
#2 and forward request alternatively between Server #1 and Server #2.
  Imagine one user has logged in and his session is stored on #1. Now
his request is forwarded to Server #2 and he has to login again. And
now his request is forwarded to Server #1 again, Server #1 cannot
understand his session (since it is stored on Server #2) and request
him to login again. And again, again.

Is this the stuff that will happen?
Nope.  GAE's sessions are saved on the datastore (where the key is the jsessionid).
Therefore any server will be able to read the jsessionid from the cookie and load from the datastore.
As long as the last server updates and persists the OpenIdUser upon finishing the request, any
other server will be able to continue to work with the updated data.
You can track the state by setting OpenIdUser.setAttribute("your_state", "bar");
 
Can you suggest a work around for
it?
You can also implement a custom UserManager and be able to serialize and save the OpenIdUser in memcache for example.


Thanks

--
You received this message because you are subscribed to the Google Groups "dyuproject" group.
To post to this group, send email to dyupr...@googlegroups.com.
To unsubscribe from this group, send email to dyuproject+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/dyuproject?hl=en.




--
When the cat is away, the mouse is alone.
- David Yu

Scott Hernandez

unread,
Apr 27, 2010, 2:33:08 AM4/27/10
to dyupr...@googlegroups.com
You do have to turn session on in GAE, by default it is off (making
sessions just work on one server, or not at all; I forget). If you
don't have them on this might cause problems.

http://code.google.com/appengine/docs/java/config/appconfig.html#Enabling_Sessions

I suspect if you are seeing problems it is because you have not
enabled sessions (stored in the datastore).

>> Can you suggest a work around for
>> it?
>
> You can also implement a custom UserManager and be able to serialize and
> save the OpenIdUser in memcache for example.

Memcache may not be a good place to store this as it can be cleared,
or any data can be invalidated at any time (as other apps use it more
aggressively).

David Yu

unread,
Apr 27, 2010, 2:58:39 AM4/27/10
to dyupr...@googlegroups.com

Right ... most of the time it is not a good place to store session data.
 

Phuong Nguyen

unread,
Apr 27, 2010, 5:55:04 AM4/27/10
to dyupr...@googlegroups.com
Thank you guys for the explanation,
I'm checking my app configuration.
Phuong.
Reply all
Reply to author
Forward
0 new messages