Session are not closing

Openfire Openfire Support
21

Christian Michallek wrote:

…snipped…

If you set a RessourceID manually, this problem does not occur and pidgin/openfire works normal.

Good observation!

I can report this same behavior.

One of my users has Pidgin set to generate a resource id.

The other user has Pidgin at home (VPN) and the office. The home resource id was autogenerated and the office resource id is set statically. The ghost sessions only appeared for the autogen resource id.

And my Pidgin instance has a static resource id, which explains why I wasn’t affected.

22

For anybody reproducing this, could you check your openfire logs and see if you see any recurring errors logged? Perhaps there is a cascading of failures going on?

23

We are running a whatsapp like setup, Openfire 3.9.3 (Always kick old connections). Clients use aSmack version 4. Everytime a connection is terminated or a connection doesnt work as expected, the client reconnects, this can occur very fast multiple times for the same client. The client uses a fixed resource to login. Due to ghost sessions/memory leak even though the old connections are kicked (or not), a session remains forcing the system into an infinite loop of login and logouts.

2014.08.11 06:44:44 org.jivesoftware.openfire.handler.IQBindHandler - Error during resource binding. Session not found in [84847dab, aa304566, 31e9c8ec, 1e3af0f3, 2a91e7e, f5cf99ef, 66ddf001, 3e3ce8e, 41b2d591, b64b6b13] for key xxxxxx@xxxx.xxxx.com/smack9

2014.08.11 06:45:13 org.jivesoftware.openfire.nio.ConnectionHandler - Closing connection due to error while processing message:

java.lang.NullPointerException

at org.jivesoftware.openfire.IQRouter.route(IQRouter.java:115)

at org.jivesoftware.openfire.spi.PacketRouterImpl.route(PacketRouterImpl.java:76)

at org.jivesoftware.openfire.net.StanzaHandler.processIQ(StanzaHandler.java:330)

at org.jivesoftware.openfire.net.ClientStanzaHandler.processIQ(ClientStanzaHandler .java:93)

at org.jivesoftware.openfire.net.StanzaHandler.process(StanzaHandler.java:295)

at org.jivesoftware.openfire.net.StanzaHandler.process(StanzaHandler.java:187)

at org.jivesoftware.openfire.nio.ConnectionHandler.messageReceived(ConnectionHandl er.java:181)

at org.apache.mina.common.support.AbstractIoFilterChain$TailFilter.messageReceived (AbstractIoFilterChain.java:570)

at org.apache.mina.common.support.AbstractIoFilterChain.callNextMessageReceived(Ab stractIoFilterChain.java:299)

at org.apache.mina.common.support.AbstractIoFilterChain.access$1100(AbstractIoFilt erChain.java:53)

at org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl$1.messageReceive d(AbstractIoFilterChain.java:648)

at org.apache.mina.common.IoFilterAdapter.messageReceived(IoFilterAdapter.java:80)

at org.apache.mina.common.support.AbstractIoFilterChain.callNextMessageReceived(Ab stractIoFilterChain.java:299)

at org.apache.mina.common.support.AbstractIoFilterChain.access$1100(AbstractIoFilt erChain.java:53)

at org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl$1.messageReceive d(AbstractIoFilterChain.java:648)

at org.apache.mina.filter.codec.support.SimpleProtocolDecoderOutput.flush(SimplePr otocolDecoderOutput.java:58)

at org.apache.mina.filter.codec.ProtocolCodecFilter.messageReceived(ProtocolCodecF ilter.java:185)

at org.apache.mina.common.support.AbstractIoFilterChain.callNextMessageReceived(Ab stractIoFilterChain.java:299)

at org.apache.mina.common.support.AbstractIoFilterChain.access$1100(AbstractIoFilt erChain.java:53)

at org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl$1.messageReceive d(AbstractIoFilterChain.java:648)

at org.apache.mina.filter.executor.ExecutorFilter.processEvent(ExecutorFilter.java :239)

at org.apache.mina.filter.executor.ExecutorFilter$ProcessEventsRunnable.run(Execut orFilter.java:283)

at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)

at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)

at org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:51)

at java.lang.Thread.run(Thread.java:744)

If you notice, the error at IQRouter at line 115,

else if (session == null || session.getStatus() == Session.STATUS_AUTHENTICATED || (
isLocalServer(to) && (
“jabber:iq:auth”.equals(packet.getChildElement().getNamespaceURI()) ||
“jabber:iq:register”
.equals(packet.getChildElement().getNamespaceURI()) ||
“urn:ietf:params:xml:ns:xmpp-bind”
.equals(packet.getChildElement().getNamespaceURI())))) {
handle(packet);
}

the session is null for the check in the code. But in the first place, if the session was null how did the message even reach that check…?? It means that the message probably came in through a live session, but in the condition is checking against a ghost session.

Looking at both the errors shown above (i dont know if both of these are related), it is certain that ghost sessions are being generated. If, so these sessions are not visible from the console either.

24

I run Openfire 3.9.3 on Linux (CentOS 6). I also use Pidgin 2.10.9 and had this same issue this morning. I found a way to remove the ghost sessions manually, one at a time, with the affected user’s Login and Pidgin.

Turns out that I appeared logged in with 2 other sessions and away for 12 days. When the “Sessions” list on the server didn’t show these, I proceeded to troubleshoot. I then stumbled onto your post, and found that others were mentioning the Ghost Sessions being related to the auto generated Resource ID’s.

I found that if I modified my account in Pidgin to login with the Ghost Resource ID (grabbed from someone else using pidgin) I was able to then Logout of that Ghost session.

I had 2 ghost sessions so I did the following:

  1. I grabbed my Resource ID’s from another user’s Pidgin’s roster list (Spark does not show this information to my knowledge)

  2. In Pidgin went to “Accounts > Manage Accounts” and unchecked the “Enabled” checkbox next to my Openfire account

  3. Clicked “Modify” on the Openfire account

  4. Placed the Resource ID (8e7614f9) into the Resource field and saved

  5. Reenable the account with the “Enable” checkbox

  6. Unchecked the “Enable” checkbox next to my Openfire account

The ghost session was now gone. I had to do this again for another autogenerated resource ID, and then I was completely logged out without having to restart the Openfire server.

I then left the Resource ID as something manual, but it seems that there’s another issue looming over this on a page that is linked to this issue.

25

How do you do clean up?