Hi @Bill_Roland and @guus, I’d like to revive this tread, we are seeing this problem as well after we upgraded to 4.5.1 (from 4.1.3) and enabled stream management. In fact we are seeing it quite a bit and it is affecting our service. Here are some observations that may help diagnose and fix this problem:
In the admin console under Sessions the user name and resource appear correctly however in the log we have mangled JID’s (see below). See lines 1,2 and 4,5 and notice how user@ is missing and (streamID) is used instead of the resource. Also notice some correct deletes of Detached sessions (line 3, 6, 11, 12,13,14), notice how the FULL JID includes user@service.com/resource and how the (streamID) is not repeated inside the full jid.
- 18:31:37.933 [TaskEngine-pool-2864] DEBUG org.jivesoftware.openfire.SessionManager - Detached session ‘service.com/p36iqpvxo’ (p36iqpvxo) has been detached for longer than PT3S and will be cleaned up.
- 18:31:37.933 [TaskEngine-pool-2864] WARN org.jivesoftware.openfire.SessionManager - Not removing detached session ‘service.com/p36iqpvxo’ (p36iqpvxo) that appears to have been replaced by another session.
- 18:31:37.933 [TaskEngine-pool-2864] DEBUG org.jivesoftware.openfire.SessionManager - Detached session ‘userone@service.com/mobile’ (58tc2lpj4f) has been detached for longer than PT3S and will be cleaned up.
- 18:31:37.950 [TaskEngine-pool-2864] DEBUG org.jivesoftware.openfire.SessionManager - Detached session ‘service.com/539mbil51’ (539mbil51) has been detached for longer than PT3S and will be cleaned up.
- 18:31:37.950 [TaskEngine-pool-2864] WARN org.jivesoftware.openfire.SessionManager - Not removing detached session ‘service.com/539mbil51’ (539mbil51) that appears to have been replaced by another session.
- 18:31:37.950 [TaskEngine-pool-2864] DEBUG org.jivesoftware.openfire.SessionManager - Detached session ‘usertwo@service.com/mobile’ (2cs9dj5oj5) has been detached for longer than PT3S and will be cleaned up.
- 18:31:37.966 [TaskEngine-pool-2864] DEBUG org.jivesoftware.openfire.SessionManager - Detached session ‘service.com/2b9ek0uc4g’ (2b9ek0uc4g) has been detached for longer than PT3S and will be cleaned up.
- 18:31:37.966 [TaskEngine-pool-2864] WARN org.jivesoftware.openfire.SessionManager - Not removing detached session ‘service.com/2b9ek0uc4g’ (2b9ek0uc4g) that appears to have been replaced by another session.
- 18:31:37.966 [TaskEngine-pool-2864] DEBUG org.jivesoftware.openfire.SessionManager - Detached session ‘service.com/81nqao7706’ (81nqao7706) has been detached for longer than PT3S and will be cleaned up.
- 18:31:37.967 [TaskEngine-pool-2864] WARN org.jivesoftware.openfire.SessionManager - Not removing detached session ‘service.com/81nqao7706’ (81nqao7706) that appears to have been replaced by another session.
- 18:31:37.967 [TaskEngine-pool-2864] DEBUG org.jivesoftware.openfire.SessionManager - Detached session ‘userthree@service.com/mobile’ (am00w1099r) has been detached for longer than PT3S and will be cleaned up.
- 18:31:37.983 [TaskEngine-pool-2864] DEBUG org.jivesoftware.openfire.SessionManager - Detached session ‘userfour@service.com/mobile’ (9wz90343a4) has been detached for longer than PT3S and will be cleaned up.
- 18:31:38.006 [TaskEngine-pool-2864] DEBUG org.jivesoftware.openfire.SessionManager - Detached session ‘userfive@service.com/mobile’ (2pjh2a3xtu) has been detached for longer than PT3S and will be cleaned up.
- 18:31:38.026 [TaskEngine-pool-2864] DEBUG org.jivesoftware.openfire.SessionManager - Detached session ‘usersix@service.com/mobile’ (98hem6gyld) has been detached for longer than PT3S and will be cleaned up.
It is as if something is mangling/screwing-up the session. The log lines above come from here: https://github.com/igniterealtime/Openfire/blob/ede343d2ca453a2920935ccabe6a4a58fcc3eb77/xmppserver/src/main/java/org/jivesoftware/openfire/SessionManager.java (lines 1727 and 1753).
We have tried to add an if statement to fix the “address” in the session so that it can be deleted:
if (!session.getAddress().toString().contains("@")) {
Log.debug("Mangled session "+ session.toString() + " Address: "+ session.getAddress());
JID newJID = new JID(session.getAddress().getNode() + "@" +
session.getAddress().getDomain() + "/" +
session.getAddress().getResource());
session.setAddress(newJID);
Log.debug("Fixed Mangled session Address: "+ session.getAddress() + " Stream:" + session.getStreamID() + "Servername:" + session.getServerName());
}
but this did not work. we got back NULL for address:
22:54:46.063 [TaskEngine-pool-67] DEBUG org.jivesoftware.openfire.SessionManager - Mangled session LocalClientSession{address=service.com/515mvh4ttf, streamID=515mvh4ttf, status=1 (connected), isSecure=false, isDetached=true, serverName=‘service.com’, isInitialized=false, hasAuthToken=true, peer address=’(not available)’, presence=’
22:54:46.063 [TaskEngine-pool-67] DEBUG org.jivesoftware.openfire.SessionManager - Fixed Mangled session Address: null@service.com/515mvh4ttf Stream:515mvh4ttfServername:service.com
22:54:46.065 [TaskEngine-pool-67] WARN org.jivesoftware.openfire.SessionManager - Not removing detached session ‘null@service.com/515mvh4ttf’ (515mvh4ttf) that appears to have been replaced by another session.
We tried this hack because while we were seeing the correct name and resource in the openfire admin gui (under Sessions), despite the session being in Client IP = “Invalid session/connection”. We looked at
Openfire-4.5.1/xmppserver/src/main/webapp/session-row.jspf and noticed that
<% String name = sess.getAddress().getNode(); %>
<%= StringUtils.escapeHTMLTags(sess.getAddress().getResource()) %>
so we thought the data in the session object may still be correct. But almost feels like there are two different session objects, one for the admin console and one that is broken in the back-end.
Here are our two questions:
- What could be mangaling the session so that it produced a broken JID as you saw in log lines above?
- In the cleanup code mentioned above (or somewhere else) how can we remove these sessions without a restart?
Any help would be appreciated.
Thank you.
DT
FYI: service.com is fictitious for our domain name. Also userone … usersix are fake to protect our user names.
be removed correctly. We got JSP file shows