With a fresh installation of Wildfire Server, I am finding that clients are disconnected every 30 minutes, give or take a minute or two.
I’'ve found the ‘‘don’‘t disconnect idle sessions’’ option in the admin console, but it looks to me as if this relates only to Server-Server connections, which I have disabled anyway. In any case, changing this option made no difference.
Is this normal behaviour for the server to kick clients after 30 minutes idle, or is it me, the clients (Gaim) or something else? If it’'s the server doing it, am I missing the option to turn it off?
We’‘re having this problem too, and it seems to have cropped up after upgrading to Wildfire from Jive Messenger. Anyone know what’'s changed to cause this, or where we can turn it off?
On our end, yes, it only happens when they’‘re idle for 30 minutes. If the clients are set to reconnect automatically, they’'ll do so, and then get booted out 30 minutes later.
Note that some clients (Gaim, for one) doesn’‘t count as idle if your system[/i] isn’‘t idle, even if you’‘re sending messages. So I don’‘t get disconnected as long as I’'m at my computer working.
Yes, same here, only if the connection is idle for 30 mins. Note it is the connection, not the status as reported by the client - all these test Gaim’'s are set not to report idle status at all.
One of my coworkers has Trillian idle for more than two hours. He is working on his computer, but Trillian reports a connected period of over two hours. To force a reconnect, we pulled his ethernet out of the socket, waited for Trillian to disconnect. After that, we replugged the ethernet cable, Trillian reconnected automatically, and reported a connected period of one minute.
So, I guess we’‘re able to keep online for at least two hours, and it’‘s probable that we didn’'t have automatic reconnects in that time (since those would reset the ‘‘online-since’’ timer).
Update:
Our setup: Wildfire from SVN (pulled it a few hours ago), running on Ubuntu 5.10. We’'re using a Postgresql 8.0 database (on another machine). I used ‘‘ant release’’ and ran the output of that.
Hrm… I guess that indicates the problem is specific to certain clients? That’‘s unfortunate, because we have a large Gaim install base here, and that won’‘t change until Spark’'s released for Linux.
In any case, we weren’‘t having this problem before the Wildfire upgrade, so it still seems like this is something that’'s changed on the server side which brings out this client behavior.
We’‘ve got two 1.5 clients exhibiting the problem. Also, I just discovered that it happens even when I’'m active on my computer, as long as Gaim itself is idle, contrary to my previous comment.
I just connected through Gaim (1.5) and disconnected all other protocols (to make sure I wouldn’'t be forced to respond to anyone using those). I disabled autologin for now. Lets see what happens.
And indeed, after 30 minutes (maybe 29) the gaim connection crashes with a ‘‘read error.’’ There doesn’‘t seem to be anything in the logs (but I just noticed my server time is off, that makes it a little hard to debug). Gaim doesn’‘t include anything in it’'s system log either.
So, to sum things up:
We seem to have a Gaim-specific bug that is replicatable.
The bug did not exist before JiveMessenger was renamed to Wildfire.
The bug does exist in yesterdays code.
The bug causes a ‘‘read error in Gaim’’ (verified in Gaim 1.5.0) after approximately 30 minutes of inactivity.
If I look at the debug code that Spark gives me, it’‘s possible to determine a client’‘s name and version by sending a stanza as defined by (historical) JEP-0092: Software Version. Could that be used to filter out known clients that don’'t support heartbeats, as a workaround?
Update:
It seems a messier solution every time I think of it. :S Anyone any other suggestions?
I have done a little digging around in the source - apologies if this is totally wrong, but I am new here and not on my dev machine, so it was the trusty Windows Search Puppy in conjunction with Notepad.
Anyway, it looks to me like if you set the system property “xmpp.client.idle” to “-1” using the admin console it will disable the client timeouts. I haven’‘t read the docs, but it looks to me from the code like if you change this property, it won’'t take effect until you restart the server, so I did.
Yeah, that’'ll work for me, I have a low number of clients that are always on.
Your ‘‘reverse-heartbeat’’ workaround idea using SoftwareVersion sounds like a better way forward though. On the other hand, maybe Gaim 2.0 does heartbeats, I haven’‘t looked at it yet. If that was the case, I’'d probably let 1.5 clients get disconnected regularly as an incentive to upgrade!
