JVM Vs Weblogic

Use JVMs, which provide better performance for server side applications (ex. JRockit). Administration console can be used for monitoring JVM heap usage graphically.

For better performance, test with JVM-vendor-specific options.

For example, these are typical "hotspot" VM options that you can set:

• -XX +AggressiveHeap - uses heaps that are nearly as large as the total physical memory
• -XX +UseISM - uses intimate shared memory (Solaris)

AggressiveHeap warnings:

1. Use all available memory
2. Incompatible with -Xms -Xmx
3. The heap might may steal memory from the stack

Intimate shared memory warnings (for Solaris only):

1. Lock memory; use only on dedicated systems
2. Memory fragmentation can prevent allocation of contiguous 4 MB pages
3. Abnormal JVM termination can result in locked segments
4. To discover and delete locked segments, use ipcs and ipcrm

Tips

• Do not set the server's heap size larger than the available free RAM on a machine.
  
• For high performance and throughput, set the minimum JVM heap size equal to the maximum heap size.
• WebLogic Server's logging feature for low memory condition can be used to sample the available free memory to detect low memory conditions.
  
• When monitoring garbage collection, if the heap always settles to 85% free, try reducing the heap size.
  
• When setting -noclassgc make sure the perm size is set greater than the default value (32mb).
  Avoid using the -verbosegc option during production run.
  
• Use parallel garbage collection algorithms with multiple CPU machines to reduce the garbage-collection pause time.
  
• On Intel-based architectures, for better performance, configure WebLogic to use the JRockit virtual machine.
  
• To discover and delete locked segments, use ipcs and ipcrm.

Weblogic Monitoring

Use operating-system-specific monitoring tools to observe thread activity and context switching. For example, on Solaris, you can use mpstat, prstat, top to monitor CPU utilization. mpstat exposes CPU utilization, thread interrupts, and voluntary and involuntary context switches. top will help you to find the processes that are using up the CPU.

WebLogic administration console can be used for monitoring running servers, server threads, JVM heap usage, log files, clusters statistics etc. Enabling SNMP monitoring can leverage the existing SNMP monitoring framework, to monitor your WebLogic domain resources through the central admin server.

Section 1.01: Third-party monitoring tools can also be used to monitor application, system resources used by WebLogic Server (Ex. spotlight from Quest, Acsera from Acsera Corporation etc.).

Tips

• An SNMP agent is an integral part of the admin server in a domain, so admin-server instance failure can become a bottleneck.
  
• To monitor WebLogic runtime MBeans, you can use JMX monitoring tools, in addition to the admin console.

Weblogic Threading

To improve WebLogic Server performance, use native I/O (performance pack) if available. To ensure that the performance pack is initialized correctly, check for errors at startup.

Execute queues can be set to automatically increase the threads during overflow condition. But avoid using the server's capability to increase the number of execute threads to manage normal application-load peaks. Rather, do careful capacity planning and server tuning; select an optimal number of execute threads.

Tips

1. Tune the execute thread count only if the CPU is not running at 100% utilization yet client requests are blocked and rejected too often.

2. When tuning the thread count, stop when throughput starts dropping or CPU utilization drops or stays constant.

3. Do not set the Stuck Thread Max Time and Stuck Thread Time Interval so low so that normal requests during peak processing time are mistaken for stuck threads.

4. To partition application components or to provide a dedicated amount of resources to one component, create user-defined execute queues. Using custom execute queues also avoids potential cross-server deadlock situations.

5. To provide a dedicated resource to message-driven beans, use a separate execute queue for each message-driven EJB that is deployed.

6. When troubleshooting deadlocks and long-running requests on WebLogic Server, use a series of properly spaced thread dumps to determine the possible causes.

7. Enabling T3 protocol access over HTTP by tunneling degrades performance by approximately 15%; avoid tunneling T3 over HTTP.

Testing Tips

1. During capacity planning and testing, plan for the peak load that an application might incur.

2. Optimize the application during testing; typically, on WebLogic Server, applications are the most-limiting factor in performance and capacity.

3. When you put a system under stress to test performance, use appropriate, realistic test cases.
4. The closer the test cases are to production situations, the more accurate the test results are.

5. When benchmarking applications, ignore the first few samples; run test samples to "warm up" the server VM.

Weblogic Clustering

