3CSCallFlow.log messages refer to a deleted Call Flow, not the current CPS.

EscondidoAdmin

Premier Customer
Basic Certified
Joined
Apr 9, 2024
Messages
91
Reaction score
19
In the 3CXCallFlow.log file, I see periodic entries that appear to be related to text to speech cache cleanup. Fair enough that this needs to happen, but what's odd is that an old CPS associated with a number that has a different CPS assigned to it keeps showing up.

For example:
- Several days ago, in v18u9a before our update to v20u3, I created a CallFlow to test some Record and Email blocks. I named the Call Flow "testvm_access" and assigned it to x6262.
- Today, post v20u3 upgrade, I tried to assign a new CPS to 6262 but found I had already used that number with "testvm_access."
- So, I deleted the CPS "testvm_access" on 6262. I confirmed that no CPS was found searching on 6262 or testvm.
- I then assigned a new CPS "fire_admin_test" on 6262.
- This afternoon, I've been sending multiple calls into the "fire_admin_test" CPS on 6262 as part of some troubleshooting.

Question: Why do I see 3CXCallFlow.log file entries that sure look to me like the 3CX thinks there's still a CPS running on 6262 named "testvm_access" and not "fire_admin_test" like what's actually assigned? I don't see any cache cleanup messages referencing "fire_admin_test." I do see cache cleanup messages for other CPS with the correct names.

Example from the log that I just pulled:
2024/12/10 16:55:59.557|0024|Trac| CallPair._6262_51.Main.60685.[C:12326.2]-From script: testvm_access - TextToSpeechProjectCacheManager - Starting cache cleanup cycle.
2024/12/10 16:55:59.557|0024|Trac| CallPair._6262_51.Main.60685.[C:12326.2]-From script: testvm_access - TextToSpeechProjectCacheManager - Finished cache cleanup cycle.
 
Looks like there is a background thread that is still running that cleanup task. I think this is expected as the script doesn't receive any invocation when it is removed, and the code will remain loaded, as it can't be unloaded while the process is running. This will be solved when you restart the 3CX Call Flow Server service. Please schedule this to be done after hours, as there are many 3CX entities now that rely in this service, and you might drop existing calls if you restart it during office hours.
 
Looks like there is a background thread that is still running that cleanup task. I think this is expected as the script doesn't receive any invocation when it is removed, and the code will remain loaded, as it can't be unloaded while the process is running. This will be solved when you restart the 3CX Call Flow Server service. Please schedule this to be done after hours, as there are many 3CX entities now that rely in this service, and you might drop existing calls if you restart it during office hours.

Thanks, I was thinking that might be the case. Definitely an after-hours reboot... :)
 

Latest Posts

Forum statistics

Threads
111,962
Messages
589,978
Members
164,864
Latest member
SCarpenter@fifthavenue-la