[ http://issues.apache.org/jira/browse/AXIS-2314?page=all ]
Davanum Srinivas resolved AXIS-2314:
------------------------------------
Resolution: Fixed
Checked in the last patch with WeakHashMap :)
thanks,
dims
> 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
