Feature request

[RDMTECH]

Would you consider adding an option of an inclusion list to prevent multiple identical processes from running in a single session?

For example:

There 25 users on a Windows 2003 terminal server and want them to only run one instance of notepad.   So I would add notepad.exe to the list and Process Lasso would limit each terminal session to opening one instance of notepad.exe.  In effect limit via session id.

I have a client with a terminal server.  An application they run from multiple terminal sessions at times will open slowly.  So the users will attempt to open the application multiple times.  This effectively bogs down the server.  When I check the CPU resources the CPU is pegged at 100%, but no one process is using more than 2%.  It just that there are 50 or so multiple identical processes open.

If this functionality can be added I have approximately 15 servers that need your product immediately with more to follow.  I would consider adding your application to every server and workstation we would deploy in the future to sweeten the deal. 

[Jeremy Collake]

Yes, I could add this feature pretty easily given Process Lasso's existing capabilities. Your offer sounds compelling, so I will begin work on this asap. I may be able to have it done today, but won't guarantee that. Soon, for sure .

[Hotrod]

Care should be used in implementing such a thing. There are some circumstances when multiple instances of a process are desirable and maybe even necessary. Maybe a choice of the number of allowed instances of a given process would be more usable.

[Jeremy Collake]

Care should be used in implementing such a thing. There are some circumstances when multiple instances of a process are desirable and maybe even necessary. Maybe a choice of the number of allowed instances of a given process would be more usable.

Yes, it should only be used in specific situations, and will definitely not enabled by default. Unless the user populates the list of processes that should be limited to X instances, then no action will be taken.

I will add the ability to set the number of instances allowed per session. I am working on the implementation now.

[RDMTECH]

Excellent! 

I agree setting the number of allowed instances per process makes sense.  Maybe an option to export/import the inclusion list?

Thank you for considering this option.  I am ready to purchase 15 licenses as soon as this feature is added.

Thanks!

[Jeremy Collake]

Just to let you know the status here: I'm almost done with the implementation. I'll be releasing a beta version sometime soon.

I'll probably defer the import/export of specific process lists until the a later version. The main configuration can already be imported/exported, and of course the INI file is pretty easy to copy & paste from. The first priority is just getting this new code written, tested, and polished .

[Jeremy Collake]

Ok, I'm finally finished with all the preliminary core support and GUI additions. I'll be building and uploading v3.17 beta 1 within the next few minutes. Be warned, this will be 'hot off the presses' and has only had limited testing... hence the beta status. Please let me know if you run into any troubles.

Update: Done, as v3.17 beta 1a.

[RDMTECH]

I installed beta3 on a test server.  I logged in as two different users and limited notepad.exe to one instance.  I opened notepad in one session and tried to open it in the other, but it wouldn't let me.

Are you limiting instances per session ID?

Thanks for adding this so quickly.

[Jeremy Collake]

Are you limiting instances per session ID?

By design, yes. It is entirely possible there is a bug though, I will test the code here and see what's going on.

[Jeremy Collake]

First, I apologize I didn't actually test the session resolution code in the last build. I just didn't see how it could go wrong -- a classic programmer's last words .

I basically have two internal functions to retrieve the session ID: one based on the NT native APIs and the other based on the standard Windows API. The former (NT native) doesn't work like it should, a fact I forgot when I wrote this new code. I am deleting it so I don't make the same mistake again.

The good news is that v3.17 beta 4 is out and I DID test the per-session clause this time . Everything appears to work as expected here, please let me know if it doesn't for you. I will continue testing before the final release to be sure.

[RDMTECH]

I tested with notepad.exe allowing one instance.  I opened two RDP sessions and each session was able to open only one instance as expected. 

Great work!

What's left before you take 3.17 final?

[Jeremy Collake]

What's left before you take 3.17 final?

Not much really: a little cosmetic polishing, a bit more testing, and a review of all code changes as I commit them to the source repository. I do my final versions in even numbers, so it will be 3.18. It is likely I'll release it some time tomorrow.

Thanks for reporting back to me with the successful results on your end. That is nice to hear after coming back from dinner .

[RDMTECH]

You are doing an excellent job developing this application.

