Weblogic Server Cluster Multicast Test
Multicast Testing
This forum
gives multicast testing methodology used in weblogic clusters.Those who have
implemented horizontal clustering and wanta to debug multicast problems ..this
forum is useful.
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.
Below is
the command to do multicast testing :
java utils.MulticastTest -n name -a address [-p portnumber]
[-t timeout] [-s send]
- -n is any name used to identify the messages sent and received from each multitest process
- -a is multicast address where the cofigured clsutered members are communicating
- -p is multicast port which is optional and defaults to admin server port if unset
- -t is idle timeout in seconds . Default value is 600 secs
- -s is send sec, default is 2 secs.
Below is the example executed in real time
# java utils.MulticastTest -N Test1 -A 237.155.155.55
Set up to send and
receive on Multicast on Address 237.155.155.55 on port 5008
Will send a
sequenced message under the name Test1 every 2 seconds.
Received
message 112 from Test1
Received
message 234 from Test2
I (Test1) sent
message num 108
Received message 108
from Test1
Received
message 239 from Test2
I (Test1) sent
message num 109
Received
message 109 from Test1
Received
message 240 from Test2
I (Test1) sent
message num 110
Received
message 110 from Test1
Received
message 241 from Test2
I (Test1) sent message
num 111
Received
message 111 from Test1
Received
message 242 from Test2
I (Test1) sent
message num 112
Received
message 112 from Test1
Received
message 243 from Test2
In the same way test2 multicast process can be viewed in other box too.
If a timeout occurs in network care interface, the exception is sent to
stdout log as below:
------------------------------------------------------------------------------------------------------------
HTTP Session Management in Oracle Weblogic Server
- Web applications use HTTP sessions to track information in server memory for each client.
- By default, when a client fails over to another server in the cluster, its session information is lost.
- Oracle WebLogic Server supports several Session Replication strategies to recover sessions from failed servers.
In-memory
replication
JDBC
replication
File
replication
- Replication is configured for each Web application within its weblogic.xml file.
In Memory Replication
- Each user’s session always exists on two servers that is primary and secondary
- Every update to the primary session is automatically replicated on the secondary server, either synchronously (default) or asynchronously (batch).
- Oracle WebLogic Server uses nonpersistent cookies to track the primary and secondary servers for each client.
- Subsequent requests from the same client must be directed to the same primary server by the proxy.
- The server that is being failed over to automatically assumes the role of the primary server.
WLS can
replicate:
HttpSession
objects
Stateful
session EJBs
Session
objects exist on only two servers.
Secondary:
The server
is determined by the replication group and machine definition.The object is
created immediately after the primary object is created.Primary failure makes
the backup object the primary object.
Configuring In-Memory Replication
Specify
the persistence type in the weblogic.xml deployment descriptor; the options
include:
- replicated
- replicated-if-clustered
- async-replicated
- async-replicated-if-clustered
…
…
___________________________________________________________________________________________________
HTTP Session : Replication using JDBC
- HTTP sessions can be persisted to a database using a common JDBC data source.
- The required Data Definition Language (DDL) file is available in the documentation.
- All members of the cluster have access to any client’s session for failover purposes (no primary or secondary).
Configuring JDBC Replication
- Create the required table in the database.
- Create a JDBC data source that has read/write privileges for your database.
- Configure JDBC session persistence in the weblogic.xml deployment descriptor.
…
…
JDBC Persistent table configuration
A database
table named WL_SERVLET_SESSIONS must exist with read/write access:
|
Column Head
|
Column Data Type
|
|
WL_ID
|
char, 100 variable width char
|
|
WL_CONTEXT_PATH
|
|
|
WL_CREATE_TIME
|
numeric, 20 digits
|
|
WL_IS_VALID
|
char, 1 character
|
|
WL_SESSION_VALUES
|
BLOB, very large
|
|
WL_ACCESS_TIME
|
numeric, 20 digits
|
|
WL_IS_NEW
|
numeric, 20 digits
|
________________________________________________________________________________________________________
HTTP Session : File Replication
File
replication is similar to JDBC replication, but it persists sessions to a
highly available file system.
Configuring File Replication
- Create a folder shared by all servers on the cluster on a highly available file system.
- Assign read/write privileges to the folder.
- Configure file session persistence in the weblogic.xml deployment descriptor.
…