调试器不会在下一个断点处暂停并且跟踪不会报告任何内容
The debugger does not pause at the next breakpoint and trace doesn't report anything
当我使用 curl 将 SOAP 消息 post 放入消息流时，需要 9 秒才能响应。调试不会在断点处停止，用户跟踪不会报告任何内容。同时，当我从 Postman 或 SoapUI 发出相同的请求时（第一条消息花费相同的时间，之后所有消息花费大约 70 - 200 毫秒），调试器和用户跟踪按预期工作。这种行为的原因是什么？
IBM 应用连接企业版 11.0.0.8
curl --trace-time 输出：
03:29:07.484000 * Trying <host>...
03:29:07.484000 * TCP_NODELAY set
03:29:07.531000 * Connected to <host_name> (<host>) port 7800 (#0)
03:29:07.531000 > POST /service HTTP/1.1
03:29:07.531000 > Host: <host_name>:7800
03:29:07.531000 > User-Agent: curl/7.55.1
03:29:07.531000 > Accept: */*
03:29:07.531000 > Content-Length: 508
03:29:07.531000 > Content-Type: application/x-www-form-urlencoded
03:29:07.531000 >
03:29:07.546000 * upload completely sent off: 508 out of 508 bytes
03:29:16.671000 < HTTP/1.1 200 OK
03:29:16.671000 < Cache-Control: no-cache
03:29:16.671000 < Pragma: no-cache
03:29:16.687000 < Expires: -1
03:29:16.687000 < X-AspNet-Version: 4.0.30319
03:29:16.687000 < X-Powered-By: ASP.NET
03:29:16.687000 < Date: Fri, 22 May 2020 01:29:14 GMT
03:29:16.687000 < Content-Type: text/xml; charset=utf-8
03:29:16.703000 < Server: IBM App Connect Enterprise
03:29:16.703000 < Content-Length: 243
编辑：我仍在尝试解决问题 - 这次是在 Wireshark 和用户跟踪的帮助下：
卷曲：
02:56:37.781000 > POST /service HTTP/1.1
几毫秒后，Wireshark 检测到来自 "curl machine" 的 POST 消息 - 这意味着连接没有问题
大约 10 秒延迟后，SoapInput 接收数据。为什么需要这么长时间？
2020-05-23 02:56:37.257076 6220 UserTrace BIP11304I: The Parser of type 'MQROOT' has been deleted from address '0x131f1312190'. This thread now has '0' cached parsers.
2020-05-23 02:56:40.591580 3684 UserTrace BIP11303I: A Parser of type 'MQROOT' has been created at address '0x131f13144a0'. This thread now has '36' cached parsers.
2020-05-23 02:56:45.143380 3684 UserTrace BIP11501I: Received data from input node 'SOAP Input'.
The input node 'SOAP Input' has received data and has propagated it to the message flow 'link'.
2020-05-23 02:56:45.143880 3684 UserTrace BIP6060I: Node 'link.SOAP Input' used parser type 'Properties' to process a portion of the incoming message of length '0' bytes beginning at offset '0'.
已通过重启机器修复。知道究竟是什么导致了这个问题吗？
当我使用 curl 将 SOAP 消息 post 放入消息流时，需要 9 秒才能响应。调试不会在断点处停止，用户跟踪不会报告任何内容。同时，当我从 Postman 或 SoapUI 发出相同的请求时（第一条消息花费相同的时间，之后所有消息花费大约 70 - 200 毫秒），调试器和用户跟踪按预期工作。这种行为的原因是什么？
IBM 应用连接企业版 11.0.0.8
curl --trace-time 输出：
03:29:07.484000 * Trying <host>...
03:29:07.484000 * TCP_NODELAY set
03:29:07.531000 * Connected to <host_name> (<host>) port 7800 (#0)
03:29:07.531000 > POST /service HTTP/1.1
03:29:07.531000 > Host: <host_name>:7800
03:29:07.531000 > User-Agent: curl/7.55.1
03:29:07.531000 > Accept: */*
03:29:07.531000 > Content-Length: 508
03:29:07.531000 > Content-Type: application/x-www-form-urlencoded
03:29:07.531000 >
03:29:07.546000 * upload completely sent off: 508 out of 508 bytes
03:29:16.671000 < HTTP/1.1 200 OK
03:29:16.671000 < Cache-Control: no-cache
03:29:16.671000 < Pragma: no-cache
03:29:16.687000 < Expires: -1
03:29:16.687000 < X-AspNet-Version: 4.0.30319
03:29:16.687000 < X-Powered-By: ASP.NET
03:29:16.687000 < Date: Fri, 22 May 2020 01:29:14 GMT
03:29:16.687000 < Content-Type: text/xml; charset=utf-8
03:29:16.703000 < Server: IBM App Connect Enterprise
03:29:16.703000 < Content-Length: 243
编辑：我仍在尝试解决问题 - 这次是在 Wireshark 和用户跟踪的帮助下：
卷曲：
02:56:37.781000 > POST /service HTTP/1.1
几毫秒后，Wireshark 检测到来自 "curl machine" 的 POST 消息 - 这意味着连接没有问题
大约 10 秒延迟后，SoapInput 接收数据。为什么需要这么长时间？
2020-05-23 02:56:37.257076 6220 UserTrace BIP11304I: The Parser of type 'MQROOT' has been deleted from address '0x131f1312190'. This thread now has '0' cached parsers.
2020-05-23 02:56:40.591580 3684 UserTrace BIP11303I: A Parser of type 'MQROOT' has been created at address '0x131f13144a0'. This thread now has '36' cached parsers.
2020-05-23 02:56:45.143380 3684 UserTrace BIP11501I: Received data from input node 'SOAP Input'.
The input node 'SOAP Input' has received data and has propagated it to the message flow 'link'.
2020-05-23 02:56:45.143880 3684 UserTrace BIP6060I: Node 'link.SOAP Input' used parser type 'Properties' to process a portion of the incoming message of length '0' bytes beginning at offset '0'.
已通过重启机器修复。知道究竟是什么导致了这个问题吗？