SIPp千路压测报TransactionAlreadyExistsException异常处理方法

注意：该异常触发和CallId全局唯一没有必然绑定关系，jain-sip内部事务的唯一索引是「CallId + From Tag + To Tag + Via头branch值 + 请求方法」的组合值，1000路压测规模下千分之1~1.5的失败率，基本是事务键碰撞、事务清理滞后、重复提交三类原因导致，按以下步骤排查即可：

排查步骤 #

• 先比对异常请求的全量事务标识字段：把抛出异常的失败呼叫对应原始SIP报文全量导出，不要只校验CallId，重点核对Via头的branch字段、From头tag、To头tag、CSeq序号这几个值。高并发场景下如果SIPp侧的branch值随机位长度不足，很容易出现哈希碰撞——SIPp默认branch是固定前缀z9hG4bK加7位随机字符，1000路并发下的随机碰撞概率正好在千分级，和你当前的失败比例完全吻合。
• 校验SIP栈事务生命周期配置：检查jain-sip配置中的T1、T2、事务最大存活时长参数。如果配置的事务超时等待时间过长，1000路并发下事务表容量被占满后，已结束、超时的旧事务还没被异步清理，同索引的新请求进来就会触发异常。同时排查压测过程中是否存在UDP丢包、响应超时：如果某路INVITE请求没收到最终响应，事务会一直存活到超时窗口，这时候重传的请求进来就会被判定为重复事务。
• 排查应用层重复提交逻辑：检查基于jain-sip开发的业务代码，高并发场景下是否存在多线程同时操作同一个SipProvider实例、同一个请求对象被重复调用sendRequest()的情况。比如业务层自定义超时重传逻辑时没有加事务存在校验，重复提交的请求哪怕是新生成的报文，只要复用了同一个请求对象或者事务索引相同，就会抛错。
• 核对SIPp压测脚本配置：确认SIPp使用的传输层协议（-t参数）和服务端一致，如果用UDP传输，检查SIPp是否开启了默认自动重传，重传报文如果和服务端已接收请求的间隔小于栈的事务判定窗口，也会被识别为重复事务。

处理方案 #

• 解决事务标识碰撞问题：修改SIPp脚本的字段生成规则，把branch、from tag、to tag的随机位长度提升到12位以上，不要用短随机串或简单递增序列；如果是自行构造SIP报文的逻辑，确保branch值严格符合RFC3261规范，随机熵足够，避免低概率碰撞。
• 调优jain-sip配置适配高并发场景：
  • 将事务表初始容量调整为压测最大并发路数的1.5倍以上，避免动态扩容带来的性能波动
  • 适当缩短无响应事务的超时时间，UDP场景下可将INVITE事务超时从默认32s调整到8~10s，非INVITE事务超时调整到4s，加快失效事务的清理速度
  • 开启栈内置的泄漏事务自动清理开关，避免异常中断的事务长期占用事务表槽位
• 修复业务层并发逻辑缺陷：所有创建客户端/服务端事务的逻辑，加前置存在校验，调用getNewClientTransaction()/getNewServerTransaction()前先查询对应索引的事务是否已存在，存在则直接复用而非新建；多线程提交请求的场景给SipProvider的发送操作加轻量锁，避免同一个请求对象被多线程重复提交。
• 压测采用阶梯升压策略：1000路规模不要瞬时打满流量，按200路/步的阶梯逐步提升并发，让SIP栈的线程池、事务表先预热到稳定状态，避免瞬时流量洪峰下事务创建、清理速度不匹配导致的假冲突。

内容的提问来源于stack exchange，提问作者DeadPool