Search your topic in Java2share
Home > FAQs
eXTReMe Tracker


Weblogic Application Server FAQs

191.How the Server will communicate in a Cluster?

      • The Oracle WebLogic Server instances in a cluster communicate with one another using two different techniques:
      1. Unicast/multicast (UDP)
      2. Sockets (peer-to-peer TCP)
      • The server instances use IP unicast or multicast to broadcast the availability of services and heartbeats that indicate continued availability.
      • IP multicast broadcasts one-to-many communications among clustered instances.
      • IP unicast is an alternative to multicast to handle cluster messaging and communications. The unicast configuration is much easier because it does not require cross-network configuration that multicast requires.
      • IP sockets are used for peer-to-peer communications between server instances.

      192.Explain about Cluster Communication in WLS?

        1. Members of a cluster cooperate to achieve high availability using the following:
          • Broadcast messages such as “heartbeats”
          • Peer-to-peer IP sockets
        2. You can configure broadcast communication to use either:
          • IP unicast
          • A dedicated IP multicast address (224.0.0.0 through 239.255.255.255) and port
        3. If heartbeats are not received from a cluster member, the server is marked as “failed” and its services are not used.

      193.How the Weblogic Server detect a server Failure?

        1. WebLogic clusters detect the failure of a server instance in the following ways:
          • Through the use of IP sockets
          • Through the Oracle WebLogic Server heartbeat
        2. If a server in the cluster unexpectedly closes its socket, it is marked as “failed” and its services are not used.
        3. Server instances use multicast to broadcast heartbeats every 10 seconds to the other server instances in the cluster.
          1. If three heartbeats are missed from a peer server, the server is marked as “failed” and its services are not used.

      194.Explain about One-to-Many Communications in WLS?

        1. Oracle WebLogic Server uses one-to-many communication for:
          1. Clusterwide JNDI updates
          2. Cluster “heartbeats”
        2. Because all one-to-many communications occur over IP multicast, when you design a cluster, consider the following factors:
          1. If your cluster spans multiple subnets, your network must be configured to reliably transmit messages.
          2. A firewall can break IP multicast transmissions.
          3. The multicast address should not be shared with other applications.
          4. Multicast storms may occur.

      195.Explain about Peer-to-Peer Communications in WLS?
      Oracle WebLogic Server uses peer-to-peer communications for:

        1. Accessing the nonclustered objects that reside on a remote server instance in the cluster
        2. Replicating HTTP session states and stateful session EJB states between a primary and a secondary server
        3. Accessing the clustered objects that reside on a remote server instance (typically, in a multitier cluster architecture)

      196.Explain about Multitier Communications in WLS?

        1. Multitier clusters require more IP sockets than a combined-tier cluster:
          • One socket for replicating session states
          • One socket for each Oracle WebLogic Server in the EJB cluster, for accessing remote objects
        2. As an example, using a three-node cluster, the worst-case scenario would be five open sockets per server:
          • One primary and secondary replicated session
          • Each server simultaneously invokes a remote EJB method on each node in the cluster.

      197.How many cluster Configuration Options are available in WLS?
      There are multiple ways to create and configure an Oracle WebLogic Server cluster:

        1. Administration Console
        2. Configuration Wizard
        3. WebLogic Scripting Tool (WLST)
        4. Using the Cluster MBean

      198.Explain about Two-Phase Deployment?

        1. Applications are deployed using two-phase deployment (TPD).
        2. Applications are copied to the cluster and activated in two phases:
          • Phase 1: Application components and modules are distributed to the server.
          • Phase 2: The application is deployed if phase 1 is successful and client access is permitted.
        3. This ensures that an application is available and active on each node before clients can access it.

      199.How will you Deploy Applications to a Cluster?

        1. All nodes must be running before an application is deployed to a cluster.
        2. If phase 2 of the two-phase deployment fails, the application is still deployed to other nodes in the cluster.
        3. WebLogic allows partial deployment of applications to a partitioned server.
        4. Session replication for deployed applications may fail if a node is partitioned at the time of deployment.
          • Avoid this by using the enforceClusterConstraints tag with weblogic.Deployer.
          • Or select the Enable Cluster Constraints check box in the console.
        5. Do not change cluster membership while deploying applications to the cluster.

      200.Explain about HTTP Session Failover?

        1. Web applications use HTTP sessions to track information in server memory for each client.
        2. By default, when a client fails over to another server in the cluster, its session information is lost.
        3. Oracle WebLogic Server supports several Session Replication strategies to recover sessions from failed servers:
          • In-memory replication
          • JDBC replication
          • File replication
        4. Replication is configured for each Web application within its weblogic.xml file.
        5. Similar options are available for stateful EJB applications.