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的新版本修复了很多问题，应尽量使用最新版本。

在高并发场景下的压力测试是必须要做的。

空空如常

求真得真