WebLogic cluster is group of managed servers from a domain that will act in a coordinate fashion to provide a single server view for the client. Use WebLogic clusters to improve efficiency, scalability, load-balancing and failover. WebLogic cluster is a process level cluster, where the participating servers can be on a different physical machine or on the same machine.

IP Multicast is the backbone for exchanging heart beat signals in a cluster. So make sure multicast traffic is enabled in the WebLogic Server network.

Tips

1. If you use Web Server proxies, configure at least two, to avoid a single point of failure for the cluster.

2. When porting an application from one WebLogic Server to a cluster, ensure that objects stored in an HTTP session are able to serialize.

3. Put at least three WebLogic Server instances in each cluster, so that failure of a server does not stop load balancing of the cluster.

4. You cannot add the admin server to a cluster.

5. Use separate multicast address for each cluster in a network.

6. Servers running in a cluster can listen on different ports from WebLogic Server 7.0

7. If available use separate hardware (NIC) to route cluster multicast traffic by configuring network channels to separate internal cluster traffic from outside client traffic for better performance.

8. Combine frequently accessed applications in one tier of clusters (ex. war and EJB jar) to avoid network traffic.

9. To enable automatic failover of servlets and JSP, use replication technique.

10. In-memory replication is faster than other type of replications.

11. When using in-memory replication, specify the machine information for servers in a cluster.

12. Define replication groups only if you require control over the secondary selection process.

13. Using server affinity wherever possible will improve performance.

14. Use publicly available DNS names to identify the WebLogic Server instances rather than using IP addresses in firewall-enabled environments.

15. If a WebLogic cluster spans multiple sites, the network among the sites must support multicast traffic for cross-site clustering.

16. With this spanning architecture, you must configure the cluster's Multicast TTL value high enough to prevent routers from dropping multicast packets before they reach their destinations.

Securing Admin Console

If you use the admin server to serve applications (or in a single-server domain), do the following for better security:

1. Change the default admin user and password to custom.

2. Change the admin console context root path.

3. Enable domain-wide administration port.

4. Consider disabling the admin console.

If you use an external LDAP provider, store the server boot identity in the embedded LDAP server, and set time-outs on the external LDAP authentication provider. This way, if the external LDAP server is unavailable, you can continue to restart and to serve unprotected data with WebLogic Server. Also before you apply any changes, set the control flag for all authentication providers to OPTIONAL; this prevents a configuration error from causing a production server not to restart.

WebLogic Server provides a custom realm, the NTRealm, based on older security realm APIs, that supports native Windows domain authentication. NTRealm is useful with Windows domains that are not set up to use Active Directory.

Tips

1. Store the server boot identity in the embedded LDAP server.

2. For finer control of a production environment, use Active Directory authentication, rather than native Windows domain (NTRealm) authentication.

3. To prevent denial-of-service attacks, modify the time-out and maximum-size values for the incoming protocol ports (T3, COM, IIOP, HTTP Post time out) on the server.

4. Have a security audit performed by an internal or external auditing group.

Using SSL with WebLogic Server

When using SSL with WebLogic Server, use keystores; storing identity (private keys and certs) and trust (CA) in files is deprecated. Migrating from an earlier version might require you to create keystores from private keys, certs, or trust files.

If the network that connects WebLogic Server in a domain is not trusted, enable SSL on each server in the domain, so that LDAP replication between the admin server and managed servers uses SSL connections. Enabling an administration port in the domain requires that all servers use SSL.

The default WebLogic installation represents exportable-strength SSL implementation (the maximum SSL strength is 512-bit keys with 40-bit bulk encryption). Key lengths longer than 512 bits require a domestic-strength SSL license key from BEA. If you use SSL in your production environment, use high-strength SSL. Key lengths of less than 1024 bits are generally considered weak.

SSL hardware accelerators:

Running SSL on the WebLogic servers is a tremendous drain on server resources. By offloading SSL processing, the resources can be applied to WebLogic functions. Web servers, load balancers, firewalls, or switches can handle SSL processing.
Filtering them can control incoming connections in WebLogic Server. WebLogic Server provides a default implementation of connection filter that you can configure in the admin console.

Tips

1. In production, do not use the sample SSL certificates that are provided with WebLogic.

2. To avoid compromising application security, install and configure server-specific SSL
certificates and enable hostname verification on production servers.

3. Use SSL with WebLogic Server only if it is necessary. SSL degrade performance.

