[
https://issues.apache.org/jira/browse/AXIS-2314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13461087#comment-13461087
]
Hudson commented on AXIS-2314:
------------------------------
Integrated in axis-trunk #150 (See
[https://builds.apache.org/job/axis-trunk/150/])
Reverted r256500 (AXIS-524) and r348194 (AXIS-2314; fixing a regression
caused by r256500). See the comments in AXIS-524 for the rationale of this
revert.
This should fix AXIS-2878. (Revision 1388756)
Result = SUCCESS
veithen :
Files :
*
/axis/axis1/java/trunk/axis/src/main/java/org/apache/axis/deployment/wsdd/WSDDUndeployment.java
*
/axis/axis1/java/trunk/axis/src/main/java/org/apache/axis/handlers/soap/SOAPService.java
*
/axis/axis1/java/trunk/axis/src/main/java/org/apache/axis/providers/java/JavaProvider.java
> Axis leaking Session objects
> ----------------------------
>
> Key: AXIS-2314
> URL: https://issues.apache.org/jira/browse/AXIS-2314
> Project: Axis
> Issue Type: Bug
> Components: Basic Architecture
> Affects 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: SimpleSessionHandler.java-Axis_1.3.patch,
> SOAPService.java-Axis_1.3.patch, SOAPService.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, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
