Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 321307

Summary:

Sessions should be passivated *before* being serialized to disk

Product:

[RT] Jetty

Reporter:

Eirik Bjørsnøs <eirbjo>

Component:

server

Assignee:

Greg Wilkins <gregw>

Status:

RESOLVED FIXED

QA Contact:

Severity:

normal

Priority:

CC:

jetty-inbox, mgorovoy

Version:

unspecified

Target Milestone:

7.1.x

Hardware:

Macintosh

OS:

Mac OS X - Carbon (unsup.)

Whiteboard:

Attachments:

Description	Flags
Test webapp which demonstrates that sessionWillPassivate is never called	none

Description Eirik Bjørsnøs

2010-07-30 05:12:07 EDT

Build Identifier: 

According to the servlet spec:

"A container that migrates session between VMs or persists sessions is required to notify all attributes bound to sessions implementing HttpSessionActivationListener."

And:

"public void sessionWillPassivate(HttpSessionEvent se): Notification that the session is about to be passivated."

Although the spec might not be 100% specific about it, I think the container should call sessionWillPassivate before a session is persisted.

Jan Bartel also supports this view on jetty-dev:

"Hhhmm, I think that's a bug. We really should call willPassivate()
before the objects are written out. This will need some refactoring
of the AbstractSessionManager to accommodate the HashSessionManager's
doStop() behaviour. The listeners are actually called by
AbstractSessionManager.doStop() which removes each of the sessions and
then calls the willPassivate() - in that order."

Given a rough todo-list and some hand holding I could attempt writing a patch for this. Otherwise, I'll leave it to the gurus :-) 

Reproducible: Always

Steps to Reproduce:
1. Leave a non-serializable attribute in the session
2. Have a HttpSessionActivationListener remove the attribute on sessionWillPassivate
3. Confirm that an exception is thrown during serialization, before sessionWillPassivate is called

Comment 1 Eirik Bjørsnøs

2010-07-30 07:17:40 EDT

Looking at this a little closer, I can't see Jetty ever calling willPassivate on a session in the current HashSessionManager since it's protected by an if(!invalidate) and invalidate seems to be true always.

Comment 2 Eirik Bjørsnøs

2010-07-30 07:21:16 EDT

Created attachment 175557 [details]
Test webapp which demonstrates that sessionWillPassivate is never called


Simple webapp used for demonstrating HttpSessionActivationListeners being not being called before serialization. Or actually not being called at all.

Comment 3 Greg Wilkins

2010-08-04 01:06:16 EDT

So I'm going to commit a patch that calls willPassivate before is saves sessions and didActivate after it restores sessions.

But it is a truly horrible specification... we can run in a mode where we save a session periodically - so we will now call willPassivate before the save and didActivate after the save.  But there is no locking to prevent other requests hitting the session during this time.

Likewise, after a session is restored, there is nothing to prevent other requests hitting the session before didActivate is called.

I'm just running some tests to confirm I've not broken anything, then I will commit.

Comment 4 Greg Wilkins

2011-02-21 02:20:07 EST

jetty-7.2.0.RC0 1 October 2010