We’re using Spark 2.5.8 in a linux thin-client environment. The server is LTSP v5 on Edubuntu 8.10 Hardy. Our Asterisk server is 1.4 on CentOS v4.7. Openfire server is 3.6.3 on CentOS v4.7.
For the most part phone statuses are working properly. For Windows PC users it’s working flawlessly. However, for our thin client users, the phone statuses will periodically get “stuck” in a state of “On Phone”. We’ve noticed that if they’re really on the phone, the Spark status will be “On the phone”. But, sometimes when they hang up, the Spark status will stay in “On Phone”. Changing the status to “Available” updates or fixes things.
The problem with this is that on our phone system, if their status is “On the phone” or simply not “Available”, then their phone won’t ring on the next incoming queue call, thus causing us to lose or not pick up calls.
The phone system support folks we use (www.bicomsystems.com) can’t see any issues on their end - I assume all of this is part of Astmanproxy(?). The one other thing that I think may be an issue is the fact these workstations are thin clients running from the linux server (GDM). When we run Spark on these workstations, they all run from /opt/Spark/Spark. The JRE is set to use the same for all clients.
We have the ability to actually run Spark as a local application, meaning the Spark and JRE programs will be loaded into local memory on the thin client workstation and run from there, thus using local resources instead of those from the server. We do this already for Mozilla Firefox and the Evince PDF viewer software.
My questions are could our issues with the phone statuses be somewhat related to the number of instances of Spark running on a linux terminal server? Upwards of 10-15 instances. If anyone has seen this before, or is running an LTSP environment also, are you running Spark and JRE from the server or utilizing local resources (localapps)?
-Mike Rathburn
Tech Dir
Step Up For Students