Difference: APPXSessionMonitor (1 vs. 17)

Revision 172021-06-08 - AlKalter

Line: 1 to 1
 
META TOPICPARENT name="APPX500Features"

APPX Monitor

Line: 38 to 38
  When the APPX Monitor's shared memory segment is created, it will always be created with the number of slots being a multiple of eight. If you specify a <session_count> that is not a multiple of eight, the number of slots allocated will be increased to the next multiple of eight.
Changed:
<
<
Warning: Setting this too low will result in unpredictable behaviour! Use the forumla above as a minimum value. Add more slots if you routinely run background jobs as well as foreground sessions. There is no drawback to setting this higher than you need.
>
>
Warning: Setting this too low will result in unpredictable behavior! Use the formula above as a minimum value. Add more slots if you routinely run background jobs as well as foreground sessions. There is no drawback to setting this higher than you need.
 

How to Run the APPX Monitor

The APPX Monitor status display process can be run from within APPX System Administration.

Revision 162017-03-29 - JeanNeron

Line: 1 to 1
 
META TOPICPARENT name="APPX500Features"

APPX Monitor

Line: 12 to 12
 

How to Enable the APPX Monitor Feature

To enable the APPX Monitor feature, each APPX session that is to be monitored must have two environment variables set at the time that the session is initiated. Any APPX session does not have these two environment variables set will simply not be displayed on the APPX Monitor display. The APPX License Server session should also have these two environment variables set.

Changed:
<
<
APPX_MONITOR_KEY=<key_number>
>
>
APPX_MONITOR_KEY=<key_number>
  APPX_MONITOR_SLOTS=<session_count>

The easiest way be ensure that these environment variables are set for all APPX sessions including the APPX License Server session is to define them in the appx.env configuration file. Simply add the two environment variables to the appx.env file with appropriate values. The example below assigns a key value of 1234 for the shared memory segment and specifies that the shared memory segment should be large enough to hold the status information for 100 APPX sessions.

Added:
>
>
 
Changed:
<
<

#============================================================================= # APPX Monitor configuration #============================================================================= APPX_MONITOR_KEY=1234 APPX_MONITOR_SLOTS=100

>
>
#============================================================================= # APPX Monitor configuration #============================================================================= APPX_MONITOR_KEY=1234 APPX_MONITOR_SLOTS=100
 

APPX_MONITOR_KEY Environment Variable

Line: 37 to 33
 

APPX_MONITOR_SLOTS Environment Variable

Changed:
<
<
The APPX_MONITOR_SLOTS environment variable defines how many "slots" should be allocated in the shared memory segment for the APPX Monitor. The minimum number of slots should correspond to the maximum number of APPX sessions ever run on your APPX server. For example, if you have 30 licensed users and each user runs no more than two sessions at a time, you should specify a value of at least 61. The following formula can be used to ensure that you allocate a sufficient number of slots:
<session_count> = <licensed_users> * 4 + 1
>
>
The APPX_MONITOR_SLOTS environment variable defines how many "slots" should be allocated in the shared memory segment for the APPX Monitor. The minimum number of slots should correspond to the maximum number of APPX sessions that could be run on your APPX server. For example, if you have 30 licensed users you should specify a value of at least 120 (each user can run as many as 4 sessions). The following formula can be used to ensure that you allocate a sufficient number of slots:
<session_count> = <licensed_users> * 4 + 1
  When the APPX Monitor's shared memory segment is created, it will always be created with the number of slots being a multiple of eight. If you specify a <session_count> that is not a multiple of eight, the number of slots allocated will be increased to the next multiple of eight.
Added:
>
>
Warning: Setting this too low will result in unpredictable behaviour! Use the forumla above as a minimum value. Add more slots if you routinely run background jobs as well as foreground sessions. There is no drawback to setting this higher than you need.
 

How to Run the APPX Monitor

The APPX Monitor status display process can be run from within APPX System Administration.

Changed:
<
<
System Administration --> System Setup --> Monitor APPX Sessions
>
>
System Administration --> System Setup --> Monitor APPX Sessions
  If the APPX Monitor feature has been properly configured, the APPX Monitor process should display a screen similar to the one below.
Changed:
<
<
Monitor.PNG
>
>
Monitor.PNG
 

The Role of the APPX License Server

The license server cleans up orphaned entries in the APPX Monitor's shared memory segment. When an APPX session terminates normally, it removes its entry from the APPX Monitor's shared memory segment. However, if an APPX session crashes or is otherwise abnormally terminated, the session's entry will be left in the APPX Monitor's shared memory segment. The APPX License Server session periodically identifies and removes entries for APPX sessions that are no longer running from the APPX Monitor shared memory segment.

Line: 60 to 58
 

Command to List Shared Memory Segments

The following command can be used on a Unix/Linux system to list the shared memory segments that have been created on the server:

Changed:
<
<
ipcs -m

>
>
ipcs -m

 

In the example below, the shared memory segment with an owner of "appx" is the shared memory segment for the APPX Monitor. The key value can be used to identify the shared memory segment of the APPX Monitor. In this case, the key value of 0x000004d2 is the hexadecimal equivalent of a decimal value of 1234 which is the value that we assigned to the APPX_MONITOR_KEY environment variable.

Changed:
<
<
icpsCommand.PNG
>
>
icpsCommand.PNG
 

Command to Remove Shared Memory Segment

In the event that your APPX server has a problem related to the APPX Monitor's shared memory segment, you can remove the APPX Monitor's shared memory segment. The following command can be used on a Unix/Linux system to remove a shared memory segment.

Changed:
<
<
ipcrm -m <shmid>

>
>
ipcrm -m <shmid>

 

The appropriate value for <shmid> can be determined by listing the shared memory segments on your server to identify the APPX Monitor's shared memory segment.

Revision 152014-04-15 - AlKalter

Line: 1 to 1
 
META TOPICPARENT name="APPX500Features"

APPX Monitor

Line: 38 to 38
 

APPX_MONITOR_SLOTS Environment Variable

The APPX_MONITOR_SLOTS environment variable defines how many "slots" should be allocated in the shared memory segment for the APPX Monitor. The minimum number of slots should correspond to the maximum number of APPX sessions ever run on your APPX server. For example, if you have 30 licensed users and each user runs no more than two sessions at a time, you should specify a value of at least 61. The following formula can be used to ensure that you allocate a sufficient number of slots:

Changed:
<
<
<session_count> = <licensed_users> * 4 + 1
>
>
<session_count> = <licensed_users> * 4 + 1
  When the APPX Monitor's shared memory segment is created, it will always be created with the number of slots being a multiple of eight. If you specify a <session_count> that is not a multiple of eight, the number of slots allocated will be increased to the next multiple of eight.

