- Print
- DarkLight
System Control
The System Control allow an administrator to free memory, clear class caches, view session information and much more.
Memory
The Memory segment shows system internal memory usage information.
Memory segment fields
Max memory | Maximum available memory. |
Allocated memory | Currently allocated memory. |
Free memory | Free memory (of the currently allocated memory). |
Memory segment buttons
Triggers Garbage Collection to clean up any unreferenced objects and thus increases the amount of free memory. |
User and session information
The user and session information segment shows detailed server, user and session information.
User and session information fields
System startup date | Server startup date. |
Time | Server startup time. |
No of users | Number of currently active users. |
No of sessions | Number of currently active sessions. |
User and session information buttons
Used for monitoring all sessions for all active users. | |
The Logical Unit Of Work tracking button will take you to a list of all open LUOWs. | |
Provides the possibility to see erroneous sql connections (open result sets). Open result sets are often caused by failed logical unit of work operations. |
Logical Unit Of Work (LUOW) tracking
In a transactional system, there are some sets of work that you want saved either in its entirety, or not at all. A logical unit of work (luow) is a set of transactions where either all sets are successfully applied against the database, or no sets have any impact on the database.
For different reasons a luow can end up in a state of neither committed nor roll backed. In such cases it is of great value to be able to track open luow:s and to act on them. The logical unit of work tracking portlet gives you the possibility to track open LUOWs.
Pressing the Luow tracking… button will take you to the System Control luow tracking portlet as below:
Luow portlet fields
Time | Time of when the luow got the state “open”. |
Id | Id of the luow. |
User | User name of the user that started the job that has caused the open luow. |
Workflow file name | Name of the workflow from where the action that has caused the open luow has taken place. |
Reason | Reason of the open luow. The different reasons are: no commit exception |
Trace | Points out which JAVA class that has caused the open luow. |
Luow portlet buttons
Back to previous view. | |
Refreshes the view. |
A right click on a specific luow will present two different options:
Rollback: Performs a rollback of the selected luow transaction.
Stack trace: Performs a stack trace for a specific open luow and populates the Trace field with the result.
Sql tracking
In the sql tracking view you have the possibility to see erroneous sql operations. Such problems are often caused by failed logical unit of work operations.
Pressing the Sql tracking… button will take you to the System Control sql tracking portlet as below:
Sql tracking portlet fields
Table | Database table associated with the open result set. |
SQL Status | The SQL state (from the JDBC driver). |
Stack Trace | Points out which JAVA class to which the erroneous SQL operation belongs. |
Transaction ID | Id of the transaction (the same id as the luow id from Table 10). |
Date | Timestamp of when the erroneous SQL operation occurred. |
DB Connection ID | Id of the database connection. |
Workflow file name | Workflow to which the erroneous SQL operation belongs. |
SQL Error Code | SQL error code (from the JDBC driver) |
User | User that performed the work that caused the erroneous SQL operation. |
Session ID | Session id of the session to which the erroneous SQL operation belongs. |
SQL | The SQL statement that caused the erroneous SQL operation. |
SQL Error Text | SQL error text (from the JDBC driver). |
A right click on a specific open result set will present two different options:
Remove: Removes an open result set
Stack trace: Performs a stack trace for a specific open result set and populates the Trace field with the result.
Cache
The cache segment of the System Control main portlet provides cache information for a number of different cached classes.
Cache size settings are system default set. These settings can be overridden if specified in the sitedef. No settings can be altered in runtime!
Cache segment fields.
Name | Class name. |
Enabled | Cache enabled when checked. |
Initial Size | Number of initially pre allocated class objects in the cache. |
Current Size | Current number of objects in the cache. |
Memory utilization | The amount of system internal memory used by the cached class. |
A right click on a specific class will present two different options:
Clear cache: Removes all cashed objects from the cache
Calculate memory utilization: Calculates the amount of memory that the cached class uses and populates the Memory utilization field with the calculated value
Planned shutdown
The planned shutdown segment allows you to broadcast a message to all logged in users about a server shutdown.
Perform the following steps to broadcast a planned shutdown message:
Set the scheduled shutdown time.
Enter the estimated time the server will be down (duration).
Press the set button.
This will automatically generate a message that will be shown in each users session.
Note that you still need to manually bring down the server. Scheduling the shutdown simply allows all users to be notified that the server will be shutdown for some time.
Connections
Database operations require Comflow programs to acquire jdbc connections from a pool of connections. For different reasons it might happen that an established jdbc connection does not get released. The connections view offers the possibility to view and act upon such active connections.
Listed in the connection segment are all services (see the Name field description in Table 14). Each service shows the number of active and idle connections to it. If the number of active connections remains at a high level even as users log off, it may point to potential problems with SQL statements not being closed correctly, so is worthwhile monitoring.
Connection segment fields
Tracking | Connection tracking is enabled when the check box is checked. |
Name | Name of the connection. One server (server) can host several databases (services). In Figure 18 the connection name is “localhost.CACORE” where “localhost” is the Server name as defined in the sitedef and “CACORE” is the name of the service as defined in the sitedef. |
Url | Url of the connection. |
Active | Number of active connections. |
Idle | Number of idle connections. |
A right click on a specific connection will present three different options:
Enable tracking: Enables tracking for a specific connection
Disable tracking: Disables tracking for a specific connection
Details: Leads to a detailed view of a specific connection
Acting upon active connections
Suppose I have a number of active connections that I suspect should have been closed and that I now want to trace and manually disable.
- Enable tracking by right clicking on the connection and choose Enable tracking as below:
Row click the connection or right click and choose Details
In this example there are ten active connections. From the Trace field we can see that the active connections all come from the same JAVA class.
A right click on a trace entry will give you two options; Release or Stack trace as below.
Choosing “Stack trace” on an active connection will give you a full stack trace:
Choosing “Release” on an active connection will release the selected open connection.
Databases
In the databases segment you have the possibility to view all sitedef defined databases.
The concept of a database in this context should not be confused with a database that is running on a server. The Pool field in Figure 20 is a good example of this because it shows that several databases can actually run on one schema in one database (see Name explanation in Table 14)!
Database portlet fields
Database | Name of the database. A database in this context is specified in the sitedef. Such database definition refers to a specific metadataid, server, service and default schema. |
Metadata id | Name of the Metadata id that is used in conjunction with the database definition. |
Default schema | Name of the schema as specified in the sitedef database definition. |
Pool | JDBC connection pool. |
Loggers
This segment allows you to control the level of logging for various categories at runtime. Note that the default logging level for each category is defined in the sitedef. A runtime server restart will set all logger levels to the sitedef default settings.
The logger level can be set to either:
FATAL
ERROR
WARN
INFO
DEBUG
FATAL will show the least amount of logging, while DEBUG the most.
Loggers
asynchwf | Process related information. |
auditor | |
authentication | Authentication related information. |
bizrules | |
cache | |
concurrency | |
customize | |
database | |
datamaint | |
dialog | |
display | |
error | |
factory | |
fop | |
help | |
jetspeed | |
localization | |
luow | |
main | |
navigations | |
navigator | |
profiler | Performance related information. |
programcall | |
prompt | |
report | |
repository | |
security | |
session | |
shutdown | |
slave | |
sql | |
stack | |
startup | |
text | |
transaction | |
validator | |
workflow |