We seem to have a problem on two different domains with idle connections. They are not closed after the time configured in xmpp.client.idle.
xmpp.client.idle is currently configured at 90000.
I’'ve tested our setup (one is 3.2.2, the other one is 3.2.3) twice: The first time, I used the JUnit testcase that I attached to this thread. The second time, I used a normal client, connected to the server and pulled out my network cable from the computer.
The server did not detect the idle sessions after 90 seconds, 2 minutes (which was the old default value) or 6 minutes (which is a new default).
I had a similar thing happen to me today, but on a NIGHTMARE SCALE!!! I talked to ddman in group chat about it not disconnecting clients correctly during an update of the client, so when the client went to log in right after spark got upated, it said the account was already logged in, but after a couple of minutes they could again login… but today I had over 100 trouble tickets blast me today after I decided to allow an update all the clients… after the update they could not log in as usual, but today even after waiting for long amounts of time they still could NOT log in… I had to go into admin console and manually terminate their connections under the sessions tab…
that really sucks. If your problem is caused by my problem, there’'s a good chance that adjusting the resource settings in the Openfire webadmin panel would have fixed your problem though.
I would have looked up the exact setting, but somehow, my network is giving me trouble at the moment. In any case, there’'s a ‘‘resource setting’’ something admin panel, that lets you configure what to do with a user that log in with the same resource simultaneously. One of the settings is ‘‘kick the first resource’’. Try that the next time. It might prevent a lot of trouble.
Strangely enough I had “Never kick - If there is a resource conflict, don’'t allow the new resource to log in.” set in the Admin console… Which is how I want it, the problem I am having is ONLY during an auto upgrade of spark, the client cannot log right back in for a few minutes until their session times out, but yesterday, it seemed like a lot of them were never going to time out…Finally I just shut the whole system down today, as I am way to frustrated at what is happening about the spark manager plugin not being updated to support the new openfire naming system… It is killing me over here with the thought of having 8.9 gigs of bandwith at risk with our ISP for 1 single day of 320 clients trying to get the 28 mb update to spark 2.5.1, when I could be hosting it locally with the old spark manager… or I could just turn into fred flintstone and stay operating in the past with the old versions forever, and lose the benefits of new versions of openfire…
Sorry just venting a little…
Openfire and Spark is a great combo… I hope you guys all keep up the great work you are all doing…
Could you get a thread dump of the JVM to see if we are again having blocked threads trying to close idle connections? BTW, any relevant errors in the log files?
Strangely enough, the problem disappeared for me (probably after a restart of the domain). I am unable to reproduce the problem, even by manually unplugging my running computer from the network.