[
https://issues.jboss.org/browse/JBAS-9491?page=com.atlassian.jira.plugin....
]
Chris Rankin commented on JBAS-9491:
------------------------------------
I can fix the JUnit test by reimplementing the {{equals()}} method as follows:
{code:Java}
@Override
public boolean equals(final Object obj) {
if (this == obj) {
return true;
}
if ((obj == null) || (obj.getClass() != getClass())) {
return false;
}
AsyncInvocationIdUUIDImpl other = (AsyncInvocationIdUUIDImpl) obj;
return uuid.equals(other.uuid);
}
{code}
But first, can anyone explain the original {{equals()}} implementation, please? Could
anything be relying on that other implementation's weirdness?
JBoss 6.0.0-Final leaks an AsyncInvocationIdUUIDImpl object for every
asynchronous call
---------------------------------------------------------------------------------------
Key: JBAS-9491
URL:
https://issues.jboss.org/browse/JBAS-9491
Project: Application Server 3 4 5 and 6
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: EJB
Affects Versions: 6.0.0.Final
Environment: CentOS, Windows7
Reporter: Chris Rankin
Assignee: Carlo de Wolf
The {{AsyncInvocationIdUUIDImpl.equals()}} method is implemented as:
{code:Java}
@Override
public boolean equals(final Object obj) {
return uuid.equals(obj);
}
{code}
This implementation is incompatible with {{ConcurrentHashMap<AsyncInvocationId,
Boolean>}}, which means that {{AsyncInvocationMap.remove(id)}} does _not_ remove the
{{AsyncInvocationIdUUIDImpl}} object from the map at all. In other words, the
{{AsynchronousServerInterceptor.invoke()}} method is accumulating
{{AsyncInvocationIdUUIDImpl}} objects until the JVM's heap explodes.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see:
http://www.atlassian.com/software/jira