Póka Balázs schrieb:
Hi there,
Just a thought: what if you modified SessionInfo.timeout(Object) like
this:
public final void timeout(Object userData) {
synchronized (this.EXPIRY_TIMER_MONITOR) {
this.timerKey = null;
log.warning(ME+": Session timeout for " + getLoginName() + "
occurred, session '" + getSecretSessionId() + "' is expired, autologout");
}
DisconnectQosServer qos = new DisconnectQosServer(glob);
qos.deleteSubjectQueue(true);
try {
glob.getAuthenticate().disconnect(getAddressServer(),
getSecretSessionId(), qos.toXml());
} catch (XmlBlasterException e) {
log.severe(ME+": Internal problem with disconnect: " +
e.toString());
}
}
It seems as if timerKey is protected by EXPIRY_TIMER_MONITOR
elsewhere, but not here (this might be an error). I simply removed the
locking of "lock" from the method. Does this make it
thread-unsafe? :)
No, i think the original sync did not make sense,
as the disconnect (coming here from a timeout thread)
can also come from a remote client which disconnects at any time,
so the core must be capable to handle this situation anyhow.
I have removed the sync here and also in shutdown() to prevent the deadlock.
The current code is now committed to svn.
thanks again
Marcel
regards,
Balázs
--
Marcel Ruff
http://www.xmlBlaster.org
http://watchee.net
Phone: +49 7551 309371