4. To control the types of connections accepted by WebLogic Server instances, use connection filters.

5. Use load balancer with built-in secure sockets layer (SSL) support, or run WebLogic Server on a machine that has SSL hardware, with Java Cryptography Extension (JCE)

To recover the administrator password in a WebLogic domain

When using the default authenticator, if you have not modified the global admin role (which, by default is granted to the administrators group), you can recover the administrator password in a WebLogic domain.

To recover the administrator password in a WebLogic domain:

1. At the command line, change directory to the domain and run the setEnv script to set the PATH and CLASSPATH.

2. Backup the existing DefaultAuthenticatorInit.ldift file in a different directory.

3. java -cp D:\bea\weblogic700\server\lib\weblogic.jar weblogic.security.utils.AdminAccount adminuser weblogic . (Be careful: there is a dot at the end of the command).

4. rm myserver/ldap/DefaultAuthenticatormyrealmInit.initialized

5. rm boot.properties (if any)

6. Reboot the admin server with "adminuser" as administrator userid

7. After the server has successfully booted, delete the new DefaultAuthenticatorInit.ldift file and replace it with the backed up file. If you don't perform these steps in the correct sequence or if you create a DefaultAuthenticatorInit.ldift file by hand, a cleartext password may be available.

Security Vs Weblogic Domain

Never use development mode for production servers; development mode relaxes the security constraints for all servers in a domain. When using compatibility security, disable guest logins in production, so that guest logins cannot be used to access WebLogic resources in a WebLogic Server domain.
When you are creating a security policy, if inherited policy statements are present in the Inherited Policy Statement box of the Policy Editor page, the new policy overrides them. Changing a security policy defined in a J2EE deployment descriptor requires redeployment; changing an embedded LDAP policy in the admin console is dynamic. Configure additional administrative users to roles such as admin, deployer, monitor or operator.
SerializedSystemIni.dat contains hashes for the passwords in a domain; ensure that you store a copy of this file in a safe place. Give read privileges for SerializedSystemIni.dat only to the WebLogic system administrator account. If you lose the administrative password, and the boot identity is not stored in the form of boot.properties file, you cannot restart servers.
Tips

1. Store the encrypted boot identity of the user who has privileges to start WebLogic Server in the boot.properties file.

2. BEA recommends using security roles (rather than users or groups) to secure WebLogic resources; first assign users to groups, then create role statements.

3. Do not install or run WebLogic Server software as root. If you must bind to a privileged port, use post-bind UID or post-bind GID in the WebLogic machine configuration.

4. Set the ownership of the WebLogic installation and applications directory for access only by the user account that runs the server.

Stateless Session EJB

A stateless session EJB free pool improves performance and throughput as beans are created at server startup or deployment time. WebLogic Server uses a cache of bean instances to improve the performance of stateful session EJBs. The cache stores active EJB instances in memory so that they are immediately available for client requests.
Using application-level/combined cache will result in reduced fragmentation, better utilization of memory and heap space. But the use of application-level/combined cache is limited to entity EJBs in an enterprise application. For an application that requires high throughput, use bean-level caching. Bean-level caching is effective because tasks do not compete for control of the one thread of control in a combined cache.

To make use of WebLogic provided optimization of calls made to EJB components within an application, set to true.

The same can also be achieved by writing local interfaces for EJBs for access within the same enterprise application.

Concurrency strategies for entity EJBs include:

Database:Improves throughput by deferring to database (for EJB 1.1 and 2.0, this is the default and recommended mechanism)

Exclusive:Avoids deadlocks; use it only if a high level of consistency is required on non-clustered servers

Optimistic:No lock will be held in the EJB container or database during transaction. But the EJB container ensures that the data being updated by a transaction has not been changed.

Read-only:Container does not attempt to save a bean's state at the end of a transaction; use this for EJBs that do not make any change to persistent data. With the read-only strategy, use to invalidate cached bean data in the container; this updates the data from the persistent store when a timeout occurs.

Tips

1. Consider the number of execute threads, to configure maximum number of beans in the free pool.

2. To limit the memory used by a stateful session EJB, set the maximum number of beans that can reside in the cache (max-beans-in-cache).

3. Too small cache causes frequent activation and passivation.

4. Too large a cache wastes memory.

5. LRU algorithm keeps a bean in the passive state after it passes the ideal number timeout seconds.

