Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.
I have developed a small Web app based on GT.M 4.4. It works very well except that I occasionally get some orphaned jobs sitting around when the user hits the stop or the BACK button on the Browser when a large HTML table is loading. What is odd is that this does not always happen these usually terminate with a broken pipe error that I handle thru the application's default $ZTrap routine. Just wondering if you have ever seen this behaviour, and have found a method for dealing with it.
James A Self
There's not anything you can do to prevent these errors. The Back or Stop buttons on the browser break the connection for standard output from your app so that the error wil generally occur on the next WRITE command.
If you are using M2Web then these errors will generally be silently ignored on HTTP GET requests (under the assumption that GET requests are never used for making database updates). We chose not to ignore the errors by default on other request types (most commonly POST), since this presents a possibility of a broken database update that should either be handled by the application or logged for later review.
When processing a POST request you can get the same effect if you set the variable htMethod="GET" after completion of database updates and before initiating output. See the comments in routine ^htLog for further details (http://vista.vmth.ucdavis.edu/rtn/htLog)
If the error trap is working correctly, you should not have any orphaned jobs that have gone through the trap.
You can get the appearance of orphaned jobs if your web applications process for a long period of time with no output sent back to the browser to let the user know that your app is working and making progress. If the user presses the stop button (or anything else to break the connection) your job will not know about it unless it attempts output so it will keep running until it finally attempts to write something and the error trap gets invoked.
Yes you were right. If I watch those jobs long enough they do eventually exit with a Broken pipe error. Which is fine, means I do not have to write an special monitor process to go looking for them, They do eventually fall into the default $ZTrap.
The web address above is not currently operational. Instead use http://vista.vmth.ucdavis.edu/. This has the M2Web utilities hooked up to routines and globals from one of the recent OpenVistA distributions from http://worldvista.org and (among other things) makes it easy to view metadata and and reference data from that database.
There are some screenshots that illustrate some of the functionality at http://vista.vmth.ucdavis.edu/notebook/index/49.html