Google App Engine, Sticky Sessions and the Single Page Interface

Home

News: Google App Engine, Sticky Sessions and the Single Page Interface

  1. Google App Engine (GAE) is a very attractive Java hosting service for web applications, it combines price (the first level is free), easy of deployment, manageability and “infinite” scalability. Having said that, it also has many limitations like a very long number of black-listed Java classes, limited threading, only one database technology etc. However, there is another very important limitation that needs to be addressed: the fact that only replicated sessions are supported. What effect does this have? How can the risks be mitigated? Read Jose Maria Arranz' article on GAE and session affinity.

    Some hope for server-centric AJAX frameworks in Google App Engine
  2. We're using GAE to develop our project, but I found I have a performance issue, when checking the logs I found the GAE will auto- restarting every 30-60 sec. 

    Someone tell me this's because if the web app wasn't used much, GAE will dispose the instances, and after that made a load request to spin up a new VM and servlet container. So I write a very simple testing for confirm this: 

    -- Test Servlet -- // using JPA to store a counterrequest.count = Counter.createOrIncrement("JspTest", 1); 
    forward '/test.jsp'; 

    -- Test JSP -- 
    <%@include file="/includes/header.jsp"%>
    </head>
    <body>
    <h1>
    Count: ${count}  <!--  GET THE COUNT FROM REQUEST FOR VIEW  -->
    </h1>
    <%@include file="/includes/footer.jsp"%> 

    -- Log Messages -- 
    06-02 10:27PM 57.036 com.liyue.web.ContextListener contextInitialized: Web context inited.  --->> FIRST REQUEST 
    06-02 10:27PM 58.036 javax.servlet.ServletContext log: Action servlet initialized. 
    06-02 10:28PM 06.379 [...].<stdout>: com.liyue.web.Test spend : 8341 ms  --->> SPEND 8sec FOR INIT AND EXEC ... 
    06-02 10:28PM 39.401 [...].<stdout>: com.liyue.web.Test spend : 56 ms  --->> VERY GOOD PERFORMANCE ... 
    06-02 10:30PM 03.502 [...].<stdout>: com.liyue.web.Test spend : 60 ms  --->> VERY GOOD PERFORMANCE ... 
    06-02 10:32PM 52.688 com.liyue.web.ContextListener contextInitialized: Web context inited.  --->> AUTO-RELOAD !!!! 
    06-02 10:32PM 53.636 javax.servlet.ServletContext log: Action servlet initialized. 
    06-02 10:33PM 01.669 [...].<stdout>: com.liyue.web.Test spend : 8032 ms  --->> VERY POOR PERFORMANCE ... 

    I have no idea for how to solve this issue, but this may make us give up using GAE, because our boss and customers couldn't accept this poor performace. But we have wrote lots of code for GAE, if you have any idea could help us please tell me.

     
    http://code.google.com/p/googleappengine/issues/detail?id=2931  --->> PLEASE STAR IT !!


    THANKS VERY VERY MUCH in advance !!!

  3. If you read my article you will find the answer: your application is being loaded in a new node (or maybe the JVM is being recycled, yes could be the reason) .

    Take a look the time lapse before your application is reloaded

    10:30PM 03 ... VERY GOOD

    10:32PM 52 ... AUTO-RELOAD

    Difference, around 3 minutes, enough for Google to say goodbye to the current node and dispatch to another node.

    Solution: try with an AJAX timer kicking the server (doing nothing), maybe one request per minute (or less) and GAE will keep your user in the same node.

     

     

  4. YES~~ You're Right !!![ Go to top ]

    Dear Jose:

    Thanks very very much !! Your solution is correct. It help us lots, thank you again !!!

  5. "only replicated sessions are supported"

    This looks like a serious limitation. Have we found parctical wrokarounds for this?

    Please share them with us.

    Personally I suggest you guys wtich to Python Google AppEngine. That has been working fine for us.

     

    george kyaw naing

    http://ethicminds.blogspot.com/

  6. http://onjava.com/onjava/2004/11/24/replication1.html has some ideas:

    Design Considerations for Session Replication

    Network Considerations

    It is important to isolate the cluster multicast address with other applications. We don't want the cluster configuration or the network topology to interfere with multicast server communications. Sharing the cluster multicast address with other applications forces clustered server instances to process unnecessary messages, introducing overhead. Sharing a multicast address may also overload the IP multicast buffer and delay transmission of the server heartbeat messages. Such delays can result in a server instance being marked as dead, simply because its heartbeat messages were not received in a timely manner.

    Programming Considerations

    In addition to the network-related factors mentioned above, there are some design considerations related to the way we write J2EE web applications that also affect session replication. Following is a list of some of these programming considerations:

    • Session data must be serializable: To support in-memory replication of HTTP session state, all servlet and JSP session data must be serializable. Every field in an object must be serializable or transient in order for the object to be considered serializable.
    • Design the application to be idempotent: The term "idempotent" means that an operation doesn't modify the state information and returns the same results each time it's performed (in other words, performing a routine more than once has the same effect as performing it once). Sometimes, web requests, especially HTML forms, are submitted more than once (when the user clicks the Submit button twice and reloads a web page multiple times), resulting in duplicate HTTP requests. Design servlets and other web objects to be idempotent; i.e., to tolerate the duplicate requests. Refer to design patterns such as Synchronized Token and Idempotent Receiver for details on how to design idempotent applications.
    • Store state on the business tier: Conversational state should be maintained in the EJB layer using stateful session beans, rather than in an HttpSession in the web tier. Since the enterprise application is going to support various types of clients (web clients, Java applications, and other EJBs) storing the data in the web tier will result in duplicate data storage on the clients. Therefore, stateful session beans should be considered for storing the session state in these scenarios. A stateless session bean reconstructs conversational state for each invocation. The state may have to be rebuilt by retrieving data from a database. This completely defeats the purpose of using stateless session beans to improve performance and scalability, and can severely degrade performance.
    • Serialization overhead: Serializing session data has some overhead for replicating the session state. The overhead increases as the size of serialized objects grows. It's a good idea to keep the session size reasonably small. But if you have to create very large objects in the session, test the performance of your servlets to ensure that performance is acceptable and session replication time is reasonable.
    • User sessions: It is important to determine the maximum number of concurrent user sessions that will be handled by each Tomcat server instance in the cluster. To handle more concurrent sessions, we will need to add more memory for efficiency. The maximum number of concurrent clients and how frequently each client will be making a request also factors in deciding session replication's impact on the server performance.

    So other Java clustered environments also have this problem, right?

    george kyaw niang at  http://ethicminds.blogspot.com/ 

     

     

    <!--CS_PAGE_INDEX-->
  7. Type "java + replicated sessions" in Google search and most articles are dated 2004 to 2007. e.g.

    http://www.ibm.com/developerworks/java/library/j-jtp07294.html 

    So, this is a very old problem for Java world.

    Perhaps this is solved already.

    Perhaps, this is TRIAGED out.

    Perhaps this is a very WICKED problem for computer science.

    george kyaw naing at

    http://ethicminds.blogspot.com/

  8. "only replicated sessions are supported" This looks like a serious limitation. Have we found parctical wrokarounds for this?

    Have you read my article?

     

     

  9. Is it worth it?[ Go to top ]

    Seems like unless your application is inherently stateless, one has to develop all kinds of work-arounds to do a basic transactional site, functionality that other platforms has had for years.  Is it worth it?