Inefficient Session Implementation on Google App Engine / Java & GAE Critics

[Mos]

Wrote an article on my blog about this:
http://www.mosbase.com/2012/04/inefficient-session-implementation-on.html

There is also a ticket. Please vote for it if you are affected as well:
http://code.google.com/p/googleappengine/issues/detail?id=7355

Cheers
Mos

[Brandon Wirtz]

Just so I’m clear.

 

You used a frame work built for another platform. Wedged it in to this platform. It is inefficient because it thinks it needs to re-validate sessions faster than a page would load, which creates a boat load of unnecessary requests.

You acknowledge all of that.

 

And then you still complain about GAE’s service and support?

 

It would appear that the failing of GAE is that they don’t put huge disclaimers at the top of every documentation page saying “If you just copy and paste code from old Python and Java applications your shit will break so don’t frakking do it.”   Then when people complain in the forums we could say RTFM and be done with it.

 

 

 

Brandon Wirtz BlackWaterOps: President / Lead Mercenary
Work: 510-992-6548 Toll Free: 866-400-4536 IM: dra...@gmail.com (Google Talk) Skype: drakegreene YouTube: BlackWaterOpsDotCom BlackWater Ops Cloud On A String Mastermind Group

 

 

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

[Mos]

I think you don't understand the point.  Spring isn't build for another platform. It's build as a core Java framework and is also supported for GAE applications.
Our application is new and 100% build and optimized for GAE.

By the way:  Some times your "humble" signature seems to have more substance than the content you write on this list. ;)

[Jeff Schnitzer]

In all fairness, http sessions are generally considered a bad idea these days.  Especially if you have scalability requirements.

Jeff

[Brandon Wirtz]

> Our application is new and 100% build and optimized for GAE.

I realize English may not be your primary language, but you did read the article your wrote right?

 

“Optimized for GAE” and “Uses Sessions”  are not the same. Also, if you check stack overflow there are about 1000 posts telling you “DON’T DO IT MAN”

Spring MVC adds about 6 seconds to your cold start time. On a good day, on a bad day it adds 12-15 seconds. Spring JDO ads about this much again.  This causes you cascading errors when your app gets over run, and GAE has a slow day at the same time, as your Spin up can be 30 seconds without much effort and you are already looking at 85MB of instance memory being use before you have done anything.

Spring should only be used if you are going to run F2 instances. Warm-Up, and 2 or more idle instances at all times.

 

Are you doing those things?

[Mos]

> In all fairness, http sessions are generally considered a bad idea these days.  Especially if you have scalability requirements.

Totally agree (for applications with high scalability requirements ).  But that's another discussion.

If a platform offers session support (like GAE) it should be implemented in an efficient way. I consider the current implementation as a bug.
Show me one other Java-Web-Container that does more than one remote call (== database-query) per request for checking a session-state.
There seems to be no logical reason for this...

Cheers
Mos

[andrew]

As an ignorant, can I genuinely ask:

What is the recommended equivalent implementation for apps with high scalability needs (available in Java and NOT using a GAE API directly)?

[Jeff Schnitzer]

There isn't a straight-up answer to that. The question to ask is:
Why do you think you need a server-side session? Depending on the
answer, there are various solutions.

For example, if you're storing the authentication state of a user in
the session, store it as a signed cookie instead. Easy.

If you have some kind of per-user server-side state you are
maintaining, stash it in memcache (if it is not essential) or the
datastore (if it is). This is what the session does, except that with
sessions you don't have granular control. You end up struggling with
the performance profile because the behavior of sessions in a cluster
is poorly defined - some people need super transactional robust
behavior, others don't care if the data expires randomly.

Jeff

On Mon, Apr 16, 2012 at 3:27 PM, andrew <andrew.m...@bcntouch.com> wrote:
> As an ignorant, can I genuinely ask:
>
> What is the recommended equivalent implementation for apps with high scalability needs (available in Java and NOT using a GAE API directly)?
>

> --
> You received this message because you are subscribed to the Google Groups "Google App Engine" group.

> To view this discussion on the web visit https://groups.google.com/d/msg/google-appengine/-/OxttnQjWGMEJ.

[Thomas Wiradikusuma]

I end up setting <session> to false and implementing HttpSession myself which uses memcache (and +datastore for selected props).

On Tuesday, 17 April 2012 05:51:22 UTC+8, Jeff Schnitzer wrote:

There isn't a straight-up answer to that.  The question to ask is:
Why do you think you need a server-side session?  Depending on the
answer, there are various solutions.

For example, if you're storing the authentication state of a user in
the session, store it as a signed cookie instead.  Easy.

If you have some kind of per-user server-side state you are
maintaining, stash it in memcache (if it is not essential) or the
datastore (if it is).  This is what the session does, except that with
sessions you don't have granular control.  You end up struggling with
the performance profile because the behavior of sessions in a cluster
is poorly defined - some people need super transactional robust
behavior, others don't care if the data expires randomly.

Jeff

On Mon, Apr 16, 2012 at 3:27 PM, andrew <andrew.m...@bcntouch.com> wrote:
> As an ignorant, can I genuinely ask:
>
> What is the recommended equivalent implementation for apps with high scalability needs (available in Java and NOT using a GAE API directly)?
>
> --
> You received this message because you are subscribed to the Google Groups "Google App Engine" group.
> To view this discussion on the web visit https://groups.google.com/d/msg/google-appengine/-/OxttnQjWGMEJ.

> To post to this group, send email to google-appengine@googlegroups.com.
> To unsubscribe from this group, send email to google-appengine+unsubscribe@googlegroups.com.

[Takashi Matsuo]

Hi,

Sorry if you already tried it, but we recently released asynchronous
session described at:
https://developers.google.com/appengine/docs/java/config/appconfig#Enabling_Sessions

Doesn't following setting help with your case?
<async-session-persistence enabled="true" />

I basically agree with Jeff though. Besides that, we can expect that
modern clients does likely have a better local storage, so it could be
another option.

-- Takashi

>> > To post to this group, send email to google-a...@googlegroups.com.

>> > To unsubscribe from this group, send email to

>> > google-appengi...@googlegroups.com.

>> > For more options, visit this group at
>> > http://groups.google.com/group/google-appengine?hl=en.
>> >
>

> --
> You received this message because you are subscribed to the Google Groups
> "Google App Engine" group.
> To view this discussion on the web visit

> https://groups.google.com/d/msg/google-appengine/-/k849D6UBAjQJ.
>
> To post to this group, send email to google-a...@googlegroups.com.

> To unsubscribe from this group, send email to

> google-appengi...@googlegroups.com.

> For more options, visit this group at
> http://groups.google.com/group/google-appengine?hl=en.

--
Takashi Matsuo | Developer Advocate | tma...@google.com | 03-6384-9224