6. To avoid the associated overhead of passivating stateful session EJBs, use the not recently used (NRU) algorithm

7. Local interfaces for EJBs provide optimized access for server-side EJB clients.

8. Combined cache enables the administrator to tune just one cache, rather than multiple caches, in weblogic-application.xml.

9. Message-driven beans that use container-managed transactions must use XA connection factories.

Deployment Descriptor Editing

Changing the deployment descriptor of a J2EE application takes effect only when the application is redeployed. The WebLogic admin console provides a way to change some deployment descriptor attributes without redeploying the application. To take advantage of this feature, you must to deploy the application in exploded directory structure (non-archived format), when the domain is running in development mode.
To change descriptor values of the application after deployment (as exploded format) go to Web Application Module > Your Application > Configuration tab > Descriptor tab.

Tips

1. Use tools provided with WebLogic Server to generate and edit XML deployment descriptors.

2. WebLogic Builder generates descriptors; it includes an interface for editing descriptors.

3. DDInit is a command-line utility for generating deployment descriptors for WebLogic Server applications.

4. ddcreate is an Ant task that can be used for creating deployment descriptors for enterprise applications.

Precompiled JSP pages and EJBs

Production and test deployments should include precompiled JSP pages and EJBs (use weblogic.appc or weblogic.jspc/weblogic.ejbc with earlier weblogic versions). They can catch compile-time errors in applications long before you deploy them. Also offline compilation validates the deployment descriptors for compliance with current specifications. Deploying compiled applications reduces deployment time and subsequent server restart time. Development deployments intended for use on the developer's workstation can use on-the-fly compilation.

Tips

1. To precompile JSP files during application deployment or server startup, enable the precompile parameter in weblogic.jar.

2. To disable pagecheck and recompilation at runtime in a production environment, set pageCheckSeconds to -1.

3. You can use weblogic.appc or weblogic.ejbc (deprecated) to compile EJBs outside the server VM. This reduces the subsequent server restart time.

4. Use the weblogic.Deployer utility, or its associated Ant task, wldeploy, in scripts to automate deployment in production environments.

Enterprise Application (EJB)

WebLogic optimizes EJB access, if the client is within the same enterprise application classes and libraries can be shared across all archive applications within the enterprise application. So consider creating enterprise archives rather than deploying related applications independently. Also Enterprise-wide settings can be used, rather than multiple local settings in deployment descriptors. Create JDBC resources in the WebLogic Server domain, using the WebLogic console, rather than employing the weblogic-application.xml technique.
Tips

1. Avoid deploying EJB archives and related Web applications as separate independent applications in WebLogic Server.

2. Improved runtime performance can be achieved when Web components access EJB components within the same enterprise application.

3. The enterprise can be deployed as one deployment unit.

4. Do not place application-specific classes or JAR files in the system classpath (to avoid having to restart the server for reloading them).

5. When using WebLogic Server 8.1, use the new APP-INF/lib and APP-INF/classes directories in the enterprise-application directory structure, to simplify the packaging of utility classes and utility archives.

Deployment/Redeployment

Deployment

WebLogic Server allows you to store deployment units either as a single archive file, or as an exploded directory that contains the same contents of the archive file. An archive file is a single file that contains all of an application's or module's classes, static files, directories, and deployment descriptor files.

Deploy user applications on managed server instances. This separates the administration application (console) and the domain configurations from user applications. Avoid using automatic deployment of applications in production and multiple-server environments. Running the WebLogic domain in "Production Mode" will disable the automatic deployment in production. If you create scripts for deploying applications as a part of an overall build, consider using the wldeploy Ant task.

If you deploy an application (or module) with the On Future Redeploys option set to Ignore Roles and Policies From DD one or more times before setting it to Initialize Roles and Policies From DD, you can set security policies and security roles using the admin console. But these changes using admin console will override security specified in deployment descriptors.

Tips

1. Use production mode to run production applications.

2. Avoid deploying user applications on admin server instance.

3. To specify the server's default Web application, use an empty context-root element or an element with a value "/" in the weblogic.xml or application.xml file.

4. Changing security policies for an application after deployment in the admin console overrides the policies in the deployment descriptor.

Redeployment