How to Run the APPX Monitor

Revision 142012-04-05 - BredaHennessy

Line: 1 to 1
 
META TOPICPARENT name="APPX500Features"

APPX Monitor

Line: 17 to 17
 APPX_MONITOR_SLOTS=<session_count>
Changed:
<
<
The easiest way be ensure that these environment variables are set for all APPX sessions including the APPX License Server session is to define them in the appx.env configuration file. Simply add the two environment variables to the appx.env file with appropriate values. The example below assignes a key value of 1234 for the shared memory segment and specifies that the shared memory segment should be large enough to hold the status information for 100 APPX sessions.
>
>
The easiest way be ensure that these environment variables are set for all APPX sessions including the APPX License Server session is to define them in the appx.env configuration file. Simply add the two environment variables to the appx.env file with appropriate values. The example below assigns a key value of 1234 for the shared memory segment and specifies that the shared memory segment should be large enough to hold the status information for 100 APPX sessions.
 

#============================================================================= # APPX Monitor configuration

Revision 132011-05-10 - JeanNeron

Line: 1 to 1
 
META TOPICPARENT name="APPX500Features"
Deleted:
<
<
 

APPX Monitor

Changed:
<
<
Effective with Release 5.0.0, APPX System Administration includes a utility that allows an APPX System Administrator to monitor all APPX sessions .
>
>
Effective with Release 5.0.0, APPX System Administration includes a utility that allows an APPX System Administrator to monitor all APPX sessions .
 

Overview

Changed:
<
<
Release 5.0.0 and higher of the APPX Utility includes a new utility in System Administration which can be used to monitor all APPX sessions.  This utility provides APPX System Administrators with visibility of which processes are being run by the various APPX users as well as status information for each session.
>
>
Release 5.0.0 and higher of the APPX Utility includes a new utility in System Administration which can be used to monitor all APPX sessions. This utility provides APPX System Administrators with visibility of which processes are being run by the various APPX users as well as status information for each session.
 

How to Enable the APPX Monitor Feature

Changed:
<
<
To enable the APPX Monitor feature, each APPX session that is to be monitored must have two environment variables set at the time that the session is initiated.  Any APPX session does not have these two environment variables set will simply not be displayed on the APPX Monitor display. The APPX License Server session should also have these two environment variables set.
>
>
To enable the APPX Monitor feature, each APPX session that is to be monitored must have two environment variables set at the time that the session is initiated. Any APPX session does not have these two environment variables set will simply not be displayed on the APPX Monitor display. The APPX License Server session should also have these two environment variables set.
 
APPX_MONITOR_KEY=<key_number>
Changed:
<
<
APPX_MONITOR_SLOTS=<session_count>
>
>
APPX_MONITOR_SLOTS=<session_count>
 
Changed:
<
<
The easiest way be ensure that these environment variables are set for all APPX sessions including the APPX License Server session is to define them in the appx.env configuration file. Simply add the two environment variables to the appx.env file with appropriate values.  The example below assignes a key value of 1234 for the shared memory segment and specifies that the shared memory segment should be large enough to hold the status information for 100 APPX sessions.
>
>
The easiest way be ensure that these environment variables are set for all APPX sessions including the APPX License Server session is to define them in the appx.env configuration file. Simply add the two environment variables to the appx.env file with appropriate values. The example below assignes a key value of 1234 for the shared memory segment and specifies that the shared memory segment should be large enough to hold the status information for 100 APPX sessions.
 
Changed:
<
<
 

#=============================================================================

>
>

#=============================================================================

 # APPX Monitor configuration #============================================================================= APPX_MONITOR_KEY=1234 APPX_MONITOR_SLOTS=100
Changed:
<
<
>
>

 

APPX_MONITOR_KEY Environment Variable

Changed:
<
<
The APPX_MONITOR_KEY environment variable defines the IPC (interprocess communication) key of the shared memory segment in which the APPX session information is stored.  The <key_number> that you assign to the APPX_MONITOR_KEY environment variable must be a number and must not already be in use by any other shared memory segments that may exist on your system.  You should list the shared memory segments for your system and choose a key value that is not already in use.
>
>
The APPX_MONITOR_KEY environment variable defines the IPC (interprocess communication) key of the shared memory segment in which the APPX session information is stored. The <key_number> that you assign to the APPX_MONITOR_KEY environment variable must be a number and must not already be in use by any other shared memory segments that may exist on your system. If you are running on Unix or Linux, you should list the shared memory segments for your system and choose a key value that is not already in use. On the Windows platform, the shared memory segment is prefixed with 'Appx.', so there's almost no chance of a conflict with other software.
 
Changed:
<
<
Each APPX session updates the shared memory segment with information relating to which APPX process is being run and the status of the process. The APPX Monitor reads the shared memory segment to obtain and display the information for each APPX session. 
>
>
Each APPX session updates the shared memory segment with information relating to which APPX process is being run and the status of the process. The APPX Monitor reads the shared memory segment to obtain and display the information for each APPX session.
 

APPX_MONITOR_SLOTS Environment Variable

Changed:
<
<
The APPX_MONITOR_SLOTS environment variable defines how many "slots" should be allocated in the shared memory segment for the APPX Monitor. The minimum number of slots should correspond to the maximum number of APPX sessions ever run on your APPX server.  For example, if you have 30 licensed users and each user runs no more than two sessions at a time, you should specify a value of at least 61. The following formula can be used to ensure that you allocate a sufficient number of slots:
<session_count> = <licensed_users> * 4 + 1
>
>
The APPX_MONITOR_SLOTS environment variable defines how many "slots" should be allocated in the shared memory segment for the APPX Monitor. The minimum number of slots should correspond to the maximum number of APPX sessions ever run on your APPX server. For example, if you have 30 licensed users and each user runs no more than two sessions at a time, you should specify a value of at least 61. The following formula can be used to ensure that you allocate a sufficient number of slots:
<session_count> = <licensed_users> * 4 + 1
 
Changed:
<
<
When the APPX Monitor's shared memory segment is created, it will always be created with the number of slots being a multiple of eight.  If you specify a <session_count> that is not a multiple of eight, the number of slots allocated will be increased to the next multiple of eight.
>
>
When the APPX Monitor's shared memory segment is created, it will always be created with the number of slots being a multiple of eight. If you specify a <session_count> that is not a multiple of eight, the number of slots allocated will be increased to the next multiple of eight.
 

How to Run the APPX Monitor

The APPX Monitor status display process can be run from within APPX System Administration.

Line: 51 to 49
  If the APPX Monitor feature has been properly configured, the APPX Monitor process should display a screen similar to the one below.
Changed:
<
<
 Monitor.PNG
>
>
Monitor.PNG
 

The Role of the APPX License Server

