The startWebLogic script does the following:
- Sets environment variables by invoking
DOMAIN_NAME/bin/setDomainEnv.sh(setDomainEnv.cmd on Windows), whereDOMAIN_NAMEis the directory in which you located the domain. - Invokes the
java weblogic.Servercommand, which starts a JVM that is configured to run a WebLogic Server instance. When the server successfully completes its startup process, it writes the following message to standard out (which, by default, is the command window):<Notice> <WebLogicServer> <BEA-000360> <Server started in RUNNING mode>
- Or if it fails, you will get the following message:
Critical><WebLogicServer>….<BEA-000362><Server failed. Reason: … stackdump or *************************************************************************** The WebLogic Server did not start up properly. Exception raised: Name Exception + some details See preceding log message for details. ************************************************************************
The startWebLogic script can be found in the Domain directory. This one invokes the real one, which is under /bin in the Domain directory.
When you issue the script on Linux, it's started in the foreground; that means if you terminate the shell 44 or logout, your WebLogic shuts down also.
A better way of starting on Linux is using the nohup in combination with the script.
A good option is:
nohup ./startWebLogic.sh > /dev/null &2>1
Where nohup gives a sign to the process to run even if the user logon (Operating System user of the WebLogic installation) gets terminated. Be aware to start it is as the owner of the WebLogic software, or at least with enough permissions to start/stop.
The> /dev/null &2>1 is used to redirect the STDOUT, and STDERR into /dev/null, a sort of trash within Linux.
Using this command can only be executed when running your WebLogic Server in development mode, because other than the start-scripts, it does not recognize patch levels, server environments, and so on.
First you set your environment with<WL_HOME>/server/bin/setWLSEnv.sh. Then run the command:
java weblogic.Server
Usually, run java weblogic.Server with some additional options, as seen in the following block of code:
When you configured a WebLogic domain on Windows using the configuration wizard, the start script was made available on the start menu.
This is in fact the startWebLogic.cmd startup file, and shortcuts have been made for the domain start and stop scripts in the Windows Start menu.
Although WLST and the Node Manager will be discussed in Chapter 13, WLST: Makes an Administrator's Life Easier and Chapter 5, Managed Servers and the Node Manager, we can have a short overview here, on how to control your environment using these features.
WLST is a tool based on the Python programming language, for WebLogic used to access configurable items programmatically, so also stopping and starting the environment. If you have a lot of WebLogic environments to control, you can automate these with WLST to do some tasks for you; that is, it is practical to automate all the operational activities for production environments as the developers will not be involved in production operational activities. It is ideal for the support team or operational team that will maintain the environment; as said, it will be discussed in Chapter 13,WLST: Makes an Administrator's Life Easier.
Here is an example of starting WebLogic in WLST without the Node Manager.
First run the following code:
<WL_HOME>/common/bin/wlst.sh à this will set your environment setting for using WLST to connect to the WebLogic domain and starts the actual WLST prompt. WL_HOME is the WebLogic Server home directory.
Then, when the offline WLST prompt appears, type the following block of code:
wls:offline/>
startServer('AdminServer','mydomain','t3://localhost:7001', 'weblogic','weblogic','<WL_DOMAIN_DIR>','true')
The following is an example of how to start using the Node Manager:
- Start Node Manager (for more details, see Chapter 5,
- Connect WLST to Node Manager
nmConnect('weblogic', 'weblogic', 'localhost', '5556','mydomain','<WL_DOMAIN_DIR>')
Now, start the Administration Server:
wls:/nm/mydomain>nmStart('AdminServer')
When the WebLogic Administration Server has been started, all other WebLogic Managed Server instances (for more on Managed Servers, see Chapter 5, Managed Servers and the Node Manager) can be started using the Administration Console. This is only possible if the Node Manager is started and running on the specific host. On the control tab of the servers, you can find the Stop and Start buttons. For more information about how to use the Administration Console, have a look at Ease of use: the Administration Console section later in this chapter.
If you start up your WebLogic for the first time, there are some important things to know:
Are you starting up in Development or Production mode? When starting up in Production mode, the first time it will fail: the server will not startup if the boot.properties file is not present. However, WebLogic will ask on the console for the user/password for the admin user. You can also specify the user/password in the script/command line.
- This is because the startup requires some security/identity parameters, stored in a file called
boot.properties. This will give an entry in the logs. - This file contains the username and password of the WebLogic Admin user, and is stored in the
<WL_DOMAIN_DIR>/servers/AdminServer/security. - However, the first time you startup, this directory has not been created yet, so you will have to accept the first time startup failure. After the failure you create the directory security under
<WL_DOMAIN_DIR>/servers/AdminServer, and create a file namedboot.properties. Of course, you also could perform this action before starting. - Content of the
boot.propertiesfile:username=<name of WebLogic Admin ( usually weblogic)> password=<password>
- Now save this file and issue the startup sequence again. The contents of the
boot.propertiesfile will now be encrypted, upon successful startup.
Besides creating the file on the OS, you can also create it with the java weblogic.Server command.
For example, the following command starts an Administration Server named myAdminServer and creates a boot identity file:
java -Dweblogic.management.username=weblogic -Dweblogic.management.password=welcome1 -Dweblogic.system.StoreBootIdentity=true -Dweblogic.Name=myAdminServer weblogic.Server
In case you don't want to use the boot.properties file or enter the username/password during server startup, and if security is not a concern, you can add the following values in the server startup script.
-Dweblogic.management.username=username -Dweblogic.management.password=password
Like in startWeblogic.sh:
-Dweblogic.management.username=<weblogic username> -Dweblogic.management.password=<weblogic password>
However, keeping clear-text passwords is not a very good practice.
You can create the boot.properties file by keeping the following values in the startup script:
-Dweblogic.management.username=username -Dweblogic.management.password=password -Dweblogic.system.StoreBootIdentity=true
This will create a boot.properties file under the AdminServer/security directory.
Once the file is generated and in case you don't want to keep clear-text passwords in startup scripts, you can remove the added options.
The boot.properties file can be placed at a user-defined location by keeping the following flag in startup script:
-Dweblogic.system.BootIdentityFile=filename
With this option, boot.properties file can be renamed with some other name such as:
-Dweblogic.system.BootIdentityFile= <Domain home/myboot.txt>
After restarting the AdminServer, it had encrypted my password and username in myboot.txt file.
In case you want the boot.properties file to be removed, the following option can be used:
-Dweblogic.system.RemoveBootIdentity=true
This can be used even when you have specified a custom boot.properties file.
If you have specified both the options:
--Dweblogic.system.BootIdentityFile=<Domain home/myboot.txt> - Dweblogic.system.RemoveBootIdentity=true
then after a start of Admin Server, myboot.txt will be deleted just in case you are not sure what is Admin Server username and password.
Every time you try to manipulate a WebLogic server, it ends up in some kind of state after your action. These states can be:
- STANDBY
- STARTING
- ADMIN
- RESUMING
- RUNNING
In the following diagram you see the several server instance states:
There are some different shutdown options available to stop WebLogic Server:
Graceful:
Stop the server from the Administration Console, on the Control Tab in the Servers Health section.
This also closes the Administration Console, so restarting requires a command-line action.
Abrupt:
Press Ctrl + C to interrupt the startWebLogic program when using it in the foreground (so, without nohup) or kill it to filterout the process number with ps ef | grep <PID>, and then kill it.
Usually, your applications are running on Managed Servers, not on the Administration Server; so even though this is abrupt, it is not disruptive.
Another way to stop is to use the stopWeblogic.sh script, which you can find in the Domain home, under /bin. For Managed Server instances, you should use stopManagedWebLogic.sh.
Another way to stop your WebLogic domain is to use WLST and the node manager. This will be discussed in Chapter 13,WLST: Makes an Administrator's Life Easier.
One of the most important items for an administrator is the Administration Console (or here) Administration Console. It's the central point where all tasks come together, such as:
- Monitoring
- Control
- Configuration
- Security
- Deployment of applications
- Diagnostics and logging
The Administration Console can be accessed after startup at http://< weblogicserver><port>/console. The login screen appears. Enter the WebLogic credentials and you're in! The following screenshot is an example of the same:
When you run WebLogic Server in Production Mode, the Change Center will be active. This keeps track of who does what and locks when an Administrator performs a session. The console gets locked for that user and can only be changed unless the session has been activated or released. This mechanism prevents other users logging in to the console and doing configuration changes before you are finished.
First you must click on the Lock & Edit Button, and then you can do the necessary work. When it's completed, you click on Activate Changes.
Now, click on the View changes and restarts link on the second tab, to see what items should be restarted.
Also on the left, you can find a navigation tree called the Domain Structure. In here, you can access all configurable resources within the WebLogic Server, such as:
- Server: such as Administration Server, Managed Servers, and Clusters
- Services: such as JDBC and JMS
- Deployments: Applications, Adapters, and Libraries
- Security: Providers, Encryption keys, and wallets
- Diagnostics and Logging.
The System Status panel reports on the number of information, error, and warning messages that have been logged. You can view these messages in the server log files, which you can access from the Administration Console at Diagnostics | Log Files.
In the taskbar, you can track your previous navigation using the Breadcrumbs, so you can jump back two or three steps before.
For companies, such as FinanceFiction, which have strict security, administrators are only allowed to use the console if needed. Otherwise it should be set to off. Here's how to disable or enable it.
To disable:
- Select your domain name in the Domain Structure panel of the console.
- Select Configuration | General, and click Advanced at the bottom of the page, and untick Console Enabled.
- To enable, you can use WLST. The following code shows how to do it:
connect("username","password") edit() startEdit() cmo.setConsoleEnabled(true) save() activate() The following attribute(s) have been changed on MBeans which require server re-start. MBean Changed : com.bea:Name=mydomain,Type=Domain Attributes changed : ConsoleEnabled Activation completed disconnect() exit()
An administrator can separate the WebLogic Admin Server port from its administration tasks. For this you can enable the Administration Port.
With the Administration Port enabled:
- The console is only accessible over a non-standard port (which should not be available from outside your firewall). You have to use SSL.
- You get a dedicated administration listen thread.
- Administrative requests over any port other than the Admin Port are rejected.
So, by using the Admin Port, you protect your console and get several other benefits. The Admin Port will not be on port 80 or 443 and will thus not be available outside your firewall. Technically, you could open the Admin Port on the firewall but then you're back in the same boat. Also, anybody who tries to do an administrative request over any other port will find their request rejected.
Another feature is that your interaction with the console has to be over SSL, which protects your data as it transits the wire.
When you install WebLogic Server out of the box, the configuration shipped with it is pretty standard. As an administrator, you should be a guardian of the overall performance. Sure, there are many causes which can drill down performance, availability or whatever, but here are some general steps to start with. Following these rules may save you a whole lot of work afterwards.
In WebLogic Server, all requests, whether related to system administration or application activity, are serviced through a single thread pool. To avoid managing overloaded requests, you can throttle the thread pool by defining a maximum queue length. If the configured value has been reached, WebLogic Server will refuse requests, except for requests on the administration channel. In this setup, WebLogic Server will not run out of resources. Think of hackers who will bombard many requests at a time in order to overload your system. Limiting it will block any other access up to the value you have set.
Set the Shared Capacity for Work Managers field in the Administration Console (see Environments | Servers | server_name | Configuration | Overload).
You should limit the number of active HTTP sessions based on detection of a low memory condition. This is useful to avoid out of memory exceptions. WebLogic Server refuses requests that create new HTTP sessions after the configured threshold has been reached. In a WebLogic Server cluster, the proxy plug-in redirects a refused request to another Managed Server in the cluster. A nonclustered server instance can redirect requests to alternative server instances.The Servlet container takes one of the following actions when the maximum number of sessions is reached. If the server instance is in a cluster, the Servlet container throws a SessionCreationException.
Your application code should handle this runtime exception and send a relevant response. To implement overload protection, you should handle this exception and send a 503 response explicitly. This response can then be handled by the proxy or load balancer.
You set a limit for the number of simultaneous HTTP sessions in the deployment descriptor for the Web application. For example, the following element sets a limit of 12 sessions:
<session-descriptor> <max-in-memory-sessions>12</max-in-memory-sessions> </session-descriptor>
To improve application stability, you could implement a system exit when an "Out of Memory" occurs in a certain Managed Server instance. This can be done to add this in the domain config.xml (located in<domain_home/config>).
<overload-protection> <panic-action>system-exit</panic-action> </overload-protection>
To overcome unavailability in this case (when the Managed Server stops working!) you should implement crash recovery with the Node Manager (will be discussed in Chapter 5,Managed Servers and the Node Manager.)
First, what is a stuck thread? WebLogic uses threads to do its tasks. When certain tasks can't be done, because it is waiting for an answer (such as waiting for an answer from a remote database), then at a certain time it stops asking and will be flagged as a stuck thread.
WebLogic Server checks for stuck threads periodically. If all application threads are stuck, a server instance marks itself failed, and if configured to do so, exits change into the Server Instance terminates its work. You can configure Node Manager to restart for automatic failure recovery.
You can configure these actions to occur when not all threads are stuck, but the numbers of stuck threads have exceeded a configured threshold:
- Shut down the Work Manager if it has stuck threads. A Work Manager that is shutdown will refuse new work and reject existing work in the queue by sending a rejection message. In a cluster, clustered clients will fail over to another cluster member.
- Shut down the application if there are stuck threads in the application. The application is shutdown changing it into ADMIN mode. All work managers belonging to the application are shut down, and behave as described earlier.
The following is an example of an application with problems:
"ExecuteThread: '52' for queue: 'default'" daemon prio=5 tid=0x4b3e40b0 nid=0x1170 waiting on monitor [0x4c74f000..0x4c74fdbc] at java.lang.Object.wait(Native Method) at WebLogic.rjvm.ResponseImpl.waitForData(ResponseImpl.java:72) at WebLogic.rjvm.ResponseImpl.getTxContext(ResponseImpl.java:97) at WebLogic.rmi.internal.BasicOutboundRequest.sendReceive( BasicOutboundRequest.java:80) at WebLogic.rmi.cluster.ReplicaAwareRemoteRef.invoke( ReplicaAwareRemoteRef.java:262) at WebLogic.rmi.cluster.ReplicaAwareRemoteRef.invoke( ReplicaAwareRemoteRef.java:229) at WebLogic.rmi.internal.ProxyStub.invoke(ProxyStub.java:35) at $Proxy6.lookup(Unknown Source) at WebLogic.jndi.internal.WLContextImpl.lookup(WLContextImpl.java:341)
To be a proper administrator, you need some tools. There are many tools available, but let's sum up the most important ones:
- Administration Console
- WebLogic Scripting Tool
- config.sh/bat
- Configuration Template Builder
- Apache Ant tasks
- SNMP agents
The Administration Console is a Web application hosted by the WebLogic Admin Server. Through the Administration Console, system administrators can easily perform all WebLogic Server management tasks without having to learn the JMX API or the underlying management architecture. The Administration Server keeps changes to attributes in the config.xml file for the domain you are managing.
The WebLogic Scripting Tool (WLST) is a command-line scripting interface that you use to manage and monitor active or inactive WebLogic Server domains. The WLST scripting environment is based on the Java scripting interpreter Jython.
WLST will be discussed in Chapter 13,WLST: Makes an Administrator's Life Easier.
The Configuration Wizard creates the appropriate directory structure for a WebLogic Server domain, the config.xml file, and scripts you can use to start the servers in your domain. The wizard uses templates to create domains, and you can customize these templates to duplicate your own domains.
You can also use the Configuration Wizard to add or remove services from an existing, inactive domain. It can be executed with a script, config.sh or config.cmd (Windows).
You can use two Ant tasks shipped with WebLogic Server to help you perform common configuration tasks in a development environment. Ant is a Java-based tool. The configuration tasks let you start and stop WebLogic Server instances as well as create and configure WebLogic Server domains.
A tool based on the Simple Network Management Protocol (SNMP). WebLogic Server SNMP agents let you integrate management of WebLogic Servers into an SNMP-compliant management system that gives you a single view of the various software and hardware resources of a complex, distributed system.
A handy API to manage WebLogic subsystems is JMX (JAVA Management Extensions) for monitoring and managing resources. Like other management standards, JMX is a public specification and many vendors of commonly used monitoring products support it.
Some tools are:
- JConsole & JVisualVM shipped with Sun JDK
- Open Source JMX Browsers
- jManage, EJTools JMX Browser, MC4J,
- WLST
- Wraps MBean access for popular operations
- Supports 'basic' JMX access for all MBeans
- From Java
- Java application can use
javax.managementto access MBeans in remote MBean servers
- Java application can use
- FMW Enterprise Manager System MBean Browser
MBeans are configurable JAVA Objects in WebLogic, which can be accessed to change, configure, or control your WebLogic environment.
There are three types of MBeans:
The MBeans are organized in a tree, starting at the domain root (DomainMBean).
Every WLS object (domain, server) and JEE resource (JDBC DS, JMS Queue) is represented by an MBean.
A built-in tool within WebLogic Server is the Deployment API, to deploy applications, adapters, and libraries. Deployment will be discussed in Chapter 6,Deploy your Applications in Oracle WebLogic.
To detect and analyze problems, logging is very important. WebLogic provides many ways of logging; this will be discussed in Chapter 11,Configuring and Analyzing Logging.
WLDF, WebLogic Diagnostics Framework, is a group of components that work together to collect, archive, and access diagnostic information. It gathers diagnostics in real-time.
This will also be discussed in Chapter 11,Configuring and Analyzing Logging.