I've been developing a similar app, but now that I’ve found Process Lasso I would much rather support your work.  I don’t have as much time to code as I have in the past so it’s nice to see someone with a similar mindset take this idea farther.

Keep up the good work and good things will come.

[Jeremy Collake]

Thanks for the support .

I originally wrote Process Lasso years ago for my own personal needs. It was named Process Supervisor at that time. It wasn't until this year that I really took the time to polish it enough to be a revenue generating project.

I have a lot of plans for Process Lasso and there is much work ahead. I hope things continue to go well.

[RDMTECH]

I just purchased 15 licenses.  I'll wait for version 3.18 to deploy.  Thanks for the hard work.

[Jeremy Collake]

I just purchased 15 licenses.  I'll wait for version 3.18 to deploy.  Thanks for the hard work.

Thanks for the business . I went ahead and published v3.18 a little while ago, as everything looks and tests fine here.

Please let me know if you need anything or run into any troubles.

[RDMTECH]

I'll let you know how it goes.  I'll be deploying over the weekend.

[RDMTECH]

I found some anomalies.

1.  If a process is already past its instance limit when you configure it won't close processes until it gets down to the limit. That may be a good thing, but I can see when it would be desirable to close the additional instances to get down to the limit you set.  Maybe you could alert the user that the current limit is less than the number of current instances and ask if you want to close processes until you get to the limit?  Maybe pop up a list of the processes and let you choose which to close.

2.  If a process is already past its instance limit when you configure it will allow additional instances of the processes to be opened. 

3.  If a process is already past its instance limit when you configure and you close all instances of the process it won't limit until you restart the core engine. 

4.  It appears that any reconfiguration of the instance limitation requires a restart of the core engine.

I'm a bit hesitant about deploying.  I could set the limits and restart the core service, but I would like your thoughts first.

Please advise.

[Jeremy Collake]

I found some anomalies.

Thanks for taking the time to report your observations to me.

1.  If a process is already past its instance limit when you configure it won't close processes until it gets down to the limit. That may be a good thing, but I can see when it would be desirable to close the additional instances to get down to the limit you set.  Maybe you could alert the user that the current limit is less than the number of current instances and ask if you want to close processes until you get to the limit?  Maybe pop up a list of the processes and let you choose which to close.

Yes, this is by design. If you limit notepad to 2 instances and there are already 4, trying to create the 5th instance should get terminated, but none of the 4 existing instances will be terminated to get down to the 2 instance limit.

I believe this is the best way to handle it because forcing termination of existing instances could interfere with the user and cause data loss (i.e. if they are editing some text in one of those instances of notepad). What I should do, as you suggest, is inform the user if this condition exists and give them the option to select existing instances to terminate. I will work on this.

2.  If a process is already past its instance limit when you configure it will allow additional instances of the processes to be opened. 
3.  If a process is already past its instance limit when you configure and you close all instances of the process it won't limit until you restart the core engine. 
4.  It appears that any reconfiguration of the instance limitation requires a restart of the core engine.

These sound like the same issue, the updated configuration not getting propagated to the process governor, or is getting delayed in its propagation. Changes to the configuration file are designed to propagate immediately, but on file systems where a change event notification can't be created (like a network share), the governor checks for configuration updates using a polling mechanism.. with a couple minutes between checks for changes to avoid excessive file system activity. It also does this when running as a service in a context where it can't 'connect' with events created by the GUI (or vice-versa).

Anyway, I will investigate and fix in just a minute.

I'm a bit hesitant about deploying.  I could set the limits and restart the core service, but I would like your thoughts first.

Really there is just one issue here, the failure or delay of config changes to propagate. Unless you are making dynamic configuration changes often, there should be no reason not to deploy. If the problem is really simply a delay in propagation of settings, then it is almost a non-issue.

I'll be working today to further polish and test v2.18. I'll be re-running tests on the settings change detection and propagation to make sure it is handled correctly in all cases. If it isn't, you'll see a fix some time today -- or as soon as I find the issue.

[Jeremy Collake]

A quick update: In my tests of normal change-event notification cases, the configuration changes are getting immediately propagated fine with no restart required, at least on my development system here (Vista x32). I am going to do some tests on the backup polling mechanism code. Remember also, as I mentioned, that if the backup polling code is being used, a delay of up to 2 minutes could occur before the changes propagate.