Once you deploy an application, you can redeploy the application itself or selected parts of the application. Redeploying an entire application involves unloading all its classes and then deploying the application again with the changed files. Redeploying an application in production is a serious undertaking that can affect performance, so plan application updates carefully.
If a Web application is in production and in use, redeploying causes WebLogic Server to lose all active HTTP sessions. HTTP session can be restore by turning a special property ON in the WebLogic specific deployment descriptor file (weblogic.xml).

Tips

1. If you have modified only static files, it is possible to refresh them without redeploying the entire application.

2. Use command-line option to partially redeploy an expanded application (weblogic.Deployer … -redeploy …).

3. For changing deployment parameters without changing the application, use alternate deployment descriptors.

4. To simplify re-distributing application archives to multiple WebLogic Server instances during redeployment use stage mode deployment.

5. A managed server with all application staged can be started and be made fully functional in independence mode if admin server is not available.

Flow Control

After defining a JMS server, you can configure one or more connection factories to create connections with predefined attributes. With the Flow Control feature, you can direct a JMS server or destination to slow down message producers when it determines that it is becoming overloaded.
Tips

1. To slow down overactive producers that are overwhelming a destination from outside the WebLogic Server process, configure flow control.

2. Using flow control inside the server causes server threads to slow down; be careful.

Message Paging

Persistent and non-persistent messages consume server memory unless paging is enabled. Message paging is the process of freeing server memory for persistent and non-persistent messages, as even persistent messages cache their data in memory. A paged-out message does not free all of the memory that it consumes. The message header and message properties remain in memory for use with searching, sorting, and filtering. Messages sent in a transacted session are eligible for paging only after the session is committed. Before that, the message is held in memory.
Tips

1. If JMS paging is enabled and no paging store is configured, WLS 8.1 creates a paging store automatically, but configuring a paging store explicitly is recommended (you can specify the location of the store).

2. JMS paging increases the amount of message data a WebLogic Server instance can contain without requiring an increase in the JVM heap size.

3. Although paging does degrade performance, its effect is less when paging non-persistent messages than when paging persistent messages.

4. Always configure quotas for WebLogic JMS Servers; quotas prevent messages from overflowing server memory.

JMS

WebLogic Server JMS architecture allows multiple JMS servers to be created in a WebLogic domain. But each JMS server can only be instantiated (targeted) on one WebLogic Server as it is an "exactly-once" service. Multiple destinations can be hosted on a JMS Server. Persistent storage (disk-based file or JDBC-accessible database) can be configured for storing persistent message data.
If one JMS store must be shared across multiple destinations, configure multiple destinations to reside on one JMS server. But to use separate persistent stores for each destination, create them under multiple JMS servers.

Tips

1.Enabling a direct-write synchronous write policy for the JMS file store frees the virtual-memory (VM) heap, but direct-write can significantly improve performance only if there are few concurrently active JMS clients.

2.Isolate file stores on separate disks, or even on separate disk controllers.

3.To make the file store highly available, you can use Storage Area Network (SAN), a multi-ported disk, or disk-mirroring technology.

4.Do not associate a connection pool that uses an XA JDBC driver with a JMS JDBC store, because JMS JDBC store does not support XA resource drivers (WebLogic JMS implements its own XA resource).

5.Using Expiration Scan Interval to scan destinations for expired messages frees up VM, but too-frequent scanning can increase scanning overhead; ensure that you tune this optimally.

6.Set MessagesMaximum on connection factories, to tune the size of asynchronous message pipelines.

7.To avoid message buildup, set the Time To Live attribute, at the connection factory level.

8.Disable default JMS connection factories; configure application-specific JMS connection factories for production.

9.For load-balancing JMS messages across physical destinations that are configured in different JMS servers, configure a distributed destination.

10.When deploying distributed destinations, use similar settings for each JMS server and member destination in a cluster.

JDBC

