Hello and sorry for being annoying. Just wanted to know if anyone has any lead on this.
Thanks.
jonathan, sorry, but i doubt this will be fixed soon. You should think about a workaround for your needs.
No worries, I know how it is with opensource projects. Opensource projecs are all the good will / effort people put in and I appreciate the product that is already available. I found a way to fix that xmpp.client.idle issue. It can be done by adding a timer bean and then closing idle connections. Haven't tried it out yet. Will post something for other users if I get it working.
Cheers.
Hi Jonathan,
Do you have a working solution to share?
thanks,
daryl
Hello Daryl, I got that issue fixed by implementing a timer bean which calls a servlet exposed via an openfire plugin every X seconds . It is not perfect but works . You will need to write a small plugin for openfire which checks the session of every user. ( i.e if currentmillis - lastactive > Y secs and exposes a servlet, close session).
Hope that helps.
It's weird, but after i have switched xmpp.idle to 60000 (1 minute) i'm now constantly seeing my Exodus disconnecting and reconnecting while i;m idle with it. Though i can reproduce it when i'm trying. Maybe it actually works, but not with every client, maybe Spark is not sending something or maybe it sends some heartbeats that emulate the activity. I will try to set xmpp.idle to -1 again and watch Exodus.
So, now with -1 value i dont get constant Exodus disconnects. It seems this option is some how working but not all the time and not with all clients.
well i dont really know who is assigned to fix that but i think we can't really depend on them to fix it. It has to be fixed by the community which is going to be tough...
I remember a thread that was discussing keepalives (http://www.igniterealtime.org/community/message/150011#150011). Could this have something to do with the issue?
This seems to be related to
Hi.
We did a test:
1. Set xmpp.client.idle to 30 seconds (30000) via web interface (Server Settings->Client Connections->Idle Connections Policy-> "Disconnect clients after they have been idle for 30s"
and "Send an XMPP Ping request to idle clients.", without restart of Openfire
2. Plugg off ethernet cable from one of clients (with status 'online' prior to unplug)
3. Wait for 30s after the client's session becomes idle/offline - didn't happen, session remains active
4. We've send some messages from another client to the unplugged client, we could see increasing 'sent' packets counter on 'Session details' for the unplugged client's session and the client still remained 'Online', also 'Session Last Active: ' date incremented every time we send messages to the unplugged client
5. After we plugged the ethernet cable back into the client's network card the client became offline for a moment, then again online, but did not receive any messages.
It seems, that ping messages are being properly sent to client with status set to idle (which for me is not the same as 'idle client'), but it is hard to believe, that xmpp.client.idle was meant to deal with 'idle status'.
We made our tests with OpenFire 3.7.1
Ryszard Lach, if possible, could you test subversion trunk version as well?
Hi.
Strange, but after a while, openfire begun to disconnect an idle (unreach.) client, exactly after 30 seconds. I didn't restart it. Is it possible, that configuration changes need some time to propagate? Maybe some caches? Maybe the fact that my openfire has run at 80% of available heap space?
To be sure I incresed max java heap size and restarted openfire, it still disconnects as I wish.
So, the only issue for me now is losing of offline messages during that 30s time:
http://community.igniterealtime.org/message/225504#225504
Cheers,
R.
Removing the 'fix version' for all unresolved issues that were scheduled for version 7.8.2. We're releasing this version today - the remaining issues should be rescheduled later.
Anybody on this ticket wish to comment on its current applicability to 3.8.0 ?
I think this ticket needs clarification. What exactly should this property do? Maybe it wasn't even designed to disconnect idle, yet connected, sessions which send keepalive packets. In this case it works fine. Yes, after setting or changing a setting one have to wait a little (a few minutes, but maybe 10 to be sure) for this setting to propagate on the server. In my testing it was working fine and closing disconnected sessions (network cable plugged off). So, i am willing to close this ticket as "Can't reproduce". Actually, as i mentioned before, i see no value in disconnecting idle, but connected clients. This will only create annoyance for the users, unless you have millions of them and want to make less load on the server by disconnecting everyone who has been away for a few minutes. In that case one should probably think of some Openfire or client modifications to handle this better.
@wroot This setting is only applied to newly established sessions on the server and will not propogate to existing sessions. My impression is that this problem was resolved in 3.8.1
Ah, i see, i was testing restarting the client. So my session was new for this setting. Not sure if it was fixed or always worked as intended. I had this setting set to 10 minutes for a few years (Exodus client was going mad with lower setting as it wasn't sending keepalives normally) and it worked. It just never disconnected idle client, which were still connected to the server (which the title of this ticket implies). "idle" not equal "lost connection to the server" in my opinion. But the property name implies it should affect idle clients or someone naming this option picked bad wording. Maybe it should be saying xmmp.lost.disconnect 
So what about closing with whatever reason (fixed or won't fix). I would tend to use latter one, as fixed will look like something was done about that, but in fact it works like it did.
Closing as per wroot's comment, can always reopen if necessary
"Not a bug" looks like a more appropriate resolution.