Receiving system hanging, not ACKing

[Tim Gobbel]

I have tried the Recover 33 procs to no avail here.  The receiving system is hanging and saying it is getting a ‘partial message’ and not ACKing.  It appears to receive these partials on a regular basis and goes on OK.  These all have an odd character at the start of the message.  Once in while, however, it gets a message that is really complete but has this odd charater at the beginning.  The recover 33 keeps sending but no ACK is returned.  If the receiving side is ‘bounced’, the same message is processed fine.  Here is a snippet of their comm log.  Anyone have any ideas as to what the odd characters are or mean and what to do about them???  Thanx!

Topic

[Daniel Lee]

It looks like for some reason the receiving system is cutting off the message before it processes the whole message.  In the first message that says “Complete message received” notice how you have the two squares at the end of the message.  I’m sure this represents the /28/13.  Notice how the message that says “Received Partial Message” just quits at in the middle of the IN1 segment.  Than you see another “Complete message received” and see the rest of the message with a /28/13 at the end.

If you can confirm in your outbound smat file that the 7303165 message as the ZNM segment in it, I think you can safely say that it’s not the engine sending out an imcomplete message.  (the engine wouldn’t do this anyway but the vendor is going to need proff that it’s their problem).  Maybe they have some kind of length constraint on messages or on segments that is choping the message off.

[Charlie Bursell]

Tim:

If I had to guess here I would guess the other side is trying to read everything in one read.  Not a good idea with TCP/IP.  TCP/IP packets everything.  You may have to make several reads before you get a whole message.  Tha’s why we need encapsulation or length encoding.

[Alka Sharma]

We have successfully upgraded Cloverleaf from 5.3 to 5.6. We have three sites prod1 , prod2, and prod3. Prod 1 being the heaviest in volume. I am using the new recover 56 procs .  I do not have send_ok, kill_ob_save  procs in my outbound thread. I am using the automatic resend feature of 5.6.

We are using an altered check_ack_new proc. I have also changed

set my_mh $ob_save

Replaced it with this:

keylget args OBMSGID my_mh

Our institution does not want the message to go to Error database if AR or CR is received. So we have modified the check ack and deleted the line to increment the counter. This way, if we get an AR or CR, the message will fall in the else statement of the code and engine will proto the message.

After talking to quovadx support, I was told to use the recover 56 check ack. But once again, I had to alter the check ack to remove the If.

Both tcl procs attached.  The thread that I keep getting a State 16 has the tendency to disconnect and reconnect sporadically.

Any help is greatly appreciated.

[Charlie Bursell]

It seems you posted this in two places.  Why?

I gave you my opinion as to what you did is not a good idea.  As for the problems you are having with your vendor there is only one solution.  Put a sniffer on the line.  They will always point to you unil you can show them what is on the line.

[Alka Sharma]

I did it accidentally. My apologies

[Author]

Replies