Connection reset while transferring HL7 through TCPOperation
We are facing what seems to be a network problem while transferring HL7 messages from Ensemble/Healthshare to a distant target through TCP/IP.
Here is the version of the system in any case it could be useful: Cache for Windows (x86-64) 2017.2.1 (Build 801U) Wed Dec 6 2017 09:07:51 EST [HealthShare Modules:Core:14.02.2415 + Linkage Engine:15.03.9901]
Then the configuration of the operation:
NB high numbers for Read- and Response-Timeouts come from "long" transfers occuring sometimes, e.g. HL7 messages with about 600 segments, successfully transferred if we let them this "long" time.
Some messages in particular block the queue, and we don't understand why because they seem formatted the same way than other passed messages, neither they are the longest ones nor have special characters inside. Removing those messages from the queue allows the flow to be active anew, until another blocking message arrive.
At network level, we notice resets during the transfer of the blocking messages. Below an example with the reset occuring always after the transfer of the 5th chunk.
In the logs of the operation, we find disconnections and reconnections (usually it works while the message in the log is "Discarding received non-HL7 data..."). The receiving party can set up to 10 connections at a time but it seems that everyone becomes blocked as soon as the blocking message occurs :
The main question is : why does the operation not just send the message completely, instead of resetting the connection each time ?