Anyone have sessions working under Google AppEngine?

[Frank McIngvale]

Hi everybody, I'm playing some more with CherryPy under Google
AppEngine, and am stuck when it comes to sessions. For a first try, I
set the session type to 'ram' -- even though this won't do anything
since GAE runs one process per request, I figured it was a good place
to start.

Problem is that any attempt to set data into the session causes the
server to hang. i.e. a simple:

cherrypy.session['ABC'] = 'this is ABC'

.. causes a hang.

I can do, e.g.:
cherrypy.session.get('ABC','DEF')

This does not hang, but always returns 'DEF'.

I'm a little lost as to where to start tracking down the problem.
Looking through cherrypy.lib.sessions I don't see anywhere that it
could hang in e.g. __getitem__. Anyone have tips on where I should
start looking?

thanks,
Frank

[Frank McIngvale]

On 7/5/08, Frank McIngvale <fmcin...@gmail.com> wrote:

Hi everybody, I'm playing some more with CherryPy under Google
AppEngine, and am stuck when it comes to sessions. For a first try, I
set the session type to 'ram' -- even though this won't do anything
since GAE runs one process per request, I figured it was a good place
to start.

Problem is that any attempt to set data into the session causes the
server to hang. i.e. a simple:

I think I answered my own question. In sessions.py:
----
t = cherrypy.process.plugins.Monitor(
              cherrypy.engine, self.clean_up, self.clean_freq * 60)
t.subscribe()
cls.clean_thread = t
t.start() <- hang here
----

Digging into the monitor in process.plugins:
----
self.thread = PerpetualTimer(self.frequency, self.callback)
self.thread.setName(threadname)
self.thread.start() <- hangs here
----
 
A little googling reveals that threads are not supported under GAE, so that explains it (although I wish their runtime would have just raised an exception instead of hanging!)

So I guess the question is whether this can be worked-around, or is threading fundamental to the CherryPy design?

frank

[Robert Brewer]

Frank McIngvale wrote:
> I think I answered my own question. In sessions.py:
> ----
> t = cherrypy.process.plugins.Monitor(
> cherrypy.engine, self.clean_up, self.clean_freq * 60)
> t.subscribe()
> cls.clean_thread = t
> t.start() <- hang here
>

> A little googling reveals that threads are not supported
> under GAE, so that explains it (although I wish their
> runtime would have just raised an exception instead
> of hanging!)
>
> So I guess the question is whether this can be worked-around,
> or is threading fundamental to the CherryPy design?

You can certainly unsubscribe() that Monitor. But then there won't be
any process by which stale session files get harvested--you'd have to
move that to either a cron job, or something that gets run in, say, an
on_end_request hook (i.e. subvert a request thread _after_ it has
returned data to the user).

It looks like you might be able to unsubscribe it most easily by setting
tools.caching.clean_thread to True (or anything else that bool-evals to
True).

Robert Brewer
fuma...@aminus.org

[Frank McIngvale]

On Jul 6, 9:48 am, "Robert Brewer" <fuman...@aminus.org> wrote:
> Frank McIngvale wrote:
> > I think I answered my own question. In sessions.py:
> > ----
> > t = cherrypy.process.plugins.Monitor(
> >     cherrypy.engine, self.clean_up, self.clean_freq * 60)
> > t.subscribe()
> > cls.clean_thread = t
> > t.start() <- hang here
>
> > A little googling reveals that threads are not supported
> > under GAE, so that explains it (although I wish their
> > runtime would have just raised an exception instead
> > of hanging!)
>
> > So I guess the question is whether this can be worked-around,
> > or is threading fundamental to the CherryPy design?
>
> You can certainly unsubscribe() that Monitor. But then there won't be
> any process by which stale session files get harvested--you'd have to
> move that to either a cron job, or something that gets run in, say, an
> on_end_request hook (i.e. subvert a request thread _after_ it has
> returned data to the user).
>

Ah, OK, I was assuming that the Monitor was required for the session
to work. I'll will try unsubscribing it (or just removing it in my
working tree) and see if that helps.

thanks,
Frank

>
> Robert Brewer
> fuman...@aminus.org