i have search in all threads and google for my problem, but don´t find useful answers.
We have a actual openfire enviroment with spark on an IIS.
Some users never shutdown her client, they are appropriate for openfire only idle. The spark clients never disconnect, although I have put this test-wise on 5 minutes.
However, I urgently need the possibility that they distinguish after ~8 hours idle from the server. Is there any possibility? Also i (as administrator in openfire) cant disconnect clients from server, they connect automatic
The setting which should disconnect idle users will only disconnect clients which don’t send keep alive packets. As Spark does send those all the time it is not disconnected. I don’t think you will find a reliable way to disconnect such users.
Thank you for your answer. Allright, know i understand this setting.
Could i change the option, that Spark unlimited try to connect to openfireserver?
I thought i could set up a task, which quit openfire-service from 01:00 - 06:00 am, and then i start the service. But i think spark try always to connect.
Spark doesn’t have an option to set number of tries. Although i remember someone reporting that Spark stops reconnecting after many hours. I don’t leave Spark running for so long so can’t confirm this.
We are of use in our company Spark as an attendance list for employees. In addition we transmit the status to a web page. If users do not switch off the client, they are there persistently. I am accustomed by other clients that they disconnect from server after failed connecting attempt not further try to announce.
Well, Openfire and Spark are not designed to be used as the tool you need. This is an Instant Messaging platform and usually it is desired for it to be as persistently connected as possible (to be able to contact a person). As i have mentioned, Spark doesn’t have an option to set a limit of tries (like some other clients do). Anyone is welcome to provide a patch to add such setting to Spark.
Note that you can use any XMPP client with Openfire. If you do know of a client that has the behavior that you’re after, you could try to use that within your company. An alternative would be developing a custom plugin for Spark, specific to your company.
Another option would be to modify that webpage. Perhaps it can ignore people of which the latest presence change was longer than X hours ago, something like that.
With all solutions, I do wonder if you get what you want. Relating instant-messaging presence to building attendance is a loose coupling, at best. I don’t think you’ll be able to get a bulletproof solution.
For our purposes openfire and spark is exactly the right one. We need only one global information whether somebody is general available(in addition to the communication). I think an own development is a good way.
