JMeter中JSR223 Sampler发送EDIFACT消息时响应与请求一致问题咨询

在JMeter中使用JSR223 Sampler发送EDIFACT格式消息时，收到的响应内容与请求完全一致，现排查原因并寻求解决办法。

一、请求内容 #

def payload = "UNB+IATA:1+1S+XX+121103+FF168019110033++ETK1+O'\n" +
"UNH+1+TKCREQ:00:1:IA'\n" +
"MSG+:131'\n" +
"ORG+1S+99999999:X7HH+VZX++T+GR+CXN'\n" +
"TKT+676713121:T'\n" +
"UNT+5+1'\n" +
"UNZ+1+FF168019110033"

二、响应内容 #

UNB+IATA:1+1S+XX+121103+FF168019110033++ETK1+O'\n" +
"UNH+1+TKCREQ:00:1:IA'\n" +
"MSG+:131'\n" +
"ORG+1S+99999999:X7HH+VZX++T+GR+CXN'\n" +
"TKT+676713121:T'\n" +
"UNT+5+1'\n" +
"UNZ+1+FF168019110033

三、日志信息 #

2023-02-07 15:33:39,890 DEBUG o.a.j.p.t.s.TCPSampler: Created org.apache.jmeter.protocol.tcp.sampler.TCPSampler@4a6c4b41
2023-02-07 15:33:39,912 DEBUG o.a.j.p.t.s.TCPSampler: Created org.apache.jmeter.protocol.tcp.sampler.TCPSampler@7bd45f7b
2023-02-07 15:33:39,939 INFO o.a.j.e.StandardJMeterEngine: Running the test!
2023-02-07 15:33:39,939 INFO o.a.j.s.SampleEvent: List of sample_variables: []
2023-02-07 15:33:39,942 INFO o.a.j.g.u.JMeterMenuBar: setRunning(true, *local*)
2023-02-07 15:33:40,147 INFO o.a.j.e.StandardJMeterEngine: Starting ThreadGroup: 1 : Thread Group
2023-02-07 15:33:40,147 INFO o.a.j.e.StandardJMeterEngine: Starting 1 threads for group Thread Group.
2023-02-07 15:33:40,147 INFO o.a.j.e.StandardJMeterEngine: Thread will start next loop on error
2023-02-07 15:33:40,147 INFO o.a.j.t.ThreadGroup: Starting thread group... number=1 threads=1 ramp-up=1 perThread=1000.0 delayedStart=false
2023-02-07 15:33:40,150 INFO o.a.j.t.ThreadGroup: Started thread group number 1
2023-02-07 15:33:40,150 INFO o.a.j.e.StandardJMeterEngine: All thread groups have been started
2023-02-07 15:33:40,150 INFO o.a.j.t.JMeterThread: Thread started: Thread Group 1-1
2023-02-07 15:33:40,162 INFO o.a.j.t.JMeterThread: Thread is done: Thread Group 1-1
2023-02-07 15:33:40,162 INFO o.a.j.t.JMeterThread: Thread finished: Thread Group 1-1
2023-02-07 15:33:40,162 INFO o.a.j.e.StandardJMeterEngine: Notifying test listeners of end of test
2023-02-07 15:33:40,162 INFO o.a.j.g.u.JMeterMenuBar: setRunning(false, *local*)

SampleResult字段:
ContentType:
DataEncoding: windows-1252

四、已执行的配置步骤 #

• JMeter属性TCP配置：
  • tcp.handler=TCPClientImpl
  • eolByte = 111
  • tcp.eolByte=1000
  • tcp.charset=
  • tcp.status.prefix=Status=
  • tcp.status.suffix=.
  • tcp.binarylength.prefix.length=2
• TCP Sampler配置：
  • TCPClient类名=TCPClientImpl
  • 服务器名称=xxxxxx
  • 端口: 3432
  • 超时: 连接2000ms，响应2000ms
  • 启用复用连接
• JSR223 Sampler请求负载：

def payload = "UNB+IATA:1+1S+XX+121103+FF168019110033++ETK1+O'\n" +
"UNH+1+TKCREQ:00:1:IA'\n" +
"MSG+:131'\n" +
"ORG+1S+99999999:X7HH+VZX++T+GR+CXN'\n" +
"TKT+676713121:T'\n" +
"UNT+5+1'\n" +
"UNZ+1+FF168019110033'"

五、原因分析 #

1. EOL字节配置冲突：JMeter属性中同时设置eolByte = 111和tcp.eolByte=1000，导致TCP客户端无法正确识别消息结束符，可能将发送的请求内容误判为响应返回。
2. EDIFACT格式不规范：EDIFACT消息需以'作为段结束符，但请求和负载的最后一段UNZ+1+FF168019110033缺少结束符，服务器无法正确解析，直接回显请求内容。
3. TCP客户端边界识别错误：使用TCPClientImpl时，未正确设置消息边界规则，客户端发送请求后可能读取到自身缓存内容，而非服务器响应。
4. 连接复用残留数据：启用连接复用后，上一次连接的残留数据未清理，导致本次读取到旧数据或自身发送内容。

六、解决办法 #

1. 统一EOL字节配置：删除eolByte = 111，仅保留tcp.eolByte=1000，或根据服务器要求的EDIFACT结束符调整（如EDIFACT常用的十进制39对应单引号'）。
2. 修正EDIFACT格式：确保所有段以'结束，将最后一段改为UNZ+1+FF168019110033'。
3. 调整TCP客户端实现：若TCPClientImpl无法满足需求，改用BinaryTCPClientImpl或自定义TCPClient，确保正确识别响应结束标记。
4. 临时关闭连接复用：排查是否因连接残留数据导致问题，若问题消失则调整连接复用的清理逻辑。
5. 延长响应超时：将响应超时从2000ms适当延长，避免客户端提前读取未完成的响应。
6. 调整字符编码：EDIFACT常用ISO-8859-1或UTF-8，修改tcp.charset为对应编码，确保与服务器一致。

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