[ http://issues.apache.org/jira/browse/AXIS-2314?page=all ]
Ben Gunter updated AXIS-2314:
-----------------------------
Attachment: SOAPService.java-Axis_1.3.patch
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 SOAPService.java 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: http://issues.apache.org/jira/browse/AXIS-2314
> 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: SOAPService.java-Axis_1.3.patch,
> SOAPService.java-Axis_1.3.patch, SimpleSessionHandler.java-Axis_1.3.patch
>
> 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:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
