The Ensemble Production configuration screen fails to visually indicate to users, its running stale code.

Question

Question

Steve Pisani · Apr 20, 2016

The following situation always catches out new Ensemble users, and is likely to continue doing this until it is addressed..

A business operation, service or other host that is configured with a dedicated # of actors, (ie, not using the actor pool) runs with the version of compiled code that existed when the host was started. This code is loaded in memory.

Whilst they are running and developers edit and compile lines of code for a business operation, they expect immediate effect, but this does not occur for the aforementioned items, and the only clue that given is an Information event log error saying the host is running a previous (now stale) version of the code.

More problematic is that some changes (like editing a business host to send its message to a new target) are immediately reflected in the UI, and for this case, the lines connecting the business hosts in the configuration screen are drawn as per the latest update when in fact - the message path taken, is not as the user interface describes it because... the business host has not been restarted. I know why this happens, and that's because the lines are drawn at run time by evaluating the last compiled version of the code.

I would like to see either the current event log remain, and there be no misleading and incorrect representations of the host connections in the configuration screen - or - better still - a stronger indication on the configuration screen that a change has been introduced in the the underlying code and that the code is stale. Often there are so many Info messages in the event log (especially in development where this occurs most), that this will be missed, and hours are spent wondering why the new code is not working, causing frustration.

We already know a business host needs re-starting (because we create an event log). How hard could it be to add a flag to the run-time properties of the host, at the same time, to record it needs restarting.

I propose having some visual indication for hosts that are known to be running outdated code. For example, either italicise the host name, introduce a new color, or have a border around the circle next to the host name to indicate visually, the stale state. The connection lines would probably still need to be redrawn from the most recently compiled code, so perhaps, these should be in whatever new color is introduced, or, drawn as a dashed line.

I think something similar should be added to the Production Monitor screen too.

I believe this is an enhancement which would save a lot of angst and win favor among new users (and old ones!).

Can this be implemented ?

Steve

Discussion (1)1

Log in or sign up to continue

David Loveluck · Apr 21, 2016

This is a very good question but there are some subtleties that need to be considered.

On a production server, compilation should be part of a managed deployment process so this isn’t an issue, but in development it is easy to forget to restart a BS or BO.

This situation only applies to Business Services and Business Operations. Typically in a BS or BO the class that implements the service remains instantiated until the BS is disabled or the production is restarted and so the old code runs. The Business process class is instantiated for each request so it doesn’t apply there.

It can be more complicated. For example if a BS is instantiated by application code using CreateBusinessService() from (for example) a web page the BS class will be instantiated for each request so you will see the new code picked up immediately. On the other hand if one job in a pool dies and is restarted, or if the pool size is increased, then you can have a mixture of BS jobs, some running the old code and some running the new code. This is probably rare in development but I do know someone was confused by that situation a few years back.

The configuration page that shows connections can’t know what code is instantiated in running Business Services and the connection lines have to be derived from the current code in the class definition. The only thing that could be done with that is to disable the functionality if the class has been compiled; but that would be unhelpful in the cases when the change had nothing to do with routing.

If a BS or BO continues to run older code after the class is compiled, then we log a message in the event log. We might be able to set a flag in the Job Status global and have an indication in the production monitor based on that, but this situation exists on a job basis, not on a configuration item basis so the UI would be a compromise in the special circumstances described above. I have recorded the enhancement request but nothing is currently planned so for now, I would always advise restarting a BS or BO as soon as you compile the class.

1 0