A thread identifier names a sequence of events that can be traced as a group. The events logged for a given thread identifier can be a sequence of events performed to accomplish a task, or it can be a group of similar events.
The Web Service Framework includes several Web services. Each Web service has a data model associated with it. As the identity provider or service provider initializes, the data model builds the set of data items included in each Web service. This log is written once at startup and once each time the identity server application is restarted.
As each Web Service data model is built, you can configure model extensions (or schema extensions) to add additional data items to the model. You can configure the model extensions for each Web Service by adding XML to the edit box on each Web Service’s Details: General Settings page ( > > > > > > ).
The following thread identifier logs each new entry that is added to the model. Also, all errors that occur from attempting to add to the model are logged.
tIdWSFSchemaExtensions: Logs successful and failed additions to all Web service data models.
One of the best ways to debug the identity provider or service provider is to log the HTTP requests and HTTP responses that are handled by the identity provider or service provider. The following thread identifier logs the requests and responses for all subsystems. The HealthCheck request is not logged under this thread identifier because it might become verbose and interfere with locating pertinent data. Therefore, the HealthCheck request is only logged if the tIdHealthCheck thread identifier is included.
tIdRequestResponse: Logs the requests and responses for all subsystems.
As the identity provider or service provider is initializing after a startup or a reconfigure, the configuration is applied to the identity provider or service provider. The following thread identifier logs the configuration data that is used to initialize the identity provider or service provider.
tIdConfiguration: Logs the versions of various subcomponents used in the system. Also logs the details of each Web service.
The identity provider or service provider include an LDAP operations subsystem that handles all communications with the LDAP trust/configuration database and LDAP user stores. This subsystem maintains connection pools for general purpose administrative level LDAP operations and for user LDAP operations. A typical administrative LDAP operation is to read a user’s identity information from the directory. A typical user LDAP operation is to bind a user to a directory object to prove that a name/password combination is valid.
As the system is pushed to its limits, the LDAP operations subsystem can determine that it needs more connections devoted to administrator operations. Thus, user connections from the user connection pool are shared with the administrator connection pool. This also can happen in the opposite direction. The following thread identifiers log data about the current state of the LDAP operations subsystem and the LDAP operations it performs. The LDAP operations subsystem is the most verbose logging section of the identity provider or service provider. Thus, there is a different thread identifier for each basic LDAP operation. Be careful when including all of these thread identifiers at the same time because large amounts of data are logged.
tIdLdapJndiConnShare: Logs details about how the LDAP operations subsystem shares the connection between user and administrator connection pools.
tIdLdapJndiOperations: Logs details associated with the LDAP operations subsystem.
tIdLdapJndiOperationStats: Periodically logs the LDAP operations subsystem statistics.
tIdLdapJndiSearch: Logs details about all LDAP Object Search operations.
tIdLdapJndiGetObject: Logs details about all LDAP Object Get operations.
tIdLdapJndiModifyObject: Logs details about all LDAP Object Modify operations.
tIdLdapJndiCreateConnection: Logs details about all LDAP Connection Create operations.
tIdLdapJndiCloseConnection: Logs details about all LDAP Connection Close operations.
The Session Broker is a component of the Embedded Service Provider that works closely with the Access Gateway to monitor user authentications within a clustered environment. As users log in to the system, their login information is registered in the Session Broker of the Embedded Service Provider. The Session Broker communicates with other members of the cluster to share user session information. Therefore, successful communication between cluster members is vital to a properly functioning system.
The session broker is also responsible for timing out or retiring authentication data that has been unused for too long. When an authentication data item times out, or when the user logs out of the system, the session broker is responsible to send a message to each Access Gateway in the cluster to tell the Access Gateway that the logout has taken place, and that user’s authentication data must be removed.
tIdCBPing: Logs a periodic ping that displays all cluster members to which successful communication is available. The computer initiating the ping is not shown in the list.
tIdCBRetirement: Logs details about user session data that is being retired.
tIdCBLogouts: Logs details about the messages sent to the Access Gateway indicating that a user session has timed out or was logged out.
A periodic health check of the system can be configured. The following thread identifier logs the details about the system items checked during the health check. If the health check reports an error and the administrator is not sure why the error is happening, then this health check log detail can provide more information.
tIdHealthCheck: Logs details about the health check.