Stack Manager Persistent Scripts - What is the Pool?


In the Stack Manager you can set scripts to run persistently for a domain (like a chat script)… at this URL…


I set up with an instance of 1 to stop repeats for anyone already running the same chat scrip in their Interface setup (I assume).

But what is the “Pool” and can it be left blank for a domain? I tried it blank and the script is nor started when logging into the domain with the Interface… and ditto when I put in a pool name like “Test”. Is there a required Pool name to make persistent scripts for a domain work?


It will be a way for you to run multiple machines on the same stack.
See also throwing multiple computers at shared workload…

I have not yet experimented with this, but I must assume this is a way for you to tie machines into running 1 Domain across numerous computers.

So, if you have a Stack Manager running your Domain, try installing the stack manager on an additional machine, set the “POOL” to the same hash, and see if you get better performance when visiting your domain from a third computer.


Walk before you can run…

At present the selected Persistent Script with no pool, or with a pool called “Test” does NOT start up when the nterface us used.

Is it working for others?


@Ai_Austin That chat script is written to be run on users’ machines; unless I’m mistaken, it won’t work running it on the domain. I think @Twa_Hinkle has a domain script that loads a chat script for users when they visit a domain if they don’t already have it running. (I seem to recall seeing mention of it in a forum thread or two.)


Ah, I see, that was not clear, I thought it started up the script in each users Interface. Got it now. I will remove the wrong domain chat.js script from my domain settings and replace it in my interface.

As documented elsewhere, and not understood by everyone of course, this does not give us the essential property that everyone KNOWS that the SAME Chat/IM system is running ALWAYS and can count on it as voice backup, to assist in setup and (the VERY commonplace) voice troubleshooting, feedback issues (always by the person does not know, as they don’t hear their own feedback typically) and to ability to exchange info unsuitable for voice.