Closed Nietzschecat closed 1 year ago
在开发「流量回放工具」时,「流量回放工具」内部通过使用
bytebuddy
,在不侵入“业务项目”的情况下,对“业务项目”的各种外部调用进行数据Mock
。
你提到的「流量回放工具」也是基于Java Agent
实现,应用中有2个Agent
吧?
如果是,下面是 继续的内容。
在“业务项目”中通过
Maven
引入「流量回放工具」的jar
包,且在“业务项目”启动时对特定的类做字节码增强(未增强CompletableFuture
等并发类)后,TTL+CompletableFuture
无法再正常进行上下文数据传递。
「流量回放工具」与 TTL
2个Java Agent
之间的影响,
要具体了解2者代码实现与设计才能确定;
仅通过上面的运行结果无法排查。 @Nietzschecat
TTL
是开源的,有完整的排查信息(如源码);
可以让「流量回放工具」的实现同学排查一下。
1、问题简述
在开发「流量回放工具」时,「流量回放工具」内部通过使用
bytebuddy
,在不侵入“业务项目”的情况下,对“业务项目”的各种外部调用进行数据Mock
。在“业务项目”中通过
Maven
引入「流量回放工具」的jar
包,且在“业务项目”启动时对特定的类做字节码增强(未增强CompletableFuture
等并发类)后,TTL+CompletableFuture
无法再正常进行上下文数据传递。简言之:“业务项目”在通过
bytebuddy
增强后,TTL
+CompletableFuture
无法再正常地进行上下文传递。2、测试代码
3、问题复现
transmittable-thread-local
版本:2.12.2情况一:未通过
bytebuddy
增强(1)执行结果(符合预期):
(2)debug过程(符合预期):
情况二:使用
bytebuddy
进行增强(1)执行结果(不符合预期):
(2)
debug
过程:最奇怪的地方:执行到
supplyAsync
时,仍是主线程,但是TransmittableThreadLocal
却生成了新的holder
,仿佛有切面逻辑,但是我在TTL
源码中没找到切面逻辑。主线程的
ttlA.set("888"); ttlB.remove();
操作没生效。子线程内的数据仿佛快照一样,定格在了第一次执行时的上下文,数据不再发生任何变化。