WEBLOGIC STORE

WEBLOGIC STORE

Tuesday, December 22, 2009

WebLogic Server Communication in a Cluster:-

WebLogic Server instances in a cluster communicate with one another using two basic network technologies:

IP multicast, which server instances use to broadcast availability of services and heartbeats that indicate continued availability.

IP sockets, which are the conduits for peer-to-peer communication between clustered server instances.
The way in which WebLogic Server uses IP multicast and socket communication affects the way you configure your cluster.

One-to-Many Communication Using IP Multicast
IP multicast is a simple broadcast technology that enables multiple applications to "subscribe" to a given IP address and port number and listen for messages. A multicast address is an IP address in the range from 224.0.0.0 to 239.255.255.255.

IP multicast broadcasts messages to applications, but it does not guarantee that messages are actually received. If an application's local multicast buffer is full, new multicast messages cannot be written to the buffer and the application is not notified when messages are "dropped." Because of this limitation, WebLogic Server instances allow for the possibility that they may occasionally miss messages that were broadcast over IP multicast.

WebLogic Server uses IP multicast for all one-to-many communications among server instances in a cluster. This communication includes:

Cluster-wide JNDI updates—Each WebLogic Server instance in a cluster uses multicast to announce the availability of clustered objects that are deployed or removed locally. Each server instance in the cluster monitors these announcements and updates its local JNDI tree to reflect current deployments of clustered objects. For more details, see Cluster-Wide JNDI Naming Service.

Cluster heartbeats— Each WebLogic Server instance in a cluster uses multicast to broadcast regular "heartbeat" messages that advertise its availability. By monitoring heartbeat messages, server instances in a cluster determine when a server instance has failed. (Clustered server instances also monitor IP sockets as a more immediate method of determining when a server instance has failed.)

How to Monitor the servers ??

# 1) Through Console:-
go to the AdminConsole click on Domains->servers-monitor-
>Health


# 2) Using the weblogic.Admin utiliy:-
java weblogic.Admin -url t3://hostname:port -username
weblogic -password weblogic ms1 GETSTATE


# 3) One more way is form WLST:-


For Ex the following shows how to find the status of
AdminServer in the same way we can find out the state of
other managed servers also:-

wls:/WLS10/serverConfig> state('AdminServer')
Current state of 'AdminServer' : RUNNING
wls:/WLS10/serverConfig>

Monday, November 30, 2009

Ways Of Installations:-

UNIX Based:-

For Graphical Based Installations:-

To start the graphical-mode installation process with .bin installation files follow the steps:-

1.Login to the target UNIX system.

2. Go to the directory that contains the installation program.

3.Launch the installation by entering the following command:-

chmod a+x filename.bin ./filename.bin

where filename.bin is the name of the installation program.

For Example,for WLS 10.3 the name of the net installer file for Solaris is net_wls1031_solaris.bin.

Then you can use Typical or Custom based installtion and proceed as per requirements.

For Console Based Installation:-

To start the console-mode installation process with .bin installation files, follow these steps:

1. Log in to the target UNIX system.

2. Go to the directory that contains the installation program.

3.Launch the installation by entering thefollowing command:-

chmod a+x filename.bin ./filename.bin -mode=console

To complete the console-mode installation process, respond to the prompts in each section by entering the number associated with your choice or by pressing Enter to accept the default. To exit the installation process, enter exit (or x, for short) in response to any prompt. To review or change your selection, enter previous (or p, for short) at the prompt. To proceed to the following window, enter next (or n, for short).

Use '1' or press 'enter' to accept or tp proceed and press '2' for to choose amongst the given options.

Sunday, November 29, 2009

What is CMO(Current Management Object)

WLST online provides a variable, cmo, that represents the current management object. You can use this variable to perform any get, set, or invoke method on the management object. For example, the cmo variable enables the following command:

wls:/mydomain/edit> cmo.setAdministrationPort(9092)

The variable is available in all WLST hierarchies except custom and jndi.

