axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ben Gunter (JIRA)" <>
Subject [jira] Updated: (AXIS-2314) Axis leaking Session objects
Date Tue, 22 Nov 2005 16:28:42 GMT
     [ ]

Ben Gunter updated AXIS-2314:


This is an alternative fix.  I've changed the sessions Vector to a WeakHashMap.  This allows
the SOAPService object to track active sessions and for old sessions to be cleaned up automatically.
 If you choose this approach, then only must be patched and no API changes
are required.  My tests showed this change will fix the problem.

> Axis leaking Session objects
> ----------------------------
>          Key: AXIS-2314
>          URL:
>      Project: Apache Axis
>         Type: Bug
>   Components: Basic Architecture
>     Versions: 1.3
>  Environment: Tomcat 5.5.12; JDK 1.4.0, 1.4.2, and 1.5; Windows XP Pro and Solaris 9
>     Reporter: Ben Gunter
>  Attachments:,,
> I have deployed a session-scoped service using the SimpleSessionHandler.  I discovered
the hard way that SimpleSession objects are not being  recovered by the garbage collector
and after some research found the root of the problem.
> It seems that each org.apache.axis.handlers.soap.SOAPService object maintains a Vector
of active sessions associated with it.  Likewise, each org.apache.axis.handlers.SimpleSessionHandler
maintains a Hashtable mapping session IDs to SimpleSession objects.  The SimpleSessionHandler's
reaping mechanism works properly, cleaning up stale sessions by removing them from the activeSessions
Hashtable after they've timed out.  The problem is that SOAPService has no such mechanism,
and in fact provides no public method to remove Sessions from its own private Vector of active
> sessions.  (Incidentally, even clearSessions() doesn't free the sessions up, just removes
an attribute from each of them.)
> To complicate matters further, when the SimpleSessionHandler removes a Session from activeSessions,
it does not call invalidate() on the session so any properties that have been set on the Session
are still referenced by the Session, which is still referenced by the SOAPService object.
 This can cause some major problems -- in my case a file handle leak that forced a restart
about every hour.
> I'm sure there's more than one way to correct the problem, but I took two simple steps.
 First, I added a public removeSession() method to SOAPService, like so:
>    /**
>     * Remove the given session from its known sessions
>     */
>    public void removeSession(Session session) {
>      session.remove( this.getName() );
>      Vector v = (Vector) sessions.get( this.getName() );
>      if ( v != null ) v.remove( session );
>    }
> And then I inserted a few lines into SimpleSessionHandler's invoke() method, like so:
> (At line 25)
> import org.apache.axis.handlers.soap.SOAPService;
> ...
> (At line 137)
>            SOAPService service = context.getService();
> ...
> (At line 155)
>                if (service != null)
>                        service.removeSession(session);
> Hopefully those line numbers haven't been changed by a formatter or something.  I'll
attach the output of diff -u if I can figure out how.
> My testing shows that with this change in place, the Sessions and all of their properties
get cleaned up properly.  I don't, however, know if this will have some ill side effects that
I'm not aware of.  I'll let you folks determine that, since you know much more about the code
than I do.
> What might be a better solution would be for SOAPService to maintain a list of weak references
to the sessions instead of strong references.  Then the only thing that would need to change
would be a few null checks here and there.
> If SOAPService absolutely must maintain a reference to every Session ever associated
with it, then at a minimum the SimpleSessionHandler must call Session.invalidate() on expired
sessions, which frees all the properties of the Session.  My testing showed that would prevent
major problems, but that the Session objects themselves still don't get freed.

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:

View raw message