Are you using global path over-rides and/or a network share by any chance for the config file? Are you running the governor as a service or normal process? To know will help me isolate what is causing the behavior you see. It could even be that somehow the governor is getting out of sync and using a different config file path than the GUI. I haven't seen that happen before.. just thinking aloud.

Lastly, if you discover that the aforementioned delay in applying configuration updates is the culprit, please let me know.

Thanks

[RDMTECH]

I've run into some issues where it's not working at all.

Here is a link to download the little movie I made showing the issue:

http://www.velocity.net/~rickm/ProcessLasso.wmv

Let me know what you find.

This is a XP virtual machine.

[Jeremy Collake]

Thanks for taking the time to make this video. I'll go through your exact steps and make sure that Process Lasso works as it should by the next final build.

The behavior you see is a direct result of running the governor as a service. So I recommend not doing so for the time being.

[Jeremy Collake]

Ok, well after fixing it in one manner, I have decided to take a different route.

After working through a few different scenarios here, the only logical course of action is to force use of global path over-rides when the governor is running as a service in the system user context. Running the governor as a service under a user context will be the alternate allowed configuration.

[RDMTECH]

Should I wait for version 3.20?

I was using the service install because the administrator isn't always logged on and I thought this was the best method.

How should I configure?  What do you recommend?

[RDMTECH]

I installed 3.19b1 on my test VM, installed as a service and redirected the global configuration files as recommended.  Everything is working as expected.  The only thing I would request is the option to prompt the admin to close processes that currently exceed the limitation threshold and fixing the tab order on the 'Instance count limited processes' form.  ;-)

THANKS!!!

[Jeremy Collake]

I'm glad you've had success with v3.19 beta 1. I have some more work to do with the service support, there will be a few more betas. I want to make sure it always works as the user would expect.

I must admit that I made a mistake by making the run as service feature only available in the premium version, as that implies that there is some advantage to running the governor as a service. Further, I didn't adequately warn users that running the governor as a service may still have glitches. So, I've got this situation where the people who have paid for the software are more inclined to encounter glitches when they run the core engine as a service. Oh well.. that is what v3.20 is all about, getting the run as service support worked out.

As for if you should run the governor as a service... In your case, it does sound appropriate. My only warning is that you may see other minor glitches, such as not seeing those graph highlights when a ProBalance priority adjustment occurs. Also, more importantly, when you update the configuration the service won't recognize the change until you restart it .. something you've already encountered. Both are due to events being created in different user contexts, causing a lack of 'connection' between the GUI and core engine. If you run the service as the same user with which you use the GUI, instead of as a 'system' service, then things should function a lot better... but there still may be quirks.

I have some temptation to re-release the latest final build to give users some warning about quirks when running the governor as a service, but am undecided on that. I expect v3.20 to be done by the end of the week, assuming I have put it through enough tests and review to be confident with it. I don't know whether or not to tell you to wait on it, as the current version and latest beta, aside from the quirks, should generally work without major problems.

I'll fix the tab order on the instance limits config dialog right now, thanks for the heads up on that. I actually see the tab order on a bunch of the dialogs is off, I just fixed them all here, so next beta they will be right.

The list to select which instances of existing processes to terminate upon setting a new instance count limit is something that will be deferred for a while, at least until I have the run as service support completely worked out.

Thanks for the continued support. I'm certainly working hard here to ensure Process Lasso is a quality product.

[RDMTECH]

Excellent....I'm looking forward to the next beta!!

[Jeremy Collake]

Excellent....I'm looking forward to the next beta!!

I'm working on it now.

As a side note, I noticed that the quirks when running as a system service in XP and w2k aren't as bad as I thought: the graph highlights, config change, and other events all work fine -- or at least they do now .

[Jeremy Collake]

I went ahead and released v3.20 because it substantially improved run-as-service support. I did, however, label the run-as-service support 'experimental'. This is because I still consider the run-as-service support in beta. It just hasn't been tested enough in the real world yet. I'll again remove that label when I'm totally confident in it.

If you notice any troubles, please let me know. I do, however, believe it is safe to deploy and that you won't encounter any major issues. It is only the connection between the GUI and core engine that I am still tweaking a bit, and any remaining quirks are probably specific to Vista.