powered by Jive Software

Client idle timeout not working

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…

Hey Stealth,

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…


as you may use a proxy server for all clients to access the internet you could configure “ www.jivesoftware.com” in /etc/hosts file of your proxy - this will of course block access to the page for normal users but setting up a webserver on the proxy which handles requests for http://www.jivesoftware.com:9090/plugins/enterprise/getspark?client=spark_2_5_1_ beta1.exe etc. could help a lot.


Hey Guus,

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?


– Gato

I experienced the same type of problems using Connection Manager 3.3.0

In ClientConnectionHandler.java idle detection is done as follow:

session.setIdleTime(IdleStatus.BOTH_IDLE, idleTime);

which cause the session to be idled only if nothing is written AND nothing is


I’'ve replaced this line with:

session.setIdleTime(IdleStatus.READER_IDLE, idleTime);

Everything is working fine for me now.

I guess OpenFire needs the same patch.

Just want to know if my latest remark solve the issue for others too.

Will it be possible to see this included in openfire?

Has someone my remark and plan to integrate it?


I did create JM-1066 so one can track this issue in the issue tracker.


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.

I am having issues with it still… : /