Route kill procs question

Clovertech Forums Read Only Archives Cloverleaf Cloverleaf Route kill procs question

  • Creator
    Topic
  • #54479
    Mike Strout
    Participant

      Let’s say I have two kill procs listed in the Pre-Procs section of a Route Detail, killProc1 and killProc2 (in that order).

      If the message is killed in killProc1, will killProc2 still evaluate it or will processing cease for that message?

      I ran into a scenario where a kill proc is correctly killing the message in the testing tool and I know I both restarted the parent process AND reloaded the proc, just to be sure, but the message still continued downstream. As I looked further into the route, I noticed that a later kill proc continues the message.

      Thanks,

    Viewing 10 reply threads
    • Author
      Replies
      • #81638
        Jim Kosloskey
        Participant

          Mike if the message is KILLed in the first proc then the second proc will not be invoked since theree is no message.

          email: jim.kosloskey@jim-kosloskey.com 30+ years Cloverleaf, 60 years IT – old fart.

        • #81639
          Mike Strout
          Participant

            Thanks for the quick response. I expected the kill procs to work that way and just confirmed in the testing tool that a message that is killed in killProc1 never makes it to killProc2. Grrrr.

            We really struggle in our environment with moving kill procs to PRD only to find out several days later that the server isn’t using the new version. I have progressively added more (seemingly unnecessary) steps reloading a tcl proc and still don’t get consistent results.

            I used to just restart the thread.

            Next, I tried reloading the proc at the thread level and then restarting the thread.

            Next, I tried reloading the proc at the process level and restarting the entire process.

            It is a mystery why even the drastic third step doesn’t work sometimes. Suggestions?

          • #81640
            Mike Strout
            Participant

              I stumbled on one thing that may be causing this intermittent behavior. We use an app called BeyondCompare to move files between TST and PRD. To prevent outright overwriting of the PRD file, we have the app create a backup copy, which it appends a ~ to. We then manually add a timestamp like 20141202 after the ~ so we have some rudimentary version control.

              In a windows environment, the ~ is perfectly fine, which is why BeyondCompare offers it as a default suffix. However, as you unix types know, ~ is a reserved character. It may be that when Cloverleaf looks for the file listed in the tclindex, it can’t tell the difference between the following two files and gets confused (sometimes).

              tps_myKillProc.tcl

              tps_myKillProc.tcl~20141202

              To test my theory, I have replaced every ~ with a . and moved all those backup versions to the TST server in a backup subdirectory. Not only does this keep the PRD server nice and tidy, it should guarantee Cloverleaf doesn’t struggle with file names.

            • #81641
              Jim Kosloskey
              Participant

                Mike,

                You should check your tclIndex file and assure there is only one entry per Tcl proc. Multiple entries will definitely cause issues.

                We use only one Filter proc pretty much so we don’t change the proc we change the arguments so that does not become an issue for us. We don’t have very many Tcl procs here and what we do have rarely changes.

                When I do change a proc however, typically I just do a reload from either the thread or the process (depending on the need) in the NetMonitor and that refreshes memory.

                IF I add a new proc though, I do a reindex followed by a reload.

                email: jim.kosloskey@jim-kosloskey.com 30+ years Cloverleaf, 60 years IT – old fart.

              • #81642
                Mark Thompson
                Participant

                  Mike,

                  Routing is handled in the translate thread, not the protocol threads.  If your Tcl procs are in a route, the safest way to make sure they are applied correctly is to bounce the process.  That restarts the translate thread and the protocol threads.

                  - Mark Thompson
                  HealthPartners

                • #81643
                  Mike Strout
                  Participant

                    Thanks Mark.

                    As I was driving in this morning I thought of a neat way to keep up with the versions of all running tcl procs. In the proc, I could add a few lines of code that would write the version of the script to a file every time it is loaded into memory (when the process starts). That way, at any point in time I could go to the process directory, open the text file and see what versions of scripts are running. Seems like that would be pretty useful info.

                  • #81644
                    Jim Kosloskey
                    Participant

                      Mike,

                      If the proc gets reloaded though (new release) your file won’t reflect that so that means whenever you change a Tcl proc you must interrupt message flow.

                      email: jim.kosloskey@jim-kosloskey.com 30+ years Cloverleaf, 60 years IT – old fart.

                    • #81645
                      Steve Williams
                      Participant

                        Mike,

                          My TCL scripts always announce themselves in the process log.

                        That way you can check the logs to see what scripts kick off and when they are reloaded.

                        Note: for this to work with translation procs, you need to activate “Run translation procs in start mode.” in the Netconfig >> Process > Configure… >> Propeties tab.

                        I use code like the following:

                        Code:


                        :
                        :
                        :
                           set this_proc_name [lindex [info level 0] 0]
                           set this_proc_version_no “v1.1”

                           upvar HciConnName HciConnName
                           keylget args CONTEXT context    ;# Fetch UPoC Context location
                           keylget args MODE mode          ;# Fetch mode

                           set timestamp [clock format [clock seconds] -format “%Y-%m-%d %H:%M:%S”]
                           set indent “:  ”

                           switch -exact — $mode {
                               start {
                                   # Perform special init functions
                                   echo “”
                                   echo “TPS Procedure Startup: $this_proc_name $this_proc_version_no at $timestamp”
                                   echo “$indent TPS Location (UPoC): $HciConnName $context”
                                   
                                   # Perform other start up tasks here…
                               }
                        :
                        :
                        :

                      • #81646
                        Jim Kosloskey
                        Participant

                          Steve,

                          Hmm so this displays in the log after a reload with no stop/start of the thread?

                          email: jim.kosloskey@jim-kosloskey.com 30+ years Cloverleaf, 60 years IT – old fart.

                        • #81647
                          Steve Williams
                          Participant

                            Sorry Jim, I did not mean to confuse anyone.

                            No – the “start” phase only occurs when you stop and start (or use restart) on the thread. I do not use the “reload” feature as it:

                            1 – give a list that is much to long to navigate to reload a single proc.

                            2 – does not call “start” mode and thus does not log TCL init diagnostics

                            I prefer to simply restart an affected thread have have all it’s TCL scripts bounced with one go.

                          • #81648
                            Jim Kosloskey
                            Participant

                              Steve,

                              OK thanks – I passed today’s ‘old-timers disease’ test. Wheh no need to contact the old-folks home just yet 😀

                              The list for reload is not onerous for us because we don’t have that many Tcl procs. But it would be nice to have a type-ahead feature on all pulldowns so one does not have to scroll.

                              email: jim.kosloskey@jim-kosloskey.com 30+ years Cloverleaf, 60 years IT – old fart.

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