Summary of pdl-tcp and state 14 vs state 16, please?

[Dee Davis]

All,

I am confused about the auto-resend (state 16) feature and the pdl-tcp “bugs” reported and am seeking some clarification.

We had been testing with all our old state 14 recover procs (call ours recover_38) under REV 1.  All seemed well.  Then I started reading the forum and thought perhaps we could end up with a memory issue in production.  So I downloaded (Monday) the recover_56 procs and we are testing. Now, ob connections with the recover_56 continuously resend — it is as if the outbound connection is not recognizing the ACK.  But, pdl-debug shows the ACK is okay  (this compared to an outbound using the auto-resend feature).  (Is this a pdl-tcp bug???  Why did it work with recover_38 procs?)

Areas of focus are obviously the ib-reply and reply-gen procs;  why without auto-resend on is reply-gen being hit?  Can someone clarify 1) the difference between state 14 and 16,

2) how the state 14 and state 16 messages are handled innately by the engine as it passes through the queues with and without auto-resend.

I have played around and managed to retain multiple state 14 messages in the database for the same connection, but have not seen a state 16.  I have not yet tested the auto-resend configuration with “real” resends yet.

Thanks in advance for straightening me out.

Dee

Topic

[Charlie Bursell]

If you got the new recover_56 procs they include modified recover_33 procs so your old recover_33 would still work.

State 14 is still a avalid state.  It means the thread is awaiting a reply.  The new state 16 is called “Unbacked Queue” It is where a copy of the sent message is maintaiined for resend, etc.  It takes the place of saving the message in a global via the send_OK proc.

There is an extra key in the reply procs args called OBMSGID which hold the message ID of the saved message.

If you select “Resend outbound message” in reply Timeout Handling, the message will be automatically resent upon timeout.

If you note in the check_ack proc in recover_56 it uses the message stored in OBMSGID instead of the global variable.

The bottom line is, even if you define your own resend proc, is we no longer need the send_OK proc.  If you note, the send_OK in recover_56 is basically a NOP.  We left it in so you don’t have to immediately go out and modify all of your threads.

I hope this helps

[Dee Davis]

Thanks, Charlie.  This does help me verify some of my understanding.

Although we will most likely be converting to the auto-resend, I really want to understand why I am not getting the behavior I’m looking for. (This is in case we “miss” a connection on conversion day.)  We basically renamed the recover_56 procs to our existing proc names (and renamed the old tcl file).  I just can’t figure out if it’s the way the procs are or a bug…

So — the configuration…

Send OK :we have save_ob_msg  I recognize it is just continuing MSGID instead of saving to global.

Reply-Gen: resend_ob_msg_38

tps-ib-reply: kill_ob_save, kill_reply (KILLREPLY of MSGID) — we do not validate_reply or check_ack for the test I am doing.

I can see echos from sms-ib-reply after the ACK hits — but it keeps resending the same message and echoing (from the reply-gen).

I questioned whether with save_ob_msg we needed to KILL the OBMSGID handle in this situation as it was not being done in the proc —   Is that done by the engine innately?  (It seems like there was no state 16 in the db then) Also, because we kill_reply on the MSGID, I thought perhaps we didn’t need kill_ob_save at all since it was doing KILL of the MSGID handle rather than KILLREPLY).  Still get a resend…

We are using PDL-tcp with mlp_tclp.pdl   — Is the problem with the PDL when in non-auto mode??  I suppose we could keep our old recover_38 procs with the extra global in memory since it worked — but I really want to understand what’s happening.

Thanks in advance again.

[Charlie Bursell]

It looks to me like you are mixing the new with the old which you can’t do now.

If you do not want to use check_ack, then simply use hcitpsmsgkill.  But, use the one I recently uploaded.  I had to modify it to take care of OBMSGID.  Look in the tclprocs section of this forum.

If you still have problems, just get hold of the Support guys and they will help you.

[Dee Davis]

Thanks — I just retested taking out the save_ob_msg in the above configuration.  It does work correctly then.  Something must be wrong with that one in the recover_56 set.

Just for one final point of clarification — are these correct?

1. If in manual mode — we would need to KILL or dispose of OBMSGID.

2. If in auto mode – we would NOT need to dispose of OBMSGID.

Thanks — just about done.  Thanks for your patience.

Dee

[Charlie Bursell]

In the auto mode you still need to dispose of it in your ack proc

[Author]

Replies