Clovertech

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

› Clovertech Forums › Read Only Archives › Cloverleaf › Cloverleaf › Summary of pdl-tcp and state 14 vs state 16, please?

  • Creator
    Topic
  • August 21, 2008 at 3:57 pm #50254
    Dee Davis
    Participant

      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

    • Creator
      Topic
    Viewing 4 reply threads
    • Author
      Replies
      • August 21, 2008 at 5:34 pm #65355
        Charlie Bursell
        Participant

          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

        • August 21, 2008 at 6:10 pm #65356
          Dee Davis
          Participant

            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.

          • August 21, 2008 at 6:15 pm #65357
            Charlie Bursell
            Participant

              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.

            • August 21, 2008 at 6:21 pm #65358
              Dee Davis
              Participant

                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

              • August 21, 2008 at 6:33 pm #65359
                Charlie Bursell
                Participant

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

              • Author
                Replies
              Viewing 4 reply threads
              • The forum ‘Cloverleaf’ is closed to new topics and replies.