Restart thread vs process

I think you pretty much nailed it.  If you change protocol options, it is just the thread.  For adding and removing routes or adding or removing UPOCs, it is the process.

If you change a TCL proc, you should just be able to do a reload for that proc at either the thread level or process level – no restarting is needed just like if you change a translate or table you just need to purge at the thread or process level.

And yes, if you change something in the master, then anything that uses that proc (or translate, or table) would need to be reloaded, purged, or cycled.

Watch out for reload.  It will reload the proc but nothing in startup mode will run if you have anything there.

You can reload a proc by restarting the thread if the proc belongs to the thread.  If the proc is in the route or translate you must restart the process to restart the xlate thread.

The above is why you have to restart the process if routes change.  You have to restart the xlate thread.

Remember, a process is just that, an application that is controlled by the operating system while a thread is controlled by the process.  So, to recover OS resources – memory, disk space, etc. – you must cycle the process.

There is also a reindex function which I think is available at both the thrad and process level in the NetMonitor.

That will cause the TclIndices to be reloaded to memory. If you add a new proc, the reindex will add that proc to the list presented by reload.

When and what to bounce or reload – you really need to know what objects are “owned” by what threads.

The engine process has 3 types of threads – protocol, xlate, and command.  The command thread doesn’t load any Cloverleaf objects.

The protocol threads do the protocol work.  They also own any IB or OP TPS.  If you change any protocol parameters like port number or fileset directory or whatever, that thread will need to be bounced to pick up changes.  If you change an IB or OB Tcl proc you can bounce the thread, or use reload as described above to pick up the changes.

The protocol threads will also cache lookup tables if they are referenced in IB or OB TPS procs (tbllookup command).  The purge command will reload these tables, or of course, you can bounce the thread or process.

The xlate thread owns routing configuration, xlate and associated objects like lookup tables, message models like HL7 variants or XML schemas, pre/post xlate TPS.  Purge will pick up changes for objects like xlate, lookup table, message models.  Reload will pick up changes for Tcl procs.  Anything else, most importantly routing configuration, the process will need to be bounced.  There is no way to bounce the xlate thread independently of the process.

Hope this helps!