Pooling JDBC connections to the database in WebLogic Server improves application performance. The connection pool eliminates the need for creating new database connection for each application. The JDBC Connection Pool provides ready-to-use connections to your database.
The number of connections to the database can be dynamically resized when using a connection pool. But trying to increase the number of JDBC connections during a peak load situation can worsen the situation, because database connection creation is expensive.
Connection pool also increases the performance by caching prepared statements and callable statements for reuse. Reusing prepared statements and callable statements reduces CPU usage on the database server.
Avoid draining processing power on the WebLogic Server machine by separating other applications on a separate machine or hardware; use a dedicated machine for databases.
Tips
1. If possible, size database connection pools so that they never increase the number of connections: set Initial Capacity equal to Maximum Capacity.
2. Set the Maximum Capacity of the connection pool at least equal to the Execute Thread Count.
3. Configure Inactive Connection Timeout to specify how long (in seconds) a connection can be inactive before it is reclaimed to the pool.
4. The connection leak profiling option shows leaked connections from the connection pool. BEA recommends that you do not use this option in production; it uses extra resources and typically slows connection-pool operations.
5. Use Test Reserved Connections only if you can afford the overhead of testing connections as part of normal request processing.
6. Avoid using a production table for "Test Table Name", use a dummy table (ex. dual).
7. Use the statement cache to improve performance of prepared and callable statements.
8. Select the least-recently-used (LRU) algorithm for the cache; this removes rarely used statements from the cache.
9. Connection Creation Retry Frequency can be used to retry for establishing connections to the database, if database is not reachable when creating connection pool or starting WebLogic Server.
10. If database is restarted when WebLogic Server is running, Test Frequency can be increased from 0, so that all the connections are closed and reopened to re-establish valid physical connection. After all the connections are recreated changing it back to 0 will disable the testing.
11. When using DataSource objects for a connection pool, use the Honors Global Transaction option to create a TxDataSource.
12. The only time you should use a non-Tx DataSource is when you want to do some work on the database that you do not want to include in the current transaction.
13. When configuring a connection pool to use with WebLogic JMS JDBC Store, use non-XA database drivers.

Logging

Log records information about events such as the startup and shutdown of servers, the deployment of new applications, or the failure of one or more subsystems. The log messages include information about the time and date of the event as well as the ID of the user who initiated the event. Each WebLogic Server instance can maintain a server log, an HTTP access log, a JDBC log and a JTA transaction log.

Tips

1. To prevent restarting a respective server if the log file grows too large, enable log rotation.

2. Consider rotating the log file by size, rather than by time in production, because, with the time in production option, the file can grow large very quickly.

3. If you are not debugging interactively and the WebLogic Server is started in the background (Windows or Unix), use these commands to redirect stdout and stderr messages to a file:

• -Dweblogic.Stdout="stdout-filename"
• -Dweblogic.Stderr="stderr-filename"
  

4. In production, you can avoid extra file I/O on the server if you do not enable WebLogic servers to create a JDBC log.

5. When using node managers to start managed servers, the node manager captures and stores the server's stdout to a file. The Administration Console can be used to view the contents of that file.

6. Audit the WebLogic Server log file frequently, to become familiar with normal operation, so that you can readily identify abnormal log entries.

Scripting Administration Tasks

To create scripts to manage domain configuration:

1. Use weblogic.Admin utility command BATCHUPDATE, which runs a sequence of commands specified in a batch file.This command uses one JVM to run all the listed commands.

2. The -Dweblogic.system.BootIdentityFile option lets you avoid hard-coding a username and password in your text script.

3. To build logical branching in operating-system scripts, evaluate the return code of a weblogic.Admin command using :

• %ERRORLEVEL% (Windows)
• $? (bash shell)
  

4. The -adminurl option of weblogic.Admin retrieves configuration MBeans and runtime MBeans of a managed server from the admin server.

5. Modifying the config.xml file directly is not recommended.

6. If you must modify config.xml:

• First, make a backup of the original file before editing
• Use XML editors to avoid making typos
• Avoid editing the file while the admin server is running
  

7. Use the wlconfig Ant task for scripting configuration information and integrating it into the overall build process.

8. Use WebLogic Scripting Tool (WLST) for changing domain configuration when administration server is running and also when it is offline. (dev2dev.bea.com)

9. WLST provides a powerful shell interface to WebLogic Server and it uses Jython for scripting language.

10. You can use also third-party solution, such as the WLShell utility, to manage configuration. (www.wlshell.com)

11. WLShell provides a powerful Unix-like shell interface to WebLogic Server; it uses file system analogy for WebLogic Server MBeans.

Backup and Recovery

To migrate or recover WebLogic domains in case of failures, periodically backup of the entire domain directory tree from the administration server machine. This way, you can recover from a hardware or system failure by merely restoring the domain directory and restarting the admin server.