Changed:
<
<
The license server cleans up orphaned entries in the APPX Monitor's shared memory segment.  When an APPX session terminates normally, it removes its entry from the APPX Monitor's shared memory segment.  However, if an APPX session crashes or is otherwise abnormally terminated, the session's entry will be left in the APPX Monitor's shared memory segment.  The APPX License Server session periodically identifies and removes entries for APPX sessions that are no longer running from the APPX Monitor shared memory segment. 
>
>
The license server cleans up orphaned entries in the APPX Monitor's shared memory segment. When an APPX session terminates normally, it removes its entry from the APPX Monitor's shared memory segment. However, if an APPX session crashes or is otherwise abnormally terminated, the session's entry will be left in the APPX Monitor's shared memory segment. The APPX License Server session periodically identifies and removes entries for APPX sessions that are no longer running from the APPX Monitor shared memory segment.
 

Managing Shared Memory Segments

Changed:
<
<
Under ideal conditions, once you have configured the APPX Monitor feature, there should be no need to be concerned with shared memory segments.  However, in the event that you do encounter a problem that is somehow related to the shared memory segment there a couple of things you can do.  First, you can reboot your server.  Rebooting the server removes all shared memory segments and will clear any problems that might be related to a shared memory segment.  However, if you don't want to reboot your server, there are two commands on Unix/Linux systems which you may find useful for managing shared memory segments.  One command will list the shared memory segments that exist on your server.  The other command can be used to remove a shared memory segment.
>
>
Under ideal conditions, once you have configured the APPX Monitor feature, there should be no need to be concerned with shared memory segments. However, in the event that you do encounter a problem that is somehow related to the shared memory segment there a couple of things you can do. First, you can reboot your server. Rebooting the server removes all shared memory segments and will clear any problems that might be related to a shared memory segment. However, if you don't want to reboot your server, there are two commands on Unix/Linux systems which you may find useful for managing shared memory segments. One command will list the shared memory segments that exist on your server. The other command can be used to remove a shared memory segment.
 

Command to List Shared Memory Segments

Changed:
<
<
The following command can be used on a Unix/Linux system to list the shared memory segments that have been created on the server: 
ipcs -m
>
>
The following command can be used on a Unix/Linux system to list the shared memory segments that have been created on the server:
ipcs -m
 
Changed:
<
<
In the example below, the shared memory segment with an owner of "appx" is the shared memory segment for the APPX Monitor.  The key value can be used to identify the shared memory segment of the APPX Monitor.  In this case, the key value of 0x000004d2 is the hexadecimal equivalent of a decimal value of 1234 which is the value that we assigned to the APPX_MONITOR_KEY environment variable.
>
>
In the example below, the shared memory segment with an owner of "appx" is the shared memory segment for the APPX Monitor. The key value can be used to identify the shared memory segment of the APPX Monitor. In this case, the key value of 0x000004d2 is the hexadecimal equivalent of a decimal value of 1234 which is the value that we assigned to the APPX_MONITOR_KEY environment variable.
 
Changed:
<
<
icpsCommand.PNG
>
>
icpsCommand.PNG
 

Command to Remove Shared Memory Segment

Changed:
<
<
In the event that your APPX server has a problem related to the APPX Monitor's shared memory segment, you can remove the APPX Monitor's shared memory segment. The following command can be used on a Unix/Linux system to remove a shared memory segment.
ipcrm -m <shmid>
>
>
In the event that your APPX server has a problem related to the APPX Monitor's shared memory segment, you can remove the APPX Monitor's shared memory segment. The following command can be used on a Unix/Linux system to remove a shared memory segment.
ipcrm -m <shmid>
 
Changed:
<
<
The appropriate value for <shmid> can be determined by listing the shared memory segments on your server to identify the APPX Monitor's shared memory segment.
>
>
The appropriate value for <shmid> can be determined by listing the shared memory segments on your server to identify the APPX Monitor's shared memory segment.
 

Limitations:

Changed:
<
<
  1. A single-user license has no license server so there is no way for the APPX Monitor to remove crashed sessions from the shared memory segment.  On the other hand, do you really need the APPX Monitor on a single-user system?
  2. If more than one copy of APPX is installed and running on the same server, they cannot use a common shared memory segment.  Each copy of APPX must be configured such that the APPX_MONITOR_KEY environment variable has a different key value.
  3. Two APPX servers cannot use a common shared memory segment.  This limitation also applies to "thick client" installations of APPX.
>
>
  1. A single-user license has no license server so there is no way for the APPX Monitor to remove crashed sessions from the shared memory segment. On the other hand, do you really need the APPX Monitor on a single-user system?

  2. If more than one copy of APPX is installed and running on the same server, they cannot use a common shared memory segment. Each copy of APPX must be configured such that the APPX_MONITOR_KEY environment variable has a different key value.

  3. Two APPX servers cannot use a common shared memory segment. This limitation also applies to "thick client" installations of APPX.

 

Enhancement Suggestions:

Changed:
<
<
  1. The APPX Monitor status display needs an option to allow a System Administrator to kill an APPX session.
  2. The APPX Monitor status display needs an option to specify how often the display should be updated.
  3. The APPX Monitor status display needs a drill down option to show more information for a specific session.
  4. It would be nice if the APPX Monitor status display showed the process ID as well as the User ID.
  5. It would be nice if, during query processes, the APPX Monitor status display would show the name of the process itself, rather than QSLCT and QSORT.
  6. The configuration process is too "manual".  The APPX Monitor feature should always be enabled and should automatically configure itself.
>
>
  1. The APPX Monitor status display needs an option to allow a System Administrator to kill an APPX session.

  2. The APPX Monitor status display needs an option to specify how often the display should be updated.

  3. The APPX Monitor status display needs a drill down option to show more information for a specific session.

  4. It would be nice if the APPX Monitor status display showed the process ID as well as the User ID.

  5. It would be nice if, during query processes, the APPX Monitor status display would show the name of the process itself, rather than QSLCT and QSORT.

  6. The configuration process is too "manual". The APPX Monitor feature should always be enabled and should automatically configure itself.

 

Comments:

Added:
>
>
 Read what other users have said about this page or add your own comments.
Line: 101 to 94
  -- SteveFrizzell - 25 Sep 2008
<--/commentPlugin-->
Changed:
<
<
-- AlKalter - 04 Apr 2008
>
>
-- AlKalter - 04 Apr 2008
 