WLST sets the value of cmo to the current WLST path. Each time you change directories, WLST resets the value of cmo to the current WLST path. For example, when you change to the serverRuntime hierarchy, cmo is set to ServerRuntime. When you change to the serverConfig hierarchy, cmo is set to DomainMBean. If you change to the Servers directory under DomainMBean, cmo is set to an instance of ServerMBean.

For Example:-

Changing the Current Management Object

C:\> java weblogic.WLST
Initializing WebLogic Scripting Tool (WLST) ...
Welcome to Weblogic Server Administration Scripting Shell
...
wls:/(offline)> connect('username','password')
Connecting to weblogic server instance running at t3://localhost:7001 as username weblogic ...
Successfully connected to Admin Server 'myserver' that belongs to domain 'mydomain'.
Warning: An insecure protocol was used to connect to the server.
To ensure on-the-wire security, the SSL port or Admin port should be used instead.
wls:/mydomain/serverConfig> cmo
[MBeanServerInvocationHandler]com.bea:Name=mydomain,Type=Domain
wls:/mydomain/serverConfig> cd('Servers')
wls:/mydomain/serverConfig/Servers> cmo
[MBeanServerInvocationHandler]com.bea:Name=mydomain,Type=Domain
wls:/mydomain/serverConfig/Servers> cd('myserver')
wls:/mydomain/serverConfig/Servers/myserver> cmo
[MBeanServerInvocationHandler]com.bea:Name=myserver,Type=Server

Wednesday, November 18, 2009

How to disable confirmation prompt ??

If you are using WebLogic Admin console frequently to configure resources or to manage the life cycle of the servers, you might have seen a confirmation prompt. This prompt will show not up when you are running the domain in development mode. When the domain is running in production mode they will ask confirmation for all the operations. There used to be no way to disable this confirmation page prior WebLogic Server 10.3. Now in WebLogic Server 10.3 and higher you can set a console user preference that can disable these confirmation pages.

Use the tool bar at the center (top) of the console to go to the "Preferences". Under the "User Preferences" tab you will find an option called "Ask for confirmation in operations". By default it will be enabled in production domains and you can disable it to avoid that annoying confirmation pages where will have to click either "Yes" or "No". While you are there explore the other useful preferences like "Show Inline Help" and "Show Advanced Sections" which can buy some real-estate space in the console and save you some clicks.

Sunday, November 15, 2009

Enable & Disable Administration Console

To disable the console:

* In the admin console navigate to --> General --> Advanced Options --> Console Enabled. De-select that option to disable console (restart required).

To hide the cosole:

* Enable the administration port on the domain so that console can only be accessed on the 2-way secured admin port. This will force all the clients to have valid certificate installed in their client (browser) to access the console.
* In the admin console navigate to --> General --> Advanced Options --> Console Context Path and change the context-path of the console to something unique and only known to the administrators.

All is fine. But one of the common question is how can I enable the console once I disable them. Like I said earlier you have to rely on the scripting tool to enable the admin console once it is disabled. You either perform this action interactively or by running a WLST script. See the following sample WLST script for more info:

connect("username","password")
edit()
startEdit()
cmo.setConsoleEnabled(true)
save()
activate()
disconnect()
exit()

You have to restart the administration server to get the console back. Have fun playing hide and seek with the console!

In WLS 10.3 with the Light Weight Server Installer, you can choose not to install WLS Admin Console when you install WLS.

Managed Server Independence Mode

Starting from version 7 WebLogic managed servers can be started in the absence of an administration server. The feature that will enable a managed server to come up in the absence of administration server (MSI mode) is enabled by default. But some of the files required for MSI mode are only sent to the managed server only when another option (MSI file replication enabled) is ON.

This feature is same in version 8 except that the config.xml being copied and cached in the managed server is stored as msi-config.xml.

In version 9 the feature is still the same except that the complete config directory that contains the configuration file is copied by default to the managed servers. But some other files like the security (*.dat) file is not copied until the MSI file replication enabled option is ON.

Version 10 alleviate all the pains by making MSI mode and MSI file replication as a default option. So out of the box a managed server is enabled to run in independence mode. And all the files required to start a managed server by itself (/config dir and *.dat file) will be automatically copied to the managed server during startup and will be synced (automatically) with the master copy (in Admin Server).