|Skip Navigation Links|
|Exit Print View|
|Oracle Directory Server Enterprise Edition Troubleshooting Guide 11g Release 1 (18.104.22.168.0)|
This section describes the administrative alert codes displayed in the instance-path/logs/errors log and the appropriate action to take should these alerts occur.
1000: Server startup
Description: Proxy instance has started.
Solution: dpadm start
1001: Clean Server Shutdown
Description: Clean Server Shutdown alert is displayed when the Directory Proxy Server instance is stopped via. LDAP by the ShutDown task plug-in. The command-line interface implementation does not currently use this stop method.
1002: Abrupt Server Shutdown
Description: Directory Proxy Server instance has shut down abruptly.
Cause: Proxy was stopped through the command-line utility or Proxy JVM exited (Unexpected Fatal Exception, Out Of Memory...)
Solution: Restart the Directory Proxy Server instance.
1003: Configuration Reloaded: OK
Description: This alert is raised when the proxy dynamically reload the configuration file as a whole. This may happen in the following scenarios:
The Reload Configuration task plug-in is invoked via LDAP. This is currently not used by the monitoring framework.
It is possible to configure the proxy to automatically reload its configuration file when it is manually modified, that is, using a text editor. This feature is disabled by default for security and reliability reasons.
This alert is never raised using standard configuration.
Cause: The configuration file is changed on the disk.
Solution: Do not manually edit the configuration file, use dpconf to configure the proxy instance.
1004: Configuration Reloaded: Warning
Description: See the error code 1003. The server failed to reload the configuration but the running instance is not impacted by the configuration problem. As for the error code 1003, this can never occur with a default configuration as automatic configuration reloading is disabled.
1005: Configuration Reloaded: Error
Description: See the error code 1003. The server failed to reload the configuration and the running instance could possibly be impacted by the configuration problem. As for the error code 1003, this can never occur with a default configuration as automatic configuration reloading is disabled.
2000: Data Source Not Available
Description: A data Source is not available anymore. Last proactive monitoring query showed data source is unavailable.
Cause: The error occurred because of any of the following reasons:
Data source has been put offline
Data source crashed
Solution: Do any of the following:
Bring data source back up
Fix network issue
Bring data source down.
2001: Data Source Available
Description: A Data Source has become available. Last proactive monitoring query showed data source is available.
Cause: A Data source has been added or put online.
Solution: Bring data source up.
3000: Listener Not Available
Description: The error is raised when a listener gets fatal IO exception during the accept()() system call. This error might prevent the proxy from restarting. It needs to be addressed as soon as it occurs.
Cause: The listener port is already in use.
Solution: Do the following to solve the problem:
Change port to an unused value.
Free the port by stopping the application bound to it.
4000: Data Inconsistency in Data Sources
Description: The error occurs when an operation has to be applied on multiple back ends partially failed. This only may happen for write LDAP operations. For instance it would be raised when an add must be applied to two data views, if the add to the first data view goes through, the add to the second data view fails and automatic rollback, which consists in deleting the previously added entry in first data view, fails as well.
This may happen in Virtualization and Distribution use cases only.
Cause: An update, add, or delete operation has failed on one data source and the roll back operation is not performed.
Solution: When an operation must be applied to two data views, the proxy first make sure both are able to serve the request by allocating a connection to each data view. So to reproduce easily the problem, use a modify request targeting two data views and tweak the data so that the modify succeeds on the first data view and fails on the second one. For example, value already exists.