META FILEATTACHMENT attachment="Monitor.PNG" attr="h" comment="Monitor Running Sessions" date="1222260660" name="Monitor.PNG" path="C:\Documents and Settings\steve\My Documents\My Pictures\Monitor.PNG" size="31065" stream="C:\Documents and Settings\steve\My Documents\My Pictures\Monitor.PNG" user="Main.SteveFrizzell" version="1"
META FILEATTACHMENT attachment="icpsCommand.PNG" attr="h" comment="icps Command on Linux" date="1222281339" name="icpsCommand.PNG" path="C:\Documents and Settings\steve\My Documents\My Pictures\icpsCommand.PNG" size="21713" stream="C:\Documents and Settings\steve\My Documents\My Pictures\icpsCommand.PNG" user="Main.SteveFrizzell" version="1"

Revision 122008-09-25 - SteveFrizzell

Line: 1 to 1
 
META TOPICPARENT name="APPX500Features"

APPX Monitor

Line: 55 to 55
 

The Role of the APPX License Server

The license server cleans up orphaned entries in the APPX Monitor's shared memory segment.  When an APPX session terminates normally, it removes its entry from the APPX Monitor's shared memory segment.  However, if an APPX session crashes or is otherwise abnormally terminated, the session's entry will be left in the APPX Monitor's shared memory segment.  The APPX License Server session periodically identifies and removes entries for APPX sessions that are no longer running from the APPX Monitor shared memory segment. 

Changed:
<
<

Managing Share Memory Segments

>
>

Managing Shared Memory Segments

  Under ideal conditions, once you have configured the APPX Monitor feature, there should be no need to be concerned with shared memory segments.  However, in the event that you do encounter a problem that is somehow related to the shared memory segment there a couple of things you can do.  First, you can reboot your server.  Rebooting the server removes all shared memory segments and will clear any problems that might be related to a shared memory segment.  However, if you don't want to reboot your server, there are two commands on Unix/Linux systems which you may find useful for managing shared memory segments.  One command will list the shared memory segments that exist on your server.  The other command can be used to remove a shared memory segment.
Line: 82 to 82
 

The appropriate value for <shmid> can be determined by listing the shared memory segments on your server to identify the APPX Monitor's shared memory segment.

Deleted:
<
<

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, Comments, Open Issues

From Al Kalter, 28 Apr 2008:

The notes above also stated, "If APPX_MONITOR_SLOTS is too small, nothing tragic happens - new processes just won't update their status information in the monitor table." That sounds like it should be tested, so we killed all sessions, including the license server and appxd, edited the .env file to set the value to 2, and restarted APPX. We used the first login to run the APPX Monitor, and it properly showed that session plus the license server. Using Alt-F1, we started a second session, which also showed up on the Monitor display, a bit of a surprise there. In fact, subsequent sessions also showed up, until we had six sessions running. The seventh did not appear on the table. Closing each of those in the table worked normally, and closing the session(s) that were not shown did not cause any problems, although we did notice that the entry for the license server disappeared temporarily one time. It might be worth testing this with a slight variation - logging in as different users, to check to see if the user count is somehow a factor. But the fact that it allowed six sessions (not four) seems to make that unlikely. Follow-up note: Pete looked into the code to determine why we more than two sessions were being logged, and discovered that the actual number of slots is the next higher multiple of 8 from the value entered.

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.

 

Limitations:

  1. A single-user license has no license server so there is no way for the APPX Monitor to remove crashed sessions from the shared memory segment.  On the other hand, do you really need the APPX Monitor on a single-user system?
Changed:
<
<

Suggested Enhancements:

>
>
  1. If more than one copy of APPX is installed and running on the same server, they cannot use a common shared memory segment.  Each copy of APPX must be configured such that the APPX_MONITOR_KEY environment variable has a different key value.
  2. Two APPX servers cannot use a common shared memory segment.  This limitation also applies to "thick client" installations of APPX.

Enhancement Suggestions:

 
  1. The APPX Monitor status display needs an option to allow a System Administrator to kill an APPX session.
Added:
>
>
  1. The APPX Monitor status display needs an option to specify how often the display should be updated.
 
  1. The APPX Monitor status display needs a drill down option to show more information for a specific session.
Changed:
<
<
  1. It would be nice if the APPX Monitor showed the process ID as well as the User ID.
  2. It would be nice if, during query processes, it would show the name of the process itself, rather than QSLCT and QSORT.
  3. The configuration process is too "manual".  The APPX Monitor should always be on and should automatically configure itself.
>
>
  1. It would be nice if the APPX Monitor status display showed the process ID as well as the User ID.
  2. It would be nice if, during query processes, the APPX Monitor status display would show the name of the process itself, rather than QSLCT and QSORT.
  3. The configuration process is too "manual".  The APPX Monitor feature should always be enabled and should automatically configure itself.
 

Comments:

Read what other users have said about this page or add your own comments.
Changed:
<
<
<--/commentPlugin-->
>
>
This wiki page needs to discuss how to manage shared memory segments on a Windows server.

-- SteveFrizzell - 25 Sep 2008

<--/commentPlugin-->
  -- AlKalter - 04 Apr 2008
Deleted:
<
<
  • icps Command on Linux:
icpsCommand.PNG
 
META FILEATTACHMENT attachment="Monitor.PNG" attr="h" comment="Monitor Running Sessions" date="1222260660" name="Monitor.PNG" path="C:\Documents and Settings\steve\My Documents\My Pictures\Monitor.PNG" size="31065" stream="C:\Documents and Settings\steve\My Documents\My Pictures\Monitor.PNG" user="Main.SteveFrizzell" version="1"
META FILEATTACHMENT attachment="icpsCommand.PNG" attr="h" comment="icps Command on Linux" date="1222281339" name="icpsCommand.PNG" path="C:\Documents and Settings\steve\My Documents\My Pictures\icpsCommand.PNG" size="21713" stream="C:\Documents and Settings\steve\My Documents\My Pictures\icpsCommand.PNG" user="Main.SteveFrizzell" version="1"

Revision 112008-09-24 - SteveFrizzell

Line: 1 to 1
 
META TOPICPARENT name="APPX500Features"
Added:
>
>
 

APPX Monitor

Effective with Release 5.0.0, APPX System Administration includes a utility that allows an APPX System Administrator to monitor all APPX sessions .
Line: 10 to 11
 Release 5.0.0 and higher of the APPX Utility includes a new utility in System Administration which can be used to monitor all APPX sessions.  This utility provides APPX System Administrators with visibility of which processes are being run by the various APPX users as well as status information for each session.

How to Enable the APPX Monitor Feature

Changed:
<
<
To enable the APPX Monitor feature, each APPX session that is to be monitored must have two environment variables set.  Any APPX session does not have these two environment variables will simply not be displayed on the APPX Monitor display. The APPX License Server session should also have these two environment variables set.
>
>
To enable the APPX Monitor feature, each APPX session that is to be monitored must have two environment variables set at the time that the session is initiated.  Any APPX session does not have these two environment variables set will simply not be displayed on the APPX Monitor display. The APPX License Server session should also have these two environment variables set.
 
