Route kill procs question

[Mike Strout]

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,

Topic

[Jim Kosloskey]

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.

[Mike Strout]

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?

[Mike Strout]

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.

[Jim Kosloskey]

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.

[Mark Thompson]

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

[Mike Strout]

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.

[Jim Kosloskey]

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.

[Steve Williams]

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…
       }
:
:
:

[Jim Kosloskey]

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.

[Steve Williams]

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.

[Jim Kosloskey]

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.

[Author]

Replies