The lifecycle of EmaCppConsPerf is divided into the following sections:
Figure 9. EmaCppConsPerf Lifecycle
1. Application and Enterprise Message API Initialization.
EmaCppConsPerf loads its configuration, initializes the Enterprise Message API, loads its item list using the specified file, and starts the thread(s) which connect to the provider to perform the test. The Enterprise Message API is configured by using EmaConfig.xml
• The main thread periodically collects and writes statistics from the connection thread(s) until the test is over. All subsequent steps are performed by each thread.
• Connection: the connection thread connects to the provider. If the connection fails, it continually attempts to reconnect until the connection succeeds. When the connection succeeds, the test begins and any subsequent disconnection ends the test.
• Login: the connection thread leverages an Enterprise Message API consumer to provide its login requests and waits for the provider’s response.
• Directory: the connection thread opens a directory stream and searches for the configured service name.
• Startup state: when the service is available, the “startup” phase of the performance measurement begins. During this phase, the connection thread continually performs the following actions:
- Sends bursts of requests, until all desired items have been requested.
- Processes refresh, update, and generic message traffic from the provider.
The “startup” phase continues until all items receive a refresh containing an Open/OK state. All latency statistics recorded up to this point are reported as “startup” statistics.
2. Steady state.
The connection thread continually performs the following actions:
• If configured for posting, the thread sends a burst of post messages.
• Processes updates from the provider.
• If configured to do so, sends a burst of generic messages.
The “steady state” phase continues for the period of time specified in the command line. Latency statistics recorded during this phase are reported as “steady state” statistics.
3. Application shutdown and cleanup.
The connection thread disconnects and stops. The main thread collects all remaining information from the connection threads, cleans them up, and writes the final summary statistics. The main thread then uninitializes the Enterprise Message API, any remaining resources, and exits.