Genexus 16 U9报表并发请求偶发源数组长度不足错误咨询

报错信息 #

Source array was not long enough. Check srcIndex and length, and the array's lower bounds.   at GeneXus.Procedure.GxReportUtils.GetPrinter(Int32 outputType, String path, Stream reportOutputStream)
   at GeneXus.Procedure.GXProcedure.getPrinter()
   at GeneXus.Programs.rnuc006.executePrivate()
   at GeneXus.Programs.rnuc006.execute(SdtSDTDadosEmissao& aP0_SDTDadosEmissao, SdtSDTDadosEnvio& aP1_SDTDadosEnvio, Int16 aP2_indiceLote, Int16 aP3_indiceRPS, String aP4_Filename)
   at GeneXus.Programs.pnfs216.S121()
   at GeneXus.Programs.pnfs216.executePrivate()

根因分析 #

• 该报错是Genexus 16 U9 .NET 4.0生成器的已知并发缺陷：报表工具类GxReportUtils内部使用了非线程安全的静态数组做缓存，高并发场景下多个请求同时修改同一块数组内存，触发数组长度校验失败。
• 回收IIS应用池可临时恢复的原因是进程回收会清空内存中的静态缓存，重置数组状态，但并发量上来后问题会再次复现。
• 已实现的唯一文件名逻辑可排除文件锁导致的问题，问题完全出在Genexus运行时内部的线程安全缺陷。

解决方案 #

临时缓解方案（无需重新打包部署） #

• 调整IIS应用池回收规则：设置固定间隔回收（建议2小时一次），或者配置累计请求数阈值回收（比如累计处理1000次请求后自动回收），主动在并发冲突累积前清空异常缓存。
• 限制Web服务并发请求数：在IIS的ASP.NET请求限制配置中，将最大并发请求数调整为和服务器CPU核心数匹配的数值，避免短时间内大量请求同时涌入触发竞态条件。
• 给报表接口添加本地限流逻辑：用内存队列控制同时处理的报表请求数不超过CPU核心数的2倍，大幅降低并发冲突概率。

永久修复方案 #

• 优先升级Genexus版本：该并发缺陷已在Genexus 16 U11及后续补丁版本修复，升级后重新生成部署代码即可彻底解决问题。
• 若暂时无法升级版本，可修改rnuc006报表的调用逻辑：仅给报表执行的核心代码块加线程锁，强制同一时间只有一个请求进入Genexus报表工具类逻辑，避免并发修改静态数组。注意控制锁的粒度，不要锁整个请求处理流程，避免影响接口吞吐量。
• 架构优化替代方案：将报表生成逻辑拆分到独立的后台进程处理，用异步任务队列调度报表生成请求，和Web服务请求进程完全隔离，从架构层面避免共用运行时静态缓存带来的并发冲突。

验证方法 #

• 优化完成后用压测工具模拟100+并发请求连续调用报表接口，观察是否还会抛出该异常，确认修复效果。
• 生产环境添加对应异常告警，监控该报错的出现频率，判断方案是否生效。

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