Ghost sessions in the servers when using Pidgin client

I read a post that talked about this topic. https://issues.igniterealtime.org/browse/OF-829 Apparently it was fixed in version 4.0.2, I currently use 4.2.2 and I have the same problem. I have a cluster with 3 server using hazelcast, all mounted on a LAN. For example right now, as the image shows, the same user has several ghost sessions and is using Pidgin. What is the problem with the Pidgin and openfire, this seems to be coming from a while ago.

I saw this issue with another client. I disabled stream management and restarted openfire. That seemed to have resolved the issue for me. set the system property stream.management.active to false

Thanks, a fast answer allways is grateful. I will apply your recommendation, but what impact would it have on my server to set the value of stream.management.active to false?

no, you shouldn’t see any impact.

Well, today in the morning sorprise:

This user is using pidgin, in my server config I have allowed more than one connection per user, if I only allow one connection per user it will be possible to solve the problem?

I can’t check now, but i don’t remember a setting allowing one connection.

I found a clue that may be the cause of crashes. I have a cluster with several distant servers some hundreds of kilometers away from connections that are not so fast. Remove from the cluster a server that was for a connection of 256kb/s and when giving F5 in the window of the active sessions all the ghost sessions disappeared. I understand that the clustering of XMPP in WAN networks should take a different treatment than it is in LANs, but Hazelcast send gigas for day and I can not permit this high traffic, so I think all my servers end up pointing to the capital that is where I am. I will not manage more than 10000 users but if I wanted to provide high availability in the provinces inside the country in case one day the connection with me would fall.

The problem was my Mysql cluster configuration and my HAproxy to manage the Mysql cluster.

thanks for coming back and reporting your findings!