freeswitch的任务引擎问题与解决方案
概述
freeswitch核心框架中有一个定时任务系统task，在开发过程中用来做一些延时操作和异步操作很方便。
我们在VOIP的呼叫流程中，经常会有一些对实时性要求没那么高的操作，或者会有阻塞流程的操作，我们都可以开启一个定时任务子流程，来达到延时和异步的目标。
但是在实际的生产应用中，该task模块在任务高并发的情况下发生了一些问题，通过压力测试可以重现。
问题现象。
1，task的group和desc为空的问题，并有极小概率造成coredump。
2，task.runtime错误的问题，导致任务无法执行。
环境
centos：CentOS release 7.0 (Final)或以上版本
freeswitch：v1.6.20
GCC：4.8.5
task的group和desc为空的问题
在对fs压力测试的同时，使用“show tasks”命令查询当前的任务队列。
其中，47号任务，2184号任务的task_group为空，24586号任务的task_desc和task_group均为空。
freeswitch@as137> show tasks
task_id,task_desc,task_group,task_runtime,task_sql_manager,hostname
1,heartbeat,core,1681351218,0,localhost.localdomain
2,check_ip,core,1681351258,0,localhost.localdomain
3,limit_hash_cleanup,mod_hash,1681351740,0,localhost.localdomain
4,task_keep_redis_alive,task_keep_redis_alive,1681351200,0,localhost.localdomain
5,as_common_city_forbidden_update_task,as_common_city_forbidden_update_task,1681351440,0,localhost.localdomain
6,update_cops_task,update_cops_task,1681351448,0,localhost.localdomain
36,task_report_event_hangup,task_report_event_hangup,1681350862,0,localhost.localdomain
47,task_report_event_hangup,,1681350862,0,localhost.localdomain
61,task_report_event_hangup,task_report_event_hangup,1681350862,0,localhost.localdomain
2077,task_report_event_hangup,task_report_event_hangup,1681350872,0,localhost.localdomain
2184,task_report_event_hangup,,1681350872,0,localhost.localdomain
24586,,,1681350985,0,localhost.localdomain
24647,task_report_event_hangup,task_report_event_hangup,1681350985,0,localhost.localdomain
问题分析
switch_scheduler_add_task函数中，主要逻辑分两步。
第一步，将task加入执行链表。该部分逻辑有加锁
第二步，将task信息通过event事件转发db模块保存。该部分没有加锁。
task_thread_loop函数中，主要逻辑分两步。
第一步，遍历task链表，并执行task。该部分有加解锁。
第二步，遍历task链表，删除已执行的task并清理内存。该部分有加解锁。
在多线程高并发场景下，一个任务在add_task的步骤二晚于task_thread_loop的步骤二执行时，就会发生task_desc和task_group的内存已被清理，event转发db的信息中字段为空的情况。
在极端情况下，task_desc和task_group的内存被重写，event事件在使用task_group的内存时会发生coredump的严重问题。
解决方案
在有switch_event_create函数调用和赋值的过程中，需要加锁，防止task_desc和task_group的内存已被清理。
该问题在1.10.7版本已修复。
task.runtime错误的问题
在对fs压力测试的同时，使用“show tasks”命令查询当前的任务队列。
其中，17022231号和19514678号任务的task_runtime时间为3363320919，换算为UTC时间为“2076-07-30 15:48:39”，这还执行个毛线。
freeswitch@as137> show tasks
task_id,task_desc,task_group,task_runtime,task_sql_manager,hostname
1,heartbeat,core,1681693601,0,localhost.localdomain
2,check_ip,core,1681693641,0,localhost.localdomain
3,limit_hash_cleanup,mod_hash,1681694183,0,localhost.localdomain
4,task_keep_redis_alive,task_keep_redis_alive,1681693584,0,localhost.localdomain
5,as_common_city_forbidden_update_task,as_common_city_forbidden_update_task,1681693584,0,localhost.localdomain
6,update_cops_task,update_cops_task,1681693592,0,localhost.localdomain
17022231,task_report_event_hangup,task_report_event_hangup,3363320919,0,localhost.localdomain
19514678,task_report_event_hangup,task_report_event_hangup,3363352225,0,localhost.localdomain
22295783,task_report_event_hangup,task_report_event_hangup,1681693583,0,localhost.localdomain
问题分析
从数值上分析，3363320919大概是1681693583的两倍，猜测是switch_scheduler_add_task函数第一个参数task_runtime的处理有问题。代码如下。
if (task_runtime < now) {
container->task.repeat = (uint32_t)task_runtime;
task_runtime += now;
}
临界情况下，我们希望任务马上执行，task_runtime传参为当前时间1681693583.999999，但是函数内部now的值取得1681693584.000000，这样task.task_runtime就会变成3363320919这样一个极端值。
解决方案
switch_scheduler_add_task，第一个参数task_runtime的填法，在回调函数中需要做出对应的修改。
1，不删除的定时重复执行的任务。
传入task_runtime = 60
task.repeat =60
task.runtime = 60 + switch_epoch_time_now(NULL)
2，需要马上执行的不需要重复执行的任务。
传入task_runtime = 0
task.repeat = 0
task.runtime = 0 + switch_epoch_time_now(NULL)
3，需要延时执行的不需要重复执行的任务。
传入task_runtime = switch_epoch_time_now(NULL) + 10
task.repeat = 0
task.runtime = switch_epoch_time_now(NULL) + 10
总结
freeswitch的新版本修复了很多问题，应尽量使用最新版本。
在高并发场景下的压力测试是必须要做的。
空空如常
求真得真
