Cross-Validation
 Technote (FAQ)
 
This document applies only to the following language version(s):
English
 
Problem
Cross-Validation covering performance and usage.
 
Solution
When validating from the wsAdmin scripting tool, validation is performed on all documents, and includes cross validation.
When validating from the admin console, the amount of validation performed is controlled by the troubleshooting settings. These are available under "Troubleshooting->Configuration Problems" (the first "Configuration Problems" item, which does not expand).
Two independent settings are available:
  1. A scope control setting (maximum, high, medium, low, and none),
  2. A cross validation enablement flag
Unless enabled (checked) the admin console will not perform cross validation.
Validation is controlled per configuration document. These are the XML configuration files under the "config" directory of each profile.
For example, "variables.xml", "cell.xml", "node.xml", "resources.xml", and "server.xml".
Validation is triggered as documents are loaded according to the validation policy. That validation will include cross validation if cross validation is enabled.

Validation is run when needed. That is, the validation policy and cross validation enablement controls what validation is to be done. However, the validation is not run until a request is made to view validation messages.

If the message cache is stale, validation will be rerun to generate up to date messages.

When run, whether validation runs in the background (in a separate thread) is under the control of the administrative console.
The validation settings are:
  • "Maximum: Validation all documents",
  • "High: Validate extracted, parent, and local sibling documents",
  • "Medium: Validate extracted and parent documents",
  • "Low: Validate extracted documents",
  • "None: Do not validate documents".

Based on these settings, documents will be registered as the user browsers through the configuration via the various administration console panels.

For example, traversing to "Servers->Application
Servers->server1" will cause (at least) the server configuration document cells\cellName\nodes\nodeName\servers\server.xml to be loaded.

That document will be registered as requiring validation messages. Depending on the validation settings, the nearby documents will also be registered, and the parent node and cell documents may be registered.

Then, when visiting "Troubleshooting->Configuration Problems->Error" (or "Warning" or "Information"), the validation errors for the server and other documents will be shown.
One way to trigger full validation is to set validation
to "Maximum" and enable cross validation.
How often does cross-validation run? That is, is it scheduled to run every x amount of time, or it is triggered?
  • Validation (including cross-validation) is run during product configuration, from the wsAdmin scripting and from the administrative console. Validation is not run during product startup.
  • Cross validation is triggered by a request to view validation results. The amount of cross validation which is performed depends on the state of the validation message queue. This in turn depends on the validation policy & cross-validation enablement, and on the particular configuration documents that are loaded.

Where is the log for cross-validation so I can see what it does, when and how long it runs?
  • Cross-validation usually does not create log statements. Debug statements may be enabled by setting the system property "com.ibm.websphere.validation.debug" to true. The system property must be set in the process running validation. Validation debug output is written to standard output.
  • To time cross-validation on your configuration, use the wsAdmin scripting tool and perform the command: $AdminConfig validate

That runs full validation of the configuration, including cross validation. The time to run validation will be less than the time to run this command.
Validation should not be running when the DMgr is started, nor when an application is deployed.

The sections of the configuration which are visited by the user are registered for validation. This depends on the validation policy, which is under "Troubleshooting", "Configuration Problems". The validation problems are visible there as well.
With only a few key configuration objects (cells, nodes, and servers), validation should run in a few seconds.
Accessing the "configuration problems" section is a request to view validation results. Validation messages are cached for performance.

Visiting a new section of the configuration causes that section to be registered by the validation manager. However, messages are not generated until the user actually goes to view them.
"Application deployment", either from the command line or from the administrative console, should not be impacted by validation. Also, validation is not performed by the runtime code.
Also, for basic timing information on the customer configuration, run validation through wsAdmin by issuing a $AdminConfig validate command.

There are no known issues with cross validation, aside from performance issues when there are many servers or nodes. For this reason, there is a configurable validation policy, and a cross validation enablement flag.

The performance issue is not a run time performance issue, but an issue in using the administrative console.

It is recommended that cross validation be run infrequently in environments where the configuration has many nodes or servers. This recommendation is for performance reasons, as cross validation causes multiple documents to be loaded. There are no other reasons for not running cross validation. The recommendation made by the system administration guide is incorrect.
Cross validation is a category of validation. Both are performed as a part of product administration as a check on the validity of the product configuration. Neither are performed by run time sections of the product, for example, by the application server run time, or by any system management process. The administrative console application does run validation, so it is possible for an application server to indirectly run validation.
Admin scripting runs validation when explicitly requested to do so.
  • What do you recommend or how do I run cross-validation infrequently ? $AdminConfig validate ? Or from the Admin Console ? If it is from the Admin console, where and how ?
  • Can you be more specifics what xml files you need me to provide in order for you to run comparative metrics ? What sort of metrics will the test show ? cpu ? memory ? time to run ?

The XML files under the application server config directory from the cell manager installation. There are application files there, too, but those aren't needed. (The application files can be sent, but they are typically somewhat large, so to avoid unnecessary overhead, I recommend that they not be sent).

Having a copy of the configuration files a validation run can be performed to determine if there are any particular problems validating the specific configuration files.

"Running cross validation infrequently" is deliberately vague. As often as the user is willing as they update their configuration. This depends on the size of the configuration and the particulars of the machine running the validation, so it's not possible to quantify further. The recommendation is to perform a group of configuration updates with cross validation disabled, then to enable cross validation and see if there are any problems.

Validation runs much faster with $AdminConfig validate. However, the recommendation there is the same. Perform a batch of configuration updates then run validation to check for errors.

In this case, running the $AdminConfig validation command gives a good time estimate for running validation from the admin console. The $AdminConfig validation command performs complete validation of the configuration, including all documents and including cross validation. Since the validation is user triggered, and since there is clear notification when validation completes, the time to run validation can be easily noted.

Validation (including cross validation) has no effect on a production system. Validation only has an effect when updating the configuration. Once the config is all set and the production server is brought up, validation is no longer run.
  • Cross validation can have a performance impact only while updating the configuration using the admin console. There might be a performance hit from the scripting client, but since the scripting client only performs validation when explicitly requested, this is not an issue.
In a federated environment, the admin console runs out of the DMgr, so one might view this as a DMgr performance problem, but that is not quite correct. There is a performance hit to the admin console application which is running in the DMgr java process. The run time function of the DMgr itself is not affected.

When the configuration is large (having many nodes or servers), the recommendation is to leave cross validation disabled while making configuration updates, then to go back and re-enable cross validation for a final check.
  • The simplest way to measure the time taken to perform validation is to run the "$AdminConfig validate" command. This runs full validation, including cross validation. If there is a performance problem, it should be noticeable when running this command.
  • There is another way to measure the time taken to perform validation, which is to enable validation debugging.
  • Unfortunately, this slows down validation by a large factor, since there is quite a bit of debugging output which is created, so the timing information is obscured. However, the debugging output is quite detailed, and is useful for telling proportionally where validation is spending its time.
 
 
Cross Reference information
Segment Product Component Platform Version Edition
Application Servers Runtimes for Java Technology Java SDK
 
 


Document Information


Product categories: Software > Application Servers > Distributed Application & Web Servers > WebSphere Application Server > General
Operating system(s): Windows
Software version: 5.1
Software edition:
Reference #: 1196184
IBM Group: Software Group
Modified date: Jan 19, 2005