Originally posted by: jdavee

I hope I've not stumbled upon a catch-22.  We have constructed many Launcher systems and traditionally do load balancing by having concurrent Launchers running under separate accounts.  Each account has a Launcher port range and deployment directory.

The advantage we have enjoyed in this setup is that we can manipulate the msl files in the deployment directory to change the scope of what workflows are operational. 

We've also built some Launchers that run separate instances under one account.  These are built in the normal fashion and work fine once we define the msl files that belong to each instance.

This is the logical catch-22:

Launcher with single thread executes /wtx8403/systems/*.msl

Launcher with multiple threads executes /wtx8403/systems/first.msl, second.msl, third.msl

The problem is the loss if the wildcard.  In the single thread we can manipulate the msl execution external to the Launcher.  It just runs what ever msl files it finds.

In the multiple thread we have to specifically name ALL of the msl files to get them to execute.  We can no longer manipulate the msl execution without also running launcheradmin.sh to create a new launcheradmin.bin file.

I'm not seeing a way to effectively provide *.msl support in a multiple thread configuration.  Is that correct?

I was hoping that selecting "separate threads" and having multiple deployment directories would set this up, but that doesn't work at all.

Originally posted by: Laurent(Satisco)

I'm afraid this is as designed.

The "separate threads" setting appeared in its current form in WTX8.0 (a primitive version existed in 7.5, but started a thread for each msl).

If you do not use separate threads, then the behaviour is the same as what happened before 7.5: it fecthes the msl in the deployment directory and runs them in one single "Compound" system (logically named CompoundSystem)

If you DO use separate threads, then you get much more flexibility as you declare which msl runs in its own thread, and each msl(s) can run in the same thread.

So my understanding is the same as yours: no way to handle *.msl in separate threads.

A possibility though would be to use the command line commands to generate the LauncherAdmin.bin file with the msl(s) you want to run, which could save you the "hassle" of using the GUI, and could also be automated.

Hope this helps,

Laurent

Originally posted by: jdavee

Thanks for the confirmation.  I remember when the old multi thread method used one per msl (which is why we never used it before!), so the new approach is certainly better where they can be grouped.  It's unfortunate that we lost wildcard support in the process.

Just for fun I tried using a wildcard in the export/import of the LauncherAdmin.bin.  I had it working with specifically named msl files.  I ran launcheradmin.sh -export and received the XML file of the LauncherAdmin.bin.

From that I edited the list of msl files from five specific entries to one as *.msl. 

After the import I started the engine.  It started fine, but the wildcard was treated as a literal (or roundly ignored).  The only msl that was loaded was the initial one that you have to define when building the separate launcher thread.  It was operational, but none of the other msl that would have been included in *.msl were loaded into the session.

The good news is that I can easily manipulate the XML export to add new msl files and reimport to the LauncherAdmin.bin.  This appears to be the only non-gui way to add new workflows in multi-threaded Launcher environments.  That's a big plus since these are all running on remote Unix boxes where GUI sessions are just unworkable.

Jim