In case of an admin server crash, the admin server retains information about all of the running managed servers in the running-managed-servers.xml file. When restarted, the admin server reads this file and tries to contact any managed servers that were previously running. Discovery mode might increase the admin server startup time if no managed servers are running, but always use the discovery mode (by default, it is on), so that the admin server reconnects with any managed servers, if they are already running.

Some important files to be watched/backed up periodically from administration server machines are:

1. config.xml - Domain configuration repository.

2. config.xml.booted - Good backup of domain configuration repository from a successful boot.

3. boot.properties - Encrypted username and password for booting administration server.

4. running-managed-servers.xml - This is a list of dependent managed servers currently running. This file is used for discovering managed servers if administration server gets restarted while the managed servers are running.

5. domain/configArchive/ - Contains the copies of the Domain Configuration Repository files. When updated using administration tools administration server copies the old config.xml to this directory.

6. domain\adminserver\ldap\ldapfiles - Embedded LDAP data files currently being used by the domain's administration server.

7. *.ldift files - These file can be used for initializing the WebLogic Domain Embedded LDAP server back to when the domain was created.

8. domain/adminserver/ldap/backup/EmbeddedLDAPBackup.zip - Backup of the WebLogic domain embedded LDAP server. Embedded LDAP is used to store users, groups, roles, policies by the default security realm, myrealm's security providers.

9. Batch/Shell Scripts - setEnv.cmd/sh, startWebLogic.cmd/sh, startManagedWebLogic.cmd/sh.

WebLogic Server Shutdown Process

Abnormal JVM termination can cause resources such as sockets or segments to lock. Killing or terminating WebLogic Server process from the operating system is considered and abnormal termination.

WebLogic Server can be gracefully shutdown by:

• Using administration Console 'Graceful Shutdown" hyperlink
• Using weblogic.Admin SHUTDOWN… command
• Using JMX by invoking stop method on ServerMBean class

Tips

1. To shut down the production server gracefully, use the WebLogic admin console or the weblogic.Admin utility.
   
2. Graceful shutdown does not abnormally terminate user sessions; it waits for HTTP sessions to complete or time out.
   
3. WebLogic server can also be configured not to wait (ignore Session During Shutdown option).
4. The graceful-shutdown timeout is configurable; by default the server waits indefinitely for shutdown to complete.
   
5. If the server is not responding for graceful shutdown request or to bring down the server while the server is waiting for inflight session (in standby state), use 'Force Shutdown' option.
6. If configured as a daemon, make sure the rc scripts have the stop method configured to gracefully shutdown the server in case of machine reboots and halts.
   
7. If Node Manager is configured, termination the Node Manager will not stop the respective servers started by them. Managed server have to be stopped separately.

Node Manager

Use the Node Manager feature provided by WebLogic Server to start managed servers automatically, or to restart failed managed servers. Node Manager provide remote start of managed servers for administrators from either administration server or from command line (weblogic.Admin START…). This can be achieved by communicating to the administration server and without relying on OS specific remote login features.

Also in addition to starting and killing managed servers, Node Manager can also monitor the health of the servers started by it. In case of failure if configured Node Manager can automatically restart the managed servers.

Tips

1. When using the Node Manager, configure all remote-start attributes for a managed server explicitly, rather than relying on the node manager's environment for a managed server's configuration.

2. Node Manager receives it request only from administration server. It is not possible to restart a managed server remotely through Node Manager when administration server is not available.

3. Configure Node Manager as a service/daemon.

4. Enable automatic restart of managed server.

5. Configure auto kill if failed to bring down a failed instance before Node Manager tries to restart it.

6. Node Manager running on a machine can be share by multiple managed servers running on that machine.

7. A Node Manager can also be shared by managed servers from multiple domains running in the same machine.

Startup and Shutdown Classes

WebLogic Server can be configured to invoke classes during boot and graceful shutdown process. Startup classes are loaded and executed after the server initializes all the subsystems and before it could open up the port for client access. Similarly shutdown classes are loaded before the server starts the graceful shutdown process. Unlike application files startup and shutdown classes have to be manually made available in the deployed server's local classpath.

Tips

1. Make the server-level startup classes available in the system classpath of the deployed WebLogic Server instance during startup.

2. The admin server to managed servers in a domain cannot deploy classes that are present in the system classpath automatically; application-level classes can be distributed by the admin server to targeted servers in a domain.

3. Application-level startup classes reload when the application is redeployed.

