X

Proactive insights, news and tips from Oracle WebLogic Server Support. Learn Oracle from Oracle.

  • November 2, 2015

ZDT Patching; A Simple Case – Rolling Restart

To get started understanding ZDT Patching, let’s take a look at it in its
simplest form, the rolling restart.  In
many ways, this simple use case is the foundation for all of the other types of
rollouts – Java Version, Oracle Patches, and Application Updates. Executing the rolling restart requires the
coordinated and controlled shutdown of all of the managed servers in a domain
or cluster while ensuring that service to the end-user is not interrupted, and
none of their session data is lost.

The administrator can start a rolling restart by issuing the WLST command
below:

rollingRestart(“Cluster1”)

In this case, the rolling restart will affect all managed servers in the
cluster named “Cluster1”. This is called
the target. The target can be a single
cluster, a list of clusters, or the name of the domain.

When the command is entered, the WebLogic Admin Server will analyze the
topology of the target and dynamically create a workflow (also called a
rollout), consisting of every step that needs to be taken in order to
gracefully shutdown and restart each managed server in the cluster, while
ensuring that all sessions on that managed server are available to the other
managed servers. The workflow will also
ensure that all of the running apps on a managed server are fully ready to
accept requests from the end-users before moving on to the next node. The rolling restart is complete once every
managed server in the cluster has been restarted.

A diagram illustrating this process on a very simple topology is shown
below.  In the diagram you can see that a node is taken offline (shown in red) and end-user requests that would have gone to that node are re-routed to active nodes.  Once the servers on the offline node have been restarted and their applications are again ready to receive requests, that node is added back to the pool of active nodes and the rolling restart moves on to the next node.

Animated image illustrating a rolling restart

 Illustration of a Rolling Restart Across a Cluster.

The rolling restart functionality was introduced based on customer
feedback.  Some customers have a policy
of preemptively restarting their managed servers in order to refresh the memory
usage of applications running on top of them. With this feature we are greatly simplifying that tedious and time
consuming process, and doing so in a way that doesn’t affect end-users.

For more information about Rolling Restarts with Zero Downtime Patching,
view the documentation.

Join the discussion

Comments ( 1 )
  • kumar allamraju Tuesday, November 3, 2015

    Jacob,

    Very nice feature to have in WLS.

    Why is it mandatory to have Admin Server managed by nodemanager?

    For e.g. rollingrestart can be performed at domain,cluster & for specific servers. When I do the rolling restart at a cluster or server level, the message I get is

    wls:/elastic_domain/serverConfig/> rollingRestart('DynaCluster1')

    Traceback (innermost last):

    File "<console>", line 1, in ?

    File "<iostream>", line 1641, in rollingRestart

    File "<iostream>", line 553, in raiseWLSTException

    WLSTException: Error occurred while performing rollingRestart : Error doing rollingRestart Found server AdminServer not being managed by a NodeManager. : Found server AdminServer not being managed by a NodeManager.

    Use dumpStack() to view the full stacktrace :

    wls:/elastic_domain/serverConfig/>

    I have the same problem when I do this from admin console. Am I doing something wrong here? Thanks


Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.Captcha