APPX_MONITOR_KEY=<key_number>

APPX_MONITOR_SLOTS=<session_count>

Changed:
<
<
The easiest way be ensure that these environment variables are set for all APPX sessions including the APPX License Server session is to define them in the appx.env configuration file. Simply add the two environment variables to the appx.env file with appropriate values.  The example below assigned a key value of 1234 for the shared memory segment and specifies that the shared memory segment should be large enough to hold the status information for 100 APPX sessions.
>
>
The easiest way be ensure that these environment variables are set for all APPX sessions including the APPX License Server session is to define them in the appx.env configuration file. Simply add the two environment variables to the appx.env file with appropriate values.  The example below assignes a key value of 1234 for the shared memory segment and specifies that the shared memory segment should be large enough to hold the status information for 100 APPX sessions.
   

Line: 38 to 39
 

APPX_MONITOR_SLOTS Environment Variable

The APPX_MONITOR_SLOTS environment variable defines how many "slots" should be allocated in the shared memory segment for the APPX Monitor. The minimum number of slots should correspond to the maximum number of APPX sessions ever run on your APPX server.  For example, if you have 30 licensed users and each user runs no more than two sessions at a time, you should specify a value of at least 61. The following formula can be used to ensure that you allocate a sufficient number of slots:

Changed:
<
<

>
>

 
<session_count> = <licensed_users> * 4 + 1
Added:
>
>
When the APPX Monitor's shared memory segment is created, it will always be created with the number of slots being a multiple of eight.  If you specify a <session_count> that is not a multiple of eight, the number of slots allocated will be increased to the next multiple of eight.
 

How to Run the APPX Monitor

The APPX Monitor status display process can be run from within APPX System Administration.

Line: 51 to 54
  Monitor.PNG

The Role of the APPX License Server

Changed:
<
<
The license server cleans up orphaned entries in the shared memory segment.  When an APPX session terminates normally, it removes its entry from the APPX Monitor's shared memory segment.  However, if an APPX session crashes or is terminated without ending normally, the session's entry will be left in the APPX Monitor shared memory segment.  The APPX License Server session periodically identifies and removes entries for APPX sessions that are no logner running from the APPX Monitor shared memory segment. 
>
>
The license server cleans up orphaned entries in the APPX Monitor's shared memory segment.  When an APPX session terminates normally, it removes its entry from the APPX Monitor's shared memory segment.  However, if an APPX session crashes or is otherwise abnormally terminated, the session's entry will be left in the APPX Monitor's shared memory segment.  The APPX License Server session periodically identifies and removes entries for APPX sessions that are no longer running from the APPX Monitor shared memory segment. 
 

Managing Share Memory Segments

Changed:
<
<
Under ideal conditions, once you have configured the APPX Monitor feature, there should be no need to be concerned with shared memory segments.  However, in the event that you do encounter a problem that is somehow related to the shared memory segment there a couple of things you can do.  First, you can reboot your server.  Rebooting the server removes all shared memory segments and will clear any problems that might be related to a shared memory segment.  However, if you don't want to reboot your server, there are two commands on Unix/Linux systems which you may find useful for managing shared memory segments.  One command will list the shared memory segments that exist on your server.  There other command can be used to remove a shared memory segment.
>
>
Under ideal conditions, once you have configured the APPX Monitor feature, there should be no need to be concerned with shared memory segments.  However, in the event that you do encounter a problem that is somehow related to the shared memory segment there a couple of things you can do.  First, you can reboot your server.  Rebooting the server removes all shared memory segments and will clear any problems that might be related to a shared memory segment.  However, if you don't want to reboot your server, there are two commands on Unix/Linux systems which you may find useful for managing shared memory segments.  One command will list the shared memory segments that exist on your server.  The other command can be used to remove a shared memory segment.
 

Command to List Shared Memory Segments

Line: 92 to 95
 

Test Results, Comments, Open Issues

From Al Kalter, 28 Apr 2008:
Deleted:
<
<
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 earlier in the development process. 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.

 The notes above also stated, "If APPX_MONITOR_SLOTS is too small, nothing tragic happens - new processes just won't update their status information in the monitor table." That sounds like it should be tested, so we killed all sessions, including the license server and appxd, edited the .env file to set the value to 2, and restarted APPX. We used the first login to run the APPX Monitor, and it properly showed that session plus the license server. Using Alt-F1, we started a second session, which also showed up on the Monitor display, a bit of a surprise there. In fact, subsequent sessions also showed up, until we had six sessions running. The seventh did not appear on the table. Closing each of those in the table worked normally, and closing the session(s) that were not shown did not cause any problems, although we did notice that the entry for the license server disappeared temporarily one time. It might be worth testing this with a slight variation - logging in as different users, to check to see if the user count is somehow a factor. But the fact that it allowed six sessions (not four) seems to make that unlikely. Follow-up note: Pete looked into the code to determine why we more than two sessions were being logged, and discovered that the actual number of slots is the next higher multiple of 8 from the value entered.

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.

Changed:
<
<
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.
>
>

Limitations:

  1. A single-user license has no license server so there is no way for the APPX Monitor to remove crashed sessions from the shared memory segment.  On the other hand, do you really need the APPX Monitor on a single-user system?

Suggested Enhancements:

  1. The APPX Monitor status display needs an option to allow a System Administrator to kill an APPX session.
  2. The APPX Monitor status display needs a drill down option to show more information for a specific session.
  3. It would be nice if the APPX Monitor showed the process ID as well as the User ID.
  4. It would be nice if, during query processes, it would show the name of the process itself, rather than QSLCT and QSORT.
  5. The configuration process is too "manual".  The APPX Monitor should always be on and should automatically configure itself.
 

Comments:

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

Revision 102008-09-24 - SteveFrizzell

Line: 1 to 1
 
META TOPICPARENT name="APPX500Features"
Deleted:
<
<
 

APPX Monitor

Effective with Release 5.0.0, APPX System Administration includes a utility that allows an APPX System Administrator to monitor all APPX sessions .
Line: 12 to 11
 

How to Enable the APPX Monitor Feature

To enable the APPX Monitor feature, each APPX session that is to be monitored must have two environment variables set.  Any APPX session does not have these two environment variables will simply not be displayed on the APPX Monitor display. The APPX License Server session should also have these two environment variables set.

Changed:
<
<
APPX_MONITOR_KEY=<key_number>
APPX_MONITOR_SLOTS=<session_count>
>
>
APPX_MONITOR_KEY=<key_number>

