Extra step to keep processes/threads down

[JD]

Hello – I’m curious if there’s a way to purposely keep processes and threads from coming up.  For example, if sites/processes/threads are moved to a live environment for activation at a later date;, is there a way to ensure processes/threads don’t come in case the process is inadvertently started?  I mean in addition to setting all threads to not auto start (extra assurance).  Thank you in advance.  jd

Topic

[James Cobane]

You could configure an alert to shut-down thread/processes if they get started.  But there is always the risk that something may still process depending on the systems involved.

Not sure how far in advance you would want to migrate things as having something in a production environment that you don’t want running is a bit counter intuitive.

Typically, we don’t migrate stuff into production until it is ready to go-live.  If we have a lot of prep-work with a particularly large set of threads/routes, etc., we will impose a “freeze” on any unrelated changes to the affected NetConfigs a day or two in advance, and then have a “working” copy of the NetConfig that we update and “Save As” some other NetConfig name (i.e. NetConfig.xxxx ).  Then when it comes time to implement the changes, we save the NetConfig.xxxx as NetConfig.  This way we can make the necessary updates in advance, then simply invoke the new configuration.

Hope that makes sense.

Jim Cobane – Henry Ford Health

[JD]

Hello – thanks for the insight.   We’re looking to have things in the live environment well ahead of the actual go live.  The threads will be set to not auto start, but I was curious to see if there might be another layer of safety to prevent anything from coming up.

What happens if siteA, siteB ad SiteC are removed from the server.ini file?  This will prevent the sites from coming up?  But, this will also prevent the sites from being accessed via the IDE GUI, right?  Thanks

[Tim Pancost]

Perhaps you could enlighten us a bit on the WHY of this.  As Jim said, it’s rather counterintuitive to put something in a production environment that you don’t want running in production.  It’s kind of the point of the engine to have things running.  Knowing the why might give folks the perspective to give targeted advice.

That being said, we do things very much like Jim and his shop.  If we have a large group of changes to make we’ll instate a freeze, then we’ll make two copies of NetConfig(e.g. NetConfig.b4change and NetConfig.change).  We’ll then make our modifications to the NetConfig.change file.  That way, you can have your stuff “staged” in production.  Then, when it’s time to deploy, it’s just a matter of renaming NetConfig.change to NetConfig, bounce whatever processes are necessary, and be on your merry way.  Then, if things go belly up, and we need to revert, we can always take the NetConfig.b4change and put it back as NetConfig.  What this means is that if you absolutely HAVE to make a change to the existing threads/processes, you have to do dual maintenance on NetConfig and NetConfig.change.

If it’s a brand new site, you can always create it, populate your NetConfig, make a copy, then copy in a blank NetConfig from siteProto.  That way, the site is there, it’s just empty until you’re actually ready to turn things on.

If you’re absolutely adamant about having everything visible, but unusable, and don’t mind having to go back after the fact and do a bunch of cleanup, you could, in addition to setting the threads to not auto-start, configure them to come up on hold.  This will prevent them from actually doing anything if they are inadvertently started.  What this strategy, along with the auto-start thing, means is that once everything’s up and running, now you’ve created a big clean-up task for yourself where you need to go back and update every, single new thread to now auto-start and/or not come up on hold.  Makes me tired just thinking about it. :->

Another point to be made.  If you put a new outbound thread in an already existing process, assuming you bounce processes when you do so, and don’t have it auto-start, there are now going to be messages queueing up for that thread in recovery until you’re ready to go live.  Is that what you want?  Depending on your platform and the length of time that goes on, you could fill up your recovery database and impact threads/processes you actually want running.

One more point(I swear).  The longer you have things “in production” that really aren’t, the more likely something’s going to come along and need to be changed.  And now you have created more work for yourself.

And yes, removing a site from server.ini will make it invisible to the IDE, as it’s the environs tag that it uses to populate the site list.

HTH,

TIM

Tim Pancost – Trinity Health

• This reply was modified 1 year, 7 months ago by Tim Pancost.
• This reply was modified 1 year, 7 months ago by Tim Pancost.

Tim Pancost
Trinity Health

[JD]

Hello – comments noted.  The plan is to move interfaces to prod well ahead of the to live date with the setting set to not auto start.  I was looking for another layer of assurance to keep threads down until ready to be started.  Apologies for the late reply and thank you.

[Charlie Bursell]

A simple way I always used.

Copy prod NetConfig to NetConfig.orig

Move the new stuff into the prod NetConfig

Copy NetConfig to NetConfig.new.

Copy or move NetConfig.orig to NetConfig  (Copy is better to retain orig just in case)

Then when ready to start the new threads, simply copy or move NetConfig.new to NetConfig.

[JD]

Hello – thanks for the details.  The bulk of the interfaces are new and will need new sites created when moved to live; a few interfaces will be additions to existing sites in production.  Maybe have a sort of template NetConfig to use after the interfaces are moved to live and swap with the new production NetConfigs as you suggest.  Thanks again.

[Author]

Replies