- This topic has 6 replies, 2 voices, and was last updated 16 years, 3 months ago by
.
-
Topic
-
Hello All, We are having trouble with the TCP/IP protocol on our server merging transactions together. Has anyone else had this problem? Is there a patch or something that we need for the O/S?
When it’s the same message being retransmitted that gets merged, it seems to work out. But when it’s two different message transactions getting merged, it results in data loss. The result never makes it to the receiving system, and Cloverleaf never receives the transaction acknowledgment for it. We do have the current version of the HealthVision recovery code and it is running in the threads. It does appear that this is occurring only on the high volume threads.
Any help or advice you could give us would be greatly appreciated!
TIA
Alise Blankenship
Interface Analyst
Tricore Reference Laboratories
(505) 938-8674
-
Replies
-
-
Are you saying that what is in your SMAT file is not representative of what the foreign TCP/IP listner is receiving? In other words which of these 2 cases best describes your problem:
CASE 1
– merge message in cloverleaf
– message goes to SMAT but some of the merges are missing
– SMAT messages sent out via TCP/IP
CASE 2
– sequential message flow in cloverleaf
– message goes to SMAT
– SMAT message goes out via TCP/IP and merges with previous sent message
I ask because I was not aware that TCP/IP would merge messages.
Yes it does send packets and reassemble them if that is what you mean by merging messages.
Long ago when machines were less powerfull, cloverleaf could over run the TCP/IP input buffer on the foriegn system when it had too much to send too fast.
However, the ACKs are intended to keep this problem from happening even on those old slow systems.
Russ Ross
RussRoss318@gmail.com -
-
-
By the way, this is happening in Cloverleaf, not on the receiving system. We have TCP iptrace logs running on the Cloverleaf engine and they are showing us the problem is on the Cloverleaf side. It does happen mainly during peak performance periods, so we do believe is has to do with volume. But we can’t tell why it is happening. What appears to be happening is that a message that has multiple packets will have a separate packet ID for each packet with a single message ID assigned to all packets associated with a message and used for acking the message. When a new message is merged with a packet from the previous message, it receives the same message ID as the previous message. So when the receiving system finally receives all the packets (from both messages), it acks the message based on the message ID assigned and Cloverleaf never recieves an ACK for the second message because it has the same message ID as the first message. I know this sounds confusing but I don’t know how else to explain what we are seeing.
Please let me know if you have any suggestions. I have a call into support but they are just as stumped as I am.
Thanks.
Alise
-
-
-
- The forum ‘Operating Systems’ is closed to new topics and replies.