APPX_MONITOR_SLOTS=<session_count>

  The easiest way be ensure that these environment variables are set for all APPX sessions including the APPX License Server session is to define them in the appx.env configuration file. Simply add the two environment variables to the appx.env file with appropriate values.  The example below assigned a key value of 1234 for the shared memory segment and specifies that the shared memory segment should be large enough to hold the status information for 100 APPX sessions.
Added:
>
>
 
 

Changed:
<
<
#=============================================================================
>
>

#=============================================================================

 # APPX Monitor configuration #============================================================================= APPX_MONITOR_KEY=1234 APPX_MONITOR_SLOTS=100
Added:
>
>

APPX_MONITOR_KEY Environment Variable

The APPX_MONITOR_KEY environment variable defines the IPC (interprocess communication) key of the shared memory segment in which the APPX session information is stored.  The <key_number> that you assign to the APPX_MONITOR_KEY environment variable must be a number and must not already be in use by any other shared memory segments that may exist on your system.  You should list the shared memory segments for your system and choose a key value that is not already in use.

Each APPX session updates the shared memory segment with information relating to which APPX process is being run and the status of the process. The APPX Monitor reads the shared memory segment to obtain and display the information for each APPX session. 

APPX_MONITOR_SLOTS Environment Variable

The APPX_MONITOR_SLOTS environment variable defines how many "slots" should be allocated in the shared memory segment for the APPX Monitor. The minimum number of slots should correspond to the maximum number of APPX sessions ever run on your APPX server.  For example, if you have 30 licensed users and each user runs no more than two sessions at a time, you should specify a value of at least 61. The following formula can be used to ensure that you allocate a sufficient number of slots:

<session_count> = <licensed_users> * 4 + 1
 

How to Run the APPX Monitor

Line: 34 to 48
  If the APPX Monitor feature has been properly configured, the APPX Monitor process should display a screen similar to the one below.
Changed:
<
<
 Monitor.PNG

APPX_MONITOR_KEY Environment Variable

>
>
 Monitor.PNG

The Role of the APPX License Server

The license server cleans up orphaned entries in the shared memory segment.  When an APPX session terminates normally, it removes its entry from the APPX Monitor's shared memory segment.  However, if an APPX session crashes or is terminated without ending normally, the session's entry will be left in the APPX Monitor shared memory segment.  The APPX License Server session periodically identifies and removes entries for APPX sessions that are no logner running from the APPX Monitor shared memory segment. 

Managing Share Memory Segments

Under ideal conditions, once you have configured the APPX Monitor feature, there should be no need to be concerned with shared memory segments.  However, in the event that you do encounter a problem that is somehow related to the shared memory segment there a couple of things you can do.  First, you can reboot your server.  Rebooting the server removes all shared memory segments and will clear any problems that might be related to a shared memory segment.  However, if you don't want to reboot your server, there are two commands on Unix/Linux systems which you may find useful for managing shared memory segments.  One command will list the shared memory segments that exist on your server.  There other command can be used to remove a shared memory segment.

Command to List Shared Memory Segments

 
Changed:
<
<
The APPX_MONITOR_KEY environment variable defines the IPC (interprocess communication) key of the shared memory segment in which the APPX session information is stored.  The <key_number> that you assign to the APPX_MONITOR_KEY environment variable must be a number and must not already be in use by any other shared memory segments that may exist on your system.  On a Unix/Linux system, the shared memory segments can be displayed by executing the following command:
>
>
The following command can be used on a Unix/Linux system to list the shared memory segments that have been created on the server: 
 
ipcs -m
Changed:
<
<
Each APPX session updates the shared memory segment with information relating to which APPX process is being run and the status of the process. The APPX Monitor reads the shared memory segment to obtain and display the information for each APPX session. 

APPX_MONITOR_SLOTS Environment Variable

>
>
In the example below, the shared memory segment with an owner of "appx" is the shared memory segment for the APPX Monitor.  The key value can be used to identify the shared memory segment of the APPX Monitor.  In this case, the key value of 0x000004d2 is the hexadecimal equivalent of a decimal value of 1234 which is the value that we assigned to the APPX_MONITOR_KEY environment variable.
 
Changed:
<
<
The APPX_MONITOR_SLOTS environment variable defines how many "slots" should be allocated in the shared memory segment for the APPX Monitor. The minimum number of slots should correspond to the maximum number of APPX sessions ever run on your APPX server.  For example, if you have 30 licensed users and each user runs no more than two sessions at a time, you should specify a value of at least 61. The following formula can be used to ensure that you allocate a sufficient number of slots:
>
>
icpsCommand.PNG

Command to Remove Shared Memory Segment

In the event that your APPX server has a problem related to the APPX Monitor's shared memory segment, you can remove the APPX Monitor's shared memory segment. The following command can be used on a Unix/Linux system to remove a shared memory segment.

 

Changed:
<
<
<session_count> = <licensed_users> * 4 + 1
>
>
ipcrm -m <shmid>
 
Changed:
<
<

The APPX License Server

>
>
 
Changed:
<
<
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).
>
>
The appropriate value for <shmid> can be determined by listing the shared memory segments on your server to identify the APPX Monitor's shared memory segment.
 

Concerns

From Pete Brower:
Line: 82 to 107
 
<--/commentPlugin-->
Changed:
<
<
-- AlKalter - 04 Apr 2008
>
>
-- AlKalter - 04 Apr 2008

  • icps Command on Linux:
icpsCommand.PNG
 
META FILEATTACHMENT attachment="Monitor.PNG" attr="h" comment="Monitor Running Sessions" date="1222260660" name="Monitor.PNG" path="C:\Documents and Settings\steve\My Documents\My Pictures\Monitor.PNG" size="31065" stream="C:\Documents and Settings\steve\My Documents\My Pictures\Monitor.PNG" user="Main.SteveFrizzell" version="1"
Added:
>
>
META FILEATTACHMENT attachment="icpsCommand.PNG" attr="h" comment="icps Command on Linux" date="1222281339" name="icpsCommand.PNG" path="C:\Documents and Settings\steve\My Documents\My Pictures\icpsCommand.PNG" size="21713" stream="C:\Documents and Settings\steve\My Documents\My Pictures\icpsCommand.PNG" user="Main.SteveFrizzell" version="1"

Revision 92008-09-24 - SteveFrizzell

Line: 1 to 1
 
META TOPICPARENT name="APPX500Features"

APPX Monitor

Changed:
<
<
With the new APPX Monitor, System Administrators can review the status of each APPX session.
>
>
Effective with Release 5.0.0, APPX System Administration includes a utility that allows an APPX System Administrator to monitor all APPX sessions .
 

Overview

Deleted:
<
<
To enable the monitor, you have to define two environment variables (we'll come up with reasonable defaults later):
 
Changed:
<
<
  • 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).