4. Server-level startup classes cannot be dynamically reloaded; they can be reloaded only during the respective WebLogic Server restart.

5. Use application-level startup classes, rather than defining server-level startup classes.

Weblogic Server Start-up

The administration server loads all the configurations from the configuration repository (config.xml). All dependent managed servers must connect to a running admin server during startup. Independent managed servers can load the configuration from a local repository (msi-config.xml)

If WebLogic runs in a computer that has the Unix operating system, you can assign a UID or GID for the WebLogic Server process to bind after the computer carries out the privileged startup actions as a root user. If the WebLogic Server user is binding to higher-order ports(>1024), it does not require root permission.

Tips

When writing a script to automate server start-up, consider these factors:

1. In a domain, the administration server must be started before any dependent managed servers.

2. When starting a managed server as a dependent server, it connects to the admin server to download configurations.

3. When starting a managed server as an independent server, verify that the msi-config.xml file is stored in the server root directory.

4. In Unix use 'nohup' for run the WebLogic Server start script to keep the server running in the background even if you logout.

5. Create a separate WebLogic Server user for installing and starting servers in OS.

6. Store the encrypted user identity, use the boot.properties file to avoid hard coding user identity in startup scripts.

7. Use WebLogic UNIX machine configuration to post bind a UID or GID when binding servers to low order ports (<1024),>

8. To enable automatic restart of the admin server in a WebLogic domain during machine restarts, use the daemon process features provided by the operating systems.

• Windows services
• UNIX daemon processes.

9. The admin server in a domain can be made as a service when you create the domain using the domain configuration wizard.

10. Also the installservice.cmd and uninstallservice.cmd scripts, located in the domain folder can be used to add or remove a service from Windows Service Control Manager (SCM).

11. If administration server and managed server share the machine, configure OS-level service dependency between the administration server process and managed server processes.

12. Configure the rc scripts to add the WebLogic startup command at the right run-level.

Creating WebLogic Configuration/Domain

A domain is a logically related group of WebLogic Server resources that you manage as a single administrative unit. A domain saves all the resource and application information in a XML-based configuration repository. To deploy and run applications on WebLogic Server first create a domain.

The domain configuration wizard is the recommended tool for creating new domains. If you are scripting the creation of domains, the silent mode of the domain configuration wizard is the recommended tool. WebLogic Server domains can be created either from one of the "out of the box" (OOB) domain templates provided or from custom domain templates.

For creating custom domain templates, use the configuration template builder, which is a stand-alone Java application that lets you create custom configurations and extensions. You can use the configurations and extensions to create and update domains.

The domain configuration wizard has these properties:

1. The wizard guides you through the process of creating or extending a domain for a target environment.
2. The wizard can use an OOB predefined domain template or a custom domain template to create or extend a domain.
3. The wizard creates the config.xml file, sets up basic security, builds start-up scripts, and so on.
4. The wizard can be started in graphical, console or silent mode.
To start the wizard in graphical mode, run one of these commands: (If you want to create JAR configuration template file)

%BEA_HOME%\weblogic81\common\bin\config.cmd
%BEA_HOME%\weblogic81\common\bin\config.sh

The domain configuration template builder has these properties:

1. The wizard guides you through the process of creating or extending configuration template (JAR file)
2. The configuration wizard can use the created configuration (domain) template to create a domain.
The configuration template builder can be started only in graphical mode.

To start the configuration template builder, run one of these commands:

%BEA_HOME%\weblogic81\common\bin\config_builder.cmd
%BEA_HOME%\weblogic81\common\bin\config_builder.sh

Tips

1.If WebLogic Domain/Configuration is distributed on multiple physical machines, then the domain configuration wizard should be run only on the administration server hardware (machine).
2.Running the domain configuration Wizard in managed server hardware is not required.
3.Create WebLogic domains outside WebLogic Server installation directories (By default domains are created in %BEA_HOME%\user_projects\domains )
4.When creating a startup script for the administration server, if the script (startWebLogic.cmd/sh) does not invoke the weblogic.Server class from within the domain directory, use this command line option to specify the location of domain -Dweblogic.RootDirectory=path
5.When starting managed servers (startManagedWebLogic.cmd/sh), if set -Dweblogic.RootDirectory will be set as the server root directory. And will be used for storing files such as log files and managed-server independence (MSI) files.