APPX Monitor

With the new APPX Monitor, System Administrators can review the status of each APPX session.

Overview

To enable the monitor, you have to define two environment variables (we'll come up with reasonable defaults later):

• APPX_MONITOR_KEY=some-number
• APPX_MONITOR_SLOTS=process-count

These env. variables should be identical for all Appx sessions on your system (if you don't want to include some sessions, just undefine APPX_MONITOR_KEY for those processes).

The APPX_MONITOR_KEY variable defines the IPC (inter-process-communication) identifier for the shared-memory segment that holds the monitor information. Just pick some number that's not already in use (you can see the exiting shared-memory segments on a Linux/Unix host with the command "ipcs -m"). On a Window host, the number doesn't really matter as long as the all processes use the same identifier.

APPX_MONITOR_SLOTS determines how many "slots" are allocated (in shared-memory) for the monitor table. This number should probably be computed from the registration (number of licensed users * 4). If APPX_MONITOR_SLOTS is too small, nothing tragic happens - new processes just won't update their status information in the monitor table.

The license server cleans up orphaned entries - if you don't want to clutter up your monitor table with crashed sessions, make sure you define APPX_MONITOR_KEY and APPX_MONITOR_SLOTS before starting the license server. (Of course, if an engine exits gracefully, it removes itself from the monitor table so the license server will only clean up orphans).

Concerns

From Pete Brower:

1. When we ask for an ID to a shared memory segment and a segment already exists with that key we don't do any checking to see that APPX created this memory and we aren't colliding with some other non-APPX process. I think our shared memory header record should include some known identifier at the beginning that we can inspect.
2. When we ask for an ID to a shared memory segment and a segment already exists with that key we don't use the number of slots out of the shared memory header. We use the number of slots defined in the APPX environment variable. Those values may not be the same. If the value from the environment variable is smaller we limit our access to the memory slots, if larger then our attach to the memory fails completely and silently. It's up the an administrator to manually locate and remove the shared memory segment, run APPX to create the new larger segment, then either wait for all sessions to log out and back in or force everyone to log out and back in to get attached to the new memory segment. Seems like we could put a stale indicator byte in our shared memory header block and when we need to extend the shared memory, set the stale bit, copy the contents of the old segment, delete it, allocate a larger segment, copy the data into it, and continue running. As processes go to update their slot if the header stale bit is set just un-attach/reattach to get to the current segment.
3. It looks like the SessionID used to find a memory slot is based on the row-id of the USAGE file record. Doesn't this create a problem if more than one APPX install path on a system share the same shared memory segment? Since this does not seem like a good thing, each copy can already be configured to use a different key to isolate each to it's own shared memory segment. But for safety I think we should have some information in our shared memory header that tells us the instance of APPX this segment is tied to. That way we would could catch attempts to cross over and use the wrong shared memory key.
4. Synchronized access to our shared memory segment(s) is controlled by locking either a byte in a dummy file on unix or a mutex on windows. In either case the name to the file or mutex is a fixed name. If we have several keyed memory segments in use for different installs of APPX they are all sharing the same synchronization lock. I think this locking should be based on the path to the install.
5. The license server has code that will clean up the shared memory slots left in use by orphan processes. However this will only work if the license server is running on the system that also contains the shared memory slot. This model does not work on Novell or other shared usage file installs. Not sure what to do about this.
6. I think the whole process is too manual. Coming up with key values and setting both Keys and Sizes as environment variable to activate the functionality seems wrong. Why don't we just have it on by default with a way to turn it off. Why don't we just determine a key based on the APPXPATH using the ftok() function, determine a nice initial size based on the license count and re-allocate as mentioned in item 2 above if we need more slots.
7. Problem: If you run a process like Vendors from the 1EX Main Menu and it blows up with a File Can't Be Accessed error, upon returning from the error screen to the menu the monitor still says it's running Vendors Input.
   

Test Results

From Al Kalter, 28 Apr 2008:

General testing of the APPX Monitor resulted in acceptable and expected results. As a user's screen changed, the process name displayed by the APPX Monitor changed as well. Unintentionally, we ran into an error situation in an input process, where the key file was apparently damaged, and the input process locked up. We then were forced to "kill -9" that session, which allowed us to test the issue raised by Jean's item #2 above. We found that the APPX Monitor did indeed remove such dead sessions, although it seems to take several minutes. We also learned the importance of Pete's item #5 - that you have to stop and re-start the license server after the APPX Monitor variables are set, or the APPX Monitor won't know about the license server and vice versa. An easy test - you should see the License Server displayed as one of the processes in the APPX Monitor. If it's not there, then stop and re-start the License Server.

An earlier bug report indicated that the APPX Monitor display would freeze when an ODBC connection was in use. This appears to have been fixed. A session connected via APPX ODBC showed up in the APPX Monitor as "APPXNet Session," and went away when the session was closed.

One facet that is not thoroughly tested is what the APPX Monitor will show for background tasks. It appears that an additional session will be displayed, but the background session we were testing with died too quickly to see what was really happening. This should be investigated further.

It would be nice if the APPX Monitor showed the process ID as well as the User ID. It would also be nice if, during query processes, it would show the name of the process itself, rather than QSLCT and QSORT. And finally, I concur with Pete's statement that the whole process seems too manual. Buttons to start and stop the APPX Monitor, and automation of the selection of the values for the environment variables, would seem to be desirable features. Nonetheless, for System Administrators who want or need to see what their users are doing, this should be a welcome new feature.

Comments:

Read what other users have said about this page or add your own comments.

---

-- AlKalter - 04 Apr 2008