>
>
Release 5.0.0 and higher of the APPX Utility includes a new utility in System Administration which can be used to monitor all APPX sessions.  This utility provides APPX System Administrators with visibility of which processes are being run by the various APPX users as well as status information for each session.

How to Enable the APPX Monitor Feature

To enable the APPX Monitor feature, each APPX session that is to be monitored must have two environment variables set.  Any APPX session does not have these two environment variables will simply not be displayed on the APPX Monitor display. The APPX License Server session should also have these two environment variables set.

APPX_MONITOR_KEY=<key_number>
APPX_MONITOR_SLOTS=<session_count>

The easiest way be ensure that these environment variables are set for all APPX sessions including the APPX License Server session is to define them in the appx.env configuration file. Simply add the two environment variables to the appx.env file with appropriate values.  The example below assigned a key value of 1234 for the shared memory segment and specifies that the shared memory segment should be large enough to hold the status information for 100 APPX sessions.

#=============================================================================
# APPX Monitor configuration
#=============================================================================
APPX_MONITOR_KEY=1234
APPX_MONITOR_SLOTS=100

How to Run the APPX Monitor

The APPX Monitor status display process can be run from within APPX System Administration.

System Administration --> System Setup --> Monitor APPX Sessions

If the APPX Monitor feature has been properly configured, the APPX Monitor process should display a screen similar to the one below.

 Monitor.PNG

APPX_MONITOR_KEY Environment Variable

The APPX_MONITOR_KEY environment variable defines the IPC (interprocess communication) key of the shared memory segment in which the APPX session information is stored.  The <key_number> that you assign to the APPX_MONITOR_KEY environment variable must be a number and must not already be in use by any other shared memory segments that may exist on your system.  On a Unix/Linux system, the shared memory segments can be displayed by executing the following command:

ipcs -m

Each APPX session updates the shared memory segment with information relating to which APPX process is being run and the status of the process. The APPX Monitor reads the shared memory segment to obtain and display the information for each APPX session. 

APPX_MONITOR_SLOTS Environment Variable

The APPX_MONITOR_SLOTS environment variable defines how many "slots" should be allocated in the shared memory segment for the APPX Monitor. The minimum number of slots should correspond to the maximum number of APPX sessions ever run on your APPX server.  For example, if you have 30 licensed users and each user runs no more than two sessions at a time, you should specify a value of at least 61. The following formula can be used to ensure that you allocate a sufficient number of slots:

<session_count> = <licensed_users> * 4 + 1

The APPX License Server

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:
Line: 42 to 71
  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.
Changed:
<
<
The notes above also stated, "If APPX_MONITOR_SLOTS is too small, nothing tragic happens - new processes just won't update their status information in the monitor table." That sounds like it should be tested, so we killed all sessions, including the license server and appxd, edited the .env file to set the value to 2, and restarted APPX. We used the first login to run the APPX Monitor, and it properly showed that session plus the license server. Using Alt-F1, we started a second session, which also showed up on the Monitor display, a bit of a surprise there. In fact, subsequent sessions also showed up, until we had six sessions running. The seventh did not appear on the table. Closing each of those in the table worked normally, and closing the session(s) that were not shown did not cause any problems, although we did notice that the entry for the license server disappeared temporarily one time. It might be worth testing this with a slight variation - logging in as different users, to check to see if the user count is somehow a factor. But the fact that it allowed six sessions (not four) seems to make that unlikely. Follow-up note: Pete looked into the code to determine why we more than two sessions were being logged, and discovered that the actual number of slots is the next higher multiple of 8 from the value entered.
>
>
The notes above also stated, "If APPX_MONITOR_SLOTS is too small, nothing tragic happens - new processes just won't update their status information in the monitor table." That sounds like it should be tested, so we killed all sessions, including the license server and appxd, edited the .env file to set the value to 2, and restarted APPX. We used the first login to run the APPX Monitor, and it properly showed that session plus the license server. Using Alt-F1, we started a second session, which also showed up on the Monitor display, a bit of a surprise there. In fact, subsequent sessions also showed up, until we had six sessions running. The seventh did not appear on the table. Closing each of those in the table worked normally, and closing the session(s) that were not shown did not cause any problems, although we did notice that the entry for the license server disappeared temporarily one time. It might be worth testing this with a slight variation - logging in as different users, to check to see if the user count is somehow a factor. But the fact that it allowed six sessions (not four) seems to make that unlikely. Follow-up note: Pete looked into the code to determine why we more than two sessions were being logged, and discovered that the actual number of slots is the next higher multiple of 8 from the value entered.
  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.
Changed:
<
<
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.
>
>
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.
Line: 55 to 83
 
<--/commentPlugin-->

-- AlKalter - 04 Apr 2008 \ No newline at end of file

Added:
>
>
META FILEATTACHMENT attachment="Monitor.PNG" attr="h" comment="Monitor Running Sessions" date="1222260660" name="Monitor.PNG" path="C:\Documents and Settings\steve\My Documents\My Pictures\Monitor.PNG" size="31065" stream="C:\Documents and Settings\steve\My Documents\My Pictures\Monitor.PNG" user="Main.SteveFrizzell" version="1"

Revision 82008-09-15 - SteveFrizzell

Line: 1 to 1
Changed:
<
<
META TOPICPARENT name="APPX43Features"
>
>
META TOPICPARENT name="APPX500Features"
 

APPX Monitor

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

Revision 72008-08-04 - AlKalter

Line: 1 to 1
 
META TOPICPARENT name="APPX43Features"

APPX Monitor

Line: 38 to 38
 

Test Results, Comments, Open Issues

From Al Kalter, 28 Apr 2008:
Changed:
<
<
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.
>
>
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 earlier in the development process. 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.

Revision 62008-05-13 - AlKalter

Line: 1 to 1
 
META TOPICPARENT name="APPX43Features"

APPX Monitor

Line: 43 to 43
 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.

The notes above also stated, "If APPX_MONITOR_SLOTS is too small, nothing tragic happens - new processes just

Changed:
<
<
won't update their status information in the monitor table." That sounds like it should be tested, so we killed all sessions, including the license server and appxd, edited the .env file to set the value to 2, and restarted APPX. We used the first login to run the APPX Monitor, and it properly showed that session plus the license server. Using Alt-F1, we started a second session, which also showed up on the Monitor display, a bit of a surprise there. In fact, subsequent sessions also showed up, until we had six sessions running. The seventh did not appear on the table. Closing each of those in the table worked normally, and closing the session(s) that were not shown did not cause any problems, although we did notice that the entry for the license server disappeared temporarily one time. It might be worth testing this with a slight variation - logging in as different users, to check to see if the user count is somehow a factor. But the fact that it allowed six sessions (not four) seems to make that unlikely.
>
>
won't update their status information in the monitor table." That sounds like it should be tested, so we killed all sessions, including the license server and appxd, edited the .env file to set the value to 2, and restarted APPX. We used the first login to run the APPX Monitor, and it properly showed that session plus the license server. Using Alt-F1, we started a second session, which also showed up on the Monitor display, a bit of a surprise there. In fact, subsequent sessions also showed up, until we had six sessions running. The seventh did not appear on the table. Closing each of those in the table worked normally, and closing the session(s) that were not shown did not cause any problems, although we did notice that the entry for the license server disappeared temporarily one time. It might be worth testing this with a slight variation - logging in as different users, to check to see if the user count is somehow a factor. But the fact that it allowed six sessions (not four) seems to make that unlikely. Follow-up note: Pete looked into the code to determine why we more than two sessions were being logged, and discovered that the actual number of slots is the next higher multiple of 8 from the value entered.
  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.

