Genesys CTI User Forum
Genesys CTI User Forum => Genesys CTI Technical Discussion => Topic started by: tony on August 12, 2008, 02:17:20 PM
-
Here's a problem that I might share with a few others out there; Single Threaded Applications.
Aside from "confederation" (whatever that is!) is anyone aware of a way of utilizing the single threaded components (cfg, StatServer, IXN Server, TServer, etc.), in a multithreaded way? Duplicate the Application and App Name but use a different port....???
Also (for any Genesys PS people out there): does anyone know if Genesys plan to (re)build their single threaded applications as multithreaded applications in the future?
Tony
-
Hi Tony,
I do know a multi-site implementation where we used local config servers for the agent desktops to use instead of the main CS. Updates were a nightmare but this was before CS Proxy was available.
Pavel
-
You're right - I didn't mention CSProxy... They are in use but they are also single threaded and although read-only, still slow to respond. - and that only covers config, not the rest of the apps... :(
-
Hi, Tony,
while I am hoping that Genesys will move from ST to MT for their overall architecture, we are experimenting and getting rather good results with virtualization. I find config server and stat server to be rather slow as it is right now, no matter how much CPU or memory you have, so we went VMware way, which is a god-send when you have thousands of connections to config server. Until then, it felt like we were running on windows 3.1 before the pre-emptive tasking was even implemented. Now, it feels a bit better. But at the expense of having a rather complicated environment.
We are currently trying to get Genesys to run on Zen platform, but I think we might be pushing it a bit too hard, since IT IS NOT WORKING!!!! (I don't think Genesys was designed to run like that )
Best regards,
Vic
-
Thanks Vic - I only just found this, since there were so many posts/replies in the last few days... I hadn't considered virtualization but suspect you are right - a bit too complex for what could be just a "bit" better...
I've raised a ticket ("thorn") with Genesys about their plans to move to MT but I don't expect much by way of reply. It is a shame really since they like to throw lots of new toys in with the latest versions of their applications but still they insist on using a ST framework. It's got to the point where we may not be able to build in much more functionality because the framework just can't handle the messaging, no matter how much mem/cpu you can apply to it...
Tony
-
I remember discussions with Genesys where was stated not giving a dime for MT. Maybe for upcoming releases.
However, we solved it by using lots of urservers, statservers (each one for different things), separated components for outbound.
regards,
andre
-
...now they are telling me it is "dual threaded..." ????
-
Dual-threaded...?? ??? Oh well. I agree though, I wish that the main core components had better thread-handling. I've no idea what dual-threaded could possibly mean unless they are referring to the main thread for processing and additional worker thread for logging.
-
It is pretty unlikely that genesys will ever go multithreaded. Infact I had a ticket come back on Friday with the fact they dont even support multithreaded DESKTOPS that YOU write, let alone their own gear.
Its just too massive a job to multithread everything. Its not worth the risk or investment in rewriting. Realtime + Multithread = fail :(
Sorry, dont hold your breath on this or you will assuredly pass out.
-
@kowari: I'd be interested in knowing what was said, and what was the context of that ticket. Genesys probably wouldn't support any customer-written desktop any more than Microsoft would support any app written using the .NET framework.
I do agree with your assessment though that the task of multithreading core components would be a risky and huge undertaking that is very unlikely to happen in the near future.
-
Well... I was searching for same on Genesys site. This is what I found for some of their processes... TServers listed are for Avaya CM Tservers... Hope this helps
6.5 TServer is single-threaded (correct)
7.0 TServer is multi-threaded (correct)
7.0 TLibs/JTLibs are single-threaded (correct)
6.5 IVR Drivers are single-threaded (correct)
6.5 IVR Servers are single-threaded (correct)
7.0 IVR Drivers are multi-threaded (correct)
7.0 IVR Server are multi-threaded (correct)
-7.0 URS <<<<<<<<<<(single-threaded in terms of computation. Additional threads are auxiliary)
-7.0 WFM <<<<<<<<<<(single-threaded in terms of computation. Additional threads are auxiliary)
-7.0 ConfigServer <<<<<<<<<<(single-threaded in terms of computation. Additional threads are auxiliary)
-7.0 Message Server <<<<<<<<<<(single-threaded in terms of computation. Additional threads are auxiliary)
-7.0 SCS <<<<<<<<<<(single-threaded in terms of computation. Additional threads are auxiliary)
-7.0 LCA <<<<<<<<<<(single-threaded in terms of computation. Additional threads are auxiliary)
-7.0 StatServer <<<<<<<<<<(single-threaded in terms of computation. Additional threads are auxiliary)
In terms of what constitutes an "auxiliary" thread or task, the primary thread would carry out major tasks (Stat Server's primary thread would calculate stats, URS primary thread would route calls...) while lesser threads contribute to logging, creating libraries etcetera.
-S