Problems with recover_33

[Charlie Bursell]

We have recently discovered a problem with the recover_33 procs that could cause message loss.

In the resend procedure of recover_33 you have two message handles, the one that was saved by the Send OK procedure, usually in a global called ob_save, and the one returned by the engine ($mh).  Normally the message handle in $ob_save is copied to a variable called my_mh and the ob_save variable is then cleared.

In the past we have always said that you should KILL one of these and PROTO the other and it did not make any difference which since both handles contain the same message.

We have found if you PROTO $mh, it will not maintain the STATE 14 so if the thread is shut down following a reeend and no acknowledgement is received, the message is lost.  However, if you PROTO the $my_mh message handle it will maintain the State 14 and will be recoverable.

I suggest you check the resend procedure of your recover_33 procs and insure you are resending (PROTO) the saved message handle and not the one returned by the engine.  Hopefully this will be fixed in upcoming versions.  Also in 5.7 recover_33 will be built into the engine.

We have also found that there are so many versions of the recover_33 procs that it is hard to keep up with them.  Therefore, I will upload a copy of recover_33.tcl to the scripts area of this forum and that will be the only version we recommend or support.  

I will also upload an updated version of the generic application to return an HL7 ACK named hl7Raw_ack.tcl.  This version will support both multiserver and non-multiserver interfaces.

Now, to dispel old wives tales ❗

There has been no change to the way Cloverleaf does recovery since version 3.3, thus the name recover_33.  Prior to version 3.3, we had to do recovery different and there was a set of procedures named recover that did that.  When version 3.3 was released we named the new procedures recover_33 to tell the difference.  It has not changed since then!

Anyone that tells you that you need recover_38, recover_53 or whatever is pumping smoke up your butt  😀

Topic

[Charlie Bursell]

I just discovered there is no scripts area as I thought there was.  These scripts have been posted under the Tcl Library forum.

[Russ Ross]

Charlie:

Most excellent heads up and thank you.

I checked our tps_resend_ob_msg.tcl proc and see it is okay.

I highlighted the line in question in the attached screen shot to help illustrate your most excellent find.

Russ Ross
RussRoss318@gmail.com

[Tim Gobbel]

Thanx for the new procs!  I want to use these as they do what I have been looking to edit ours here to do(combine the check_hl7_v2.2_ack with the recovery 33 procs).  The previous recovery procs I got from QDX support had another proc in them (tpsKillObSave).  Do I need to keep something like that in the configuration or id that handled in the check_ack?  Do I still need to keep the hcitpsmsgkill as the last IB reply proc with these new ones?  My current config is attached.  Thanx!

[Gene Salay]

I have to say I’m disappointed.   I was pinning my hopes for a resolution to my send_ok error on the recovery_38!!  (FATAL ERROR! Attempt to save over message ‘message0’ with message ‘message1)

Still digging… any help would be appreciated.    

AIX 5.2, CL 5.3, interface is over a VPN to a Windows machine.

See attached.

[Carter Harrison]

Gene – should probably move this to a new thread since it is discussing recovery_38, but..

That error message you posted is part of the save_ob_msg proc, and it prints itself when the proc that uses the saved message does not clean up after itself.  So to me, it sounds like something is going on in your kill_ob_save proc after you have received a valid ACK from the receiving application.

I couldn’t say definitively what is happening here, but that is where I would narrow my search to.

[Gene Salay]

Thanks to Carter Harrison for fingering the culprit –

I’d neglected to put ‘resend_ob_msg’ in the reply generation UPOC.

Still… 190 sec should be plenty for an ack over a VPN.

Next step is to gracefully handle a “duplicate message” NAK when I resend a message id the destination already got.

[Author]

Replies