Revision 52008-05-09 - AlKalter

Line: 1 to 1
 
META TOPICPARENT name="APPX43Features"

APPX Monitor

Line: 26 to 26
 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

Changed:
<
<
From Pete Brower:
>
>
From Pete Brower:
 
Deleted:
<
<
 
  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.
Line: 37 to 35
 
  1. 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.
  2. 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.
  3. 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.
Changed:
<
<

Test Results

>
>

Test Results, Comments, Open Issues

 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.

Added:
>
>
The notes above also stated, "If APPX_MONITOR_SLOTS is too small, nothing tragic happens - new processes just won't update their status information in the monitor table." That sounds like it should be tested, so we killed all sessions, including the license server and appxd, edited the .env file to set the value to 2, and restarted APPX. We used the first login to run the APPX Monitor, and it properly showed that session plus the license server. Using Alt-F1, we started a second session, which also showed up on the Monitor display, a bit of a surprise there. In fact, subsequent sessions also showed up, until we had six sessions running. The seventh did not appear on the table. Closing each of those in the table worked normally, and closing the session(s) that were not shown did not cause any problems, although we did notice that the entry for the license server disappeared temporarily one time. It might be worth testing this with a slight variation - logging in as different users, to check to see if the user count is somehow a factor. But the fact that it allowed six sessions (not four) seems to make that unlikely.
 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.

Revision 42008-05-06 - AlKalter

Line: 1 to 1
 
META TOPICPARENT name="APPX43Features"

APPX Monitor

Line: 25 to 25
 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).
Changed:
<
<

Bug Reports

From Jean Neron:
  1. I think there might be a bug when it shows APPX/ODBC connections, ie, with an active ASQL or WinSQL connection. The state stays at 'Initializing', and the seconds is a negative number that counts down (I was afraid to see what happens when it gets to zero...:-)
  2. As an experiment, I logged on 4 times, some with character, some with Java. Then I killed everything via 'kill -9'. I logged in again & ran MONITOR, and all the old sessions showed up. I checked 'View Registration Usage' in System Admin, and they showed there as well. Ah ha, I thought, bogus records in 0SA USAGE, so I deleted the USAGE file. 'View Registration Usage' is now correct, but MONITOR still shows all the dead sessions.
>
>

Concerns

 From Pete Brower:
Added:
>
>
 
  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.
Line: 42 to 42
  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.
Changed:
<
<
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.
>
>
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.
 
Changed:
<
<
We should also test APPX Monitor with ODBC sessions, as per Jean's item #1 above.
>
>
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.

Revision 32008-04-28 - AlKalter

Line: 1 to 1
 
META TOPICPARENT name="APPX43Features"

APPX Monitor

Line: 28 to 28
 

Bug Reports

From Jean Neron:
  1. I think there might be a bug when it shows APPX/ODBC connections, ie, with an active ASQL or WinSQL connection. The state stays at 'Initializing', and the seconds is a negative number that counts down (I was afraid to see what happens when it gets to zero...:-)
Changed:
<
<
  1. As an experiment, I logged on 4 times, some with character, some with Java. Then I killed everything via 'kill -9'. I logged in again & ran MONITOR, and all the old sessions showed up. I checked 'View Registration Usage' in System Admin, and they showed there as well. Ah ha, I thought, bogus records in 0SA USAGE, so I deleted the USAGE file. 'View Registration Usage' is now correct, but MONITOR still shows all the dead sessions.
>
>
  1. As an experiment, I logged on 4 times, some with character, some with Java. Then I killed everything via 'kill -9'. I logged in again & ran MONITOR, and all the old sessions showed up. I checked 'View Registration Usage' in System Admin, and they showed there as well. Ah ha, I thought, bogus records in 0SA USAGE, so I deleted the USAGE file. 'View Registration Usage' is now correct, but MONITOR still shows all the dead sessions.
 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.
Line: 36 to 36
 
  1. 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.
  2. 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.
  3. 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.
Changed:
<
<
  1. Problem: If you run a process like Vendors from the 1EX Main Menu and it blows up with a File Can't Be Accesses error, upon returning from the error screen to the menu the monitor still says it's running Vendors Input.
>
>
  1. 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.

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.

We should also test APPX Monitor with ODBC sessions, as per Jean's item #1 above.

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.

Revision 22008-04-23 - AlKalter

Line: 1 to 1
 
META TOPICPARENT name="APPX43Features"
Added:
>
>
 

APPX Monitor

With the new APPX Monitor, System Administrators can review the status of each APPX session.
Line: 3 to 4
 

APPX Monitor

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

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).

Bug Reports

From Jean Neron:
  1. I think there might be a bug when it shows APPX/ODBC connections, ie, with an active ASQL or WinSQL connection. The state stays at 'Initializing', and the seconds is a negative number that counts down (I was afraid to see what happens when it gets to zero...:-)
  2. As an experiment, I logged on 4 times, some with character, some with Java. Then I killed everything via 'kill -9'. I logged in again & ran MONITOR, and all the old sessions showed up. I checked 'View Registration Usage' in System Admin, and they showed there as well. Ah ha, I thought, bogus records in 0SA USAGE, so I deleted the USAGE file. 'View Registration Usage' is now correct, but MONITOR still shows all the dead sessions.
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 Accesses error, upon returning from the error screen to the menu the monitor still says it's running Vendors Input.
 

Comments:

Read what other users have said about this page or add your own comments.
<--/commentPlugin-->
Deleted:
<
<
-- AlKalter - 04 Apr 2008
 \ No newline at end of file
Added:
>
>
-- AlKalter - 04 Apr 2008

Revision 12008-04-04 - AlKalter

Line: 1 to 1
Added:
>
>
META TOPICPARENT name="APPX43Features"

APPX Monitor

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

Comments:

Read what other users have said about this page or add your own comments.
<--/commentPlugin-->

-- AlKalter - 04 Apr 2008

 
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2022 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback