VA has taken a rather laissez faire approach to how applications are to insure their processes are able to withstand forced shutdowns. Since the functions the applications are performing are guided by end users in collaboration with their system management staff, the processes that must have continuity have pretty much been identified long ago and developers either used methods invented before the advent of the newer Taskman capabilities or have taken advantage of those new capabilities. The rest of the processes that get so rudely interrupted haven't mattered as much and have been safely ignored as those processes are just begun again and run to completion.
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of steven mcphelan Sent: Thursday, September 01, 2005 4:52 AM To: hardhats-members@lists.sourceforge.net Subject: Re: [Hardhats-members] Starting TASKMAN no interactive way Taskman and VistA tasked options can be enhanced to support the functionality that you mention Bhaskar. However, the job is monumental. All existing processes that queued to Taskman would have to be reexamined and mot like rewritten. Taskman would have to be enhanced to automatically restart processes. This step may not be necessary. The SOP for program design could be that the applications would honor the shutdown request and if need be the application would set up a new scheduled task so that it can start up where it left off at. This way Taskman would only have to be modified to handle shut down gracefully which would include to set up the notifications to processes to stop running. >From the system level, this taskman function needs to honor the urgency of the system manager. The situation may be so serious that the manager does not want Taskman to wait for any extended time for the processes to stop. But that could easily be accommodated in that new taskman shutdown functionality. Actually that is the way Taskman currently works. ----- Original Message ----- From: "Jim Self" <[EMAIL PROTECTED]> To: <hardhats-members@lists.sourceforge.net> Sent: Wednesday, August 31, 2005 8:53 PM Subject: Re: [Hardhats-members] Starting TASKMAN no interactive way > Bhaskar wrote: > >Steve -- > > > >I don't have a good answer for what to do if a process is running a > >report that will take several hours to complete when operations wants to > >shut the system down. > > The good news is that you can expect to have very few such long running processes. > GT.M/Linux on a server oriented PC can cut the time required for such processes by orders > of magnitude. I don't think we have any regular tasks left in VMACS that take more than a > few minutes to run. > > >I guess that depends on the application logic for > >the process. [For example, in our banking application, with the use of > >TP, all "batch" processes are designed to be automatically restartable > >from the state of the database.] However, I do take a slightly > >different view of the others. > > > >It seems to me that the typical / traditional deployment of Taskman > >occurs based on a model of computing that (a) CPUs are a scarce resource > >and (b) spawning processes is expensive. Thus, there is a pool of > >processes, and the demand for CPU resources is throttled by queuing > >tasks to processes in this pool. > > This is an important point. It seems to me that those of us who have been working for a > long time with proprietary MUMPS implementations have developed blind spots over the years > regarding this sort of possibility because it could so easily put you in conflict with > restrictions on the number of concurrent processes allowed by your MUMPS license. We (VMTH > UCD) are slowly changing our thinking in this direction, but I find that I need periodic > reminders to let my imagination go that way. > > >Perhaps this model may still be valid when deploying VistA at a large > >hospital - I just can't say for sure one way or another. However, in an > >era when one can and acquire a PC server that at least computationally* > >is as good as, and likely much better than, the biggest VAX that existed > >10 years ago for a couple thousand dollars, and where even a low end > >Linux system can spawn hundreds - and maybe even thousands - of > >processes per second per CPU, this model of resource scarcity doesn't > >apply in the context of VistA deployed at a practice or a small > >hospital. > > One thing we have found is that some PC's make much better servers than others. We have > been running the VMTH on a dual 1.3GHz Pentium 3 rackmount. We have been using a desktop > PC with a faster CPU (I think 2-3Ghz Pentium 4) as a shared development server with a > full-size copy of the live data (slightly out of date and altered). On many intensive > tasks, the P3 is easily 10-20 times faster. > > It might be useful to run some simple VistA and MUMPS related performance tests and post > numbers on the wiki to give a range of performance expectations for people who are > wondering what sort of hardware they need or who seem to be getting exceptionally slow > response. These would ideally be based on data in one of the OpenVistA distributions so > they are easily repeated. > > --------------------------------------- > Jim Self > Systems Architect, Lead Developer > VMTH Computer Services, UC Davis > (http://www.vmth.ucdavis.edu/us/jaself) > > > ------------------------------------------------------- > SF.Net email is Sponsored by the Better Software Conference & EXPO > September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices > Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA > Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf > _______________________________________________ > Hardhats-members mailing list > Hardhats-members@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/hardhats-members ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
