WebLogic Server Administration

WebLogic Server message IDs follow a standardized format consisting of the prefix 'BEA-' followed by a six-digit numeric identifier, such as 'BEA-000215'.

Node Manager is required for automatic restart of failed Managed Servers. It monitors server health and can restart servers that crash or fail. The Administration Server can also trigger restarts through Node Manager, making it essential for high-availability configurations.

JDBC connection failures during server startup are logged at ERROR level because they prevent proper initialization of the application server. ERROR messages indicate problems that affect system functionality. CRITICAL is not a standard WebLogic logging level.

WebLogic Server supports three installation modes: Graphical mode (GUI-based wizard), Console mode (command-line interactive), and Silent mode (unattended using XML configuration). 'Secure' and 'Network' are not valid installation modes in WebLogic.

For high availability in WebLogic, Node Manager must run as a daemon or service on EVERY machine that hosts Managed Servers, not just the Admin Server machine. This allows remote start/stop/monitoring of Managed Servers even when the Administration Server is unavailable.

When the Administration Server is down, Managed Servers can start in Managed Server Independence (MSI) mode. This requires the MSI configuration file to be locally present on each Managed Server machine. Both conditions (b and d) must be met for MSI startup to work.

Node Manager is a WebLogic utility used for remote server management. It can remotely start and stop Managed Servers, auto-restart failed servers, and can be used to kill/terminate Managed Servers. Therefore, all the listed functions are valid uses of Node Manager.

WebLogic's production mode explicitly disables auto-deployment for security and stability. In development mode, applications are auto-deployed when placed in the appropriate directory, but this behavior is disabled in production to prevent accidental deployments.

WebLogic automatically creates a backup of the last known good configuration by renaming config.xml to config.xml.booted after each successful server start. If config.xml becomes corrupted, you can restore this backup file - it's a built-in recovery mechanism that avoids the extreme solution of recreating the entire domain.

Version.txt is not a standard WebLogic file or method for version identification. Server logs contain version information at startup, the WebLogic Console displays the version prominently, and the weblogic.Admin utility can report version through appropriate commands. Version.txt simply doesn't exist in a standard WebLogic installation.

The -verbose:gc JVM flag causes the Java Virtual Machine to output detailed information about each garbage collection event, including timing statistics and memory reclaimed. This is a standard JVM feature independent of any WebLogic-specific tools or utilities - the GC information appears in the JVM's stdout/stderr, not WebLogic logs.

The weblogic.Admin utility classes are contained within weblogic.jar, located in the WL_HOME/server/lib directory of the WebLogic installation. This JAR must be included in the classpath to execute admin commands - the other paths either don't exist or contain the wrong JAR files for this utility.

A WebLogic Machine represents a physical or virtual server that can host managed server instances. The same physical machine can absolutely participate in multiple domains simultaneously - you can run server instances from different WebLogic domains on the same machine. The Machine is just a logical grouping, not a domain-bound resource.

Production mode uses conservative default settings to protect database and system resources. A default connection pool size of 25 provides reasonable throughput for production workloads while preventing resource exhaustion - much lower than development defaults, which typically allow more aggressive pooling for testing convenience.

In WebLogic, SSL is configured at the individual Server level. This design allows each server within a domain to have its own unique SSL settings, private keys, and digital certificates.

Valid WebLogic Server lifecycle states include RUNNING, STANDBY, ADMIN, SHUTDOWN, and过渡 states during startup/shutdown. PENDING is not a formal state in the WebLogic lifecycle - the server moves through defined states but never enters a state called PENDING. The question asks which is NOT a valid state.

WebLogic clusters use multicast IP addresses for cluster-wide communication including heartbeat messages, health monitoring, and state synchronization. All server instances in a cluster listen on the same multicast address (port and IP) to receive broadcasts from other cluster members - this enables efficient one-to-many communication without requiring point-to-point connections between every server.

The -Xmx parameter is used to specify the maximum memory allocation pool (maximum heap size) for the Java Virtual Machine (JVM), whereas -Xms sets the initial heap size.

A WebLogic domain must contain exactly one Administration Server, which acts as the central control point, and zero or more optional Managed Servers that host the actual applications.

The Administration Server acts as the central management point for a WebLogic domain, controlling configuration and monitoring. It's not a distributed control system - that's what managed servers provide. Options C and D are incorrect because only A describes the Administration Server's role.