10-13-2014 06:22 PM - edited 03-14-2019 01:58 PM
Hi,
Regarding UCCX Max Number of Executed Steps* parameter, for default it have a value of 1000 steps, i have some questions regarding that:
How are steps counted on a Script if i call a subflow? Do the step count as a single step or count as many as the steps the subflow contains?
What is the maximum number for this parameter?
Regards,
Solved! Go to Solution.
10-14-2014 12:11 AM
++ By default the value is 1000. This parameter is purely a safe-guard to prevent poorly designed scripts from entering into infinite loops and consuming available resources. This parameter will only allow a set number of steps, so that if the script does enter a loop, UCCX can detect this and terminate the script.
++ UCCX engine has a limited set of memory available to execute scripts and process all the
steps for each and every call. The UCCX engine memory has nothing to do with the actual server RAM and its execution set is limited.
++ UCCX engine executes scripts, processes xml documents, processes prompts and calculates real time data, etc.The Maximum number of steps were put in place to make sure that the CCX Engine memory set
is not overflowed due to more steps present in UCCX scripts.
++ Basically, if a call takes too long to go through a script, you could deadlock a cti port or cause a continuous loop in the script itself which will cause your application subsystem to shutdown and UCCX engine to restart . There
are no other side affects to changing this value except that if it is increased it will take longer for UCCX to determine the script is in a loop and terminate the script. Cisco recommends that the max steps are set to 1000, to prevent an infinite loop, however the max steps could be set to as per the script desires.
++There is no recommended safe value. You can increase the number of steps, test it in a production or load environment and see if the server is running fine.Push it further and then test once again. You will need to make sure that increasing it doesn't cause performance issues due to other inadvertent script loops. It isn't likely to be an issue, but you should always proceed with caution when changing a system limit from the default.
10-14-2014 06:49 AM
Every step executed per task counts towards your maximum executed steps limit. So if the parent script calls a sub-flow every step that has been executed within that sub-flow will be counted by the task that initiated it.
It should be noted that there is not a real limit to the number of steps in a script, but a limit of steps that are executed when the script runs.
DJ
06-15-2016 10:43 PM
I know this is an older post, but I do know the answer, and, well, no one answered you yet.
The first thing you need to know is that the memory being discussed is called the Java Heap. It used to 256MB for a long time, but with 8.5(1)SU4ES02-15 (CSCuf79940) it became 512MB. I know right? The server has like 6GB of RAM, and the main process running EVERYTHING only gets 512MB? Crazy how this thing even works. But it does. And you can break it. That's called a heap overrun and then the system basically does a core dump and the Engine restarts.
Two ways to see the heap usage (and max value):
In RTMT you can use the following Performance Counter to track the heap usage. Note that I have two servers, hence the "a" and "b" designations. You may only have one.
In a Script, you can use the following code to get the heap values. Heck, you could use this as a decision on whether or not you offer more complex or memory intensive features to your callers. E.g., If heap is over 70% do not offer call back feature.
10-14-2014 12:11 AM
++ By default the value is 1000. This parameter is purely a safe-guard to prevent poorly designed scripts from entering into infinite loops and consuming available resources. This parameter will only allow a set number of steps, so that if the script does enter a loop, UCCX can detect this and terminate the script.
++ UCCX engine has a limited set of memory available to execute scripts and process all the
steps for each and every call. The UCCX engine memory has nothing to do with the actual server RAM and its execution set is limited.
++ UCCX engine executes scripts, processes xml documents, processes prompts and calculates real time data, etc.The Maximum number of steps were put in place to make sure that the CCX Engine memory set
is not overflowed due to more steps present in UCCX scripts.
++ Basically, if a call takes too long to go through a script, you could deadlock a cti port or cause a continuous loop in the script itself which will cause your application subsystem to shutdown and UCCX engine to restart . There
are no other side affects to changing this value except that if it is increased it will take longer for UCCX to determine the script is in a loop and terminate the script. Cisco recommends that the max steps are set to 1000, to prevent an infinite loop, however the max steps could be set to as per the script desires.
++There is no recommended safe value. You can increase the number of steps, test it in a production or load environment and see if the server is running fine.Push it further and then test once again. You will need to make sure that increasing it doesn't cause performance issues due to other inadvertent script loops. It isn't likely to be an issue, but you should always proceed with caution when changing a system limit from the default.
10-14-2014 05:34 AM
ok, Thank you very much, i have more clear the maximum steps now. but what about the way steps are counted in a subflow, do this steps counts as part of the script that call the subflow or is an independent count for the subflow?
Regards,
10-14-2014 06:49 AM
Every step executed per task counts towards your maximum executed steps limit. So if the parent script calls a sub-flow every step that has been executed within that sub-flow will be counted by the task that initiated it.
It should be noted that there is not a real limit to the number of steps in a script, but a limit of steps that are executed when the script runs.
DJ
01-16-2015 01:39 PM
Many thanks for the information. With that said, Is there a way to monitor in Real-Time the memory of the CCX Engine memory set so testing doesn't become a Trial-and-Error task?
06-15-2016 10:43 PM
I know this is an older post, but I do know the answer, and, well, no one answered you yet.
The first thing you need to know is that the memory being discussed is called the Java Heap. It used to 256MB for a long time, but with 8.5(1)SU4ES02-15 (CSCuf79940) it became 512MB. I know right? The server has like 6GB of RAM, and the main process running EVERYTHING only gets 512MB? Crazy how this thing even works. But it does. And you can break it. That's called a heap overrun and then the system basically does a core dump and the Engine restarts.
Two ways to see the heap usage (and max value):
In RTMT you can use the following Performance Counter to track the heap usage. Note that I have two servers, hence the "a" and "b" designations. You may only have one.
In a Script, you can use the following code to get the heap values. Heck, you could use this as a decision on whether or not you offer more complex or memory intensive features to your callers. E.g., If heap is over 70% do not offer call back feature.
08-28-2018 09:48 AM
Love the code there very useful. Question something I can do to retrieve number of steps that have been executed mid script?
08-26-2020 03:27 PM
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide