Weblogic Side by Side Deployment

Welogic server Side by side deployment

Keywords : weblogic side by side deployment, side by side deployment in weblogic, deployment, weblogic deployment

Weblogic Server supports a nice feature called side-by-side deployment (or versioned deployment). This function is extremely usefull when you need to deploy a new version of an application and still keep the old one up and running. So the running instances will still use the current version and all new instances will be able to invoke the new deployed version of the application. 

As soon as all the sessions who’re using the old version of the application are expired, Weblogic will recognize it and will deactivate the old version. So at this moment only the new deployed version is active and all new sessions will make us of it.

So how does this work ?

[A].1 . You could either use command line to deploy the application and specify the versionnumber on deployment as one of   

           the parameters

[B].1.   you can use the manifest.mf file and deploy from console

********************************** 
[A].1 -> From command line
********************************* 


Deploy a web application version 1 with below command ( i am deploying on Admin server )


java weblogic.Deployer -adminurl t3://localhost:7001 -username weblogic -password webl0gic -name VersionedApp  -targets AdminServer -deploy -source C:\shoppingcart.war -appversion version1


you will see application deployed with as version1.

Now redeploy the application as version 2 with below commands


java weblogic.Deployer -adminurl t3://localhost:7001 -username weblogic -password webl0gic -name VersionedApp -targets AdminServer -redeploy -source C:\shoppingcart.war  -appversion version2 

you will see same application deployed with as version2.

go ahead and delete the old application with status as retired.


************************
[B].1 From Console
************************
Edit to manifest file located in  META-INF and add the next on a new row : ‘WebLogic-Application-Version: v1′

2. 
   
3. 
   
4. 
   
5. 
   
6. 
   

Package the service and deploy it in the console

Deployment

1. Go to the Weblogic Console > Deployments. Click ‘Lock & Edit’ and in the deployments part click Install
2. Select the just created archive
3. Install this deployment as an application
4. Optional Settings. And in here we will see the ‘Archive Version’ of our application. Change the name to ‘MyService’ and leave the rest on default value

If you look in the list of deployments we will see our application is labeled with a version indication (v1).
The current version is still active.

Now create a new version of the application and change the v1 in the manifest file to v2, and package it.

Update Deployment

1. Go to the Weblogic Console > Deployments. Click ‘Lock & Edit’, select the application we want to update (MyService) and in the deployments part click Update
2. Click Change Path of the source path and select the just created archive (v2), the application will be deployed as version v2

If we now look in the list of deployments, we will see 2 versions of our application deployed.

Version v1 gets status ‘Retired’ and the new version v2 will get status ‘Active’.

Deployment : war, ear and jar files

Deployment : war, ear and jar files

Difference between ear, war and jar files.

Enterprise Application ( .ear )

An Enterprise Application consists of one or more of the following J2EE applications or modules:

• Web applications
• Enterprise Java Beans (EJB) modules
• Resource Adapter modules

An Enterprise Application is packaged as an archive file with an .ear extension

you can say it's a collection of war & jar files

Web Application ( .war )

A Web application always includes the following files:

• A servlet or JSP page, along with any helper classes.
• A web.xml deployment descriptor, a J2EE standard XML document that configures the contents of a WAR file.

Web applications may also contain JSP tag libraries, static .html and image files, supporting classes and .jar files, and a weblogic.xml deployment descriptor, which configures WebLogic Server-specific elements for Web applications. 

Enterprise JavaBean ( .jar )

Enterprise JavaBeans (EJBs) are reusable Java components that implement business logic and enable you to develop component-based distributed business applications. EJB modules are packaged as archive files having a .jar extension.


Summary

Deployment units that are packaged using the jar utility have a specific file extension depending on the type:

• EJBs and client archives are packaged as .jar files.
• Web applications are packaged as .war files.

• Resource adapters are packaged as .rar files.
• Enterprise applications are packaged as .ear files, and can contain other Java EE modules such as EJBs, JDBC, JMS, Web Applications, and Resource Adapters.
• Web Services can be packaged either as .war files or as .jar files, depending on whether they are implemented using Java classes or EJBs. Typically, the .war or .jar files are then packaged in an Enterprise Application .ear file.
• Java EE libraries are packaged either as an Enterprise Application (.ear file) or as a standard Java EE module.
• Client applications and optional packages are packaged as .jar files.

Deployment : Archive & Exploded Format

Archive Files

In most production environments, you will receive a deployable module as an archive file. An archive file is a single file that contains all of a J2EE module's classes, static files, directories, and deployment descriptor files. Archive files are created by using the jar utility to package the top-level directory of a J2EE module.

Modules that are packaged using the jar utility have specific file extension depending on the module type:

• EJBs are packaged as .JAR files.
• Web Applications are packaged as .WAR files.
• Resource Adapters are packaged as .RAR files.
• Enterprise Applications are packaged as .EAR files.

In most cases, you will deploy the archive file itself with no additional preparation.

Exploded Archive Directories

An exploded archive directory contains the same files and directories as a jar archive. However, the files and directories reside directly in your file system and are not packaged into a single archive file using the jar utility.

You may need to deploy a module as an exploded archive directory, rather than a single archive file, in the following circumstances:

• You are deploying an EJB, Web Application, or Enterprise Application that performs direct file system I/O. In this case, the components that perform the I/O operations should have a physical filesystem directory in which to work.
• You are deploying a Web Application or Enterprise Application that contains static files that you will periodically update. In this case, it is more convenient to deploy the module as an exploded directory, because you can update and refresh the static files without editing the archive.

How to increase default work manager threads

The default workmanager, as its name tells, is the workmanager defined by default.
Thus, all applications deployed on WLS will use it. The default workmanager belongs to a threadpool.

As the initial threadpool comes with only five threads, that's not much.

If your application has to face a large number of hits, you may want to start with more than that. 

Well, that's quite easy. You've got two ways to do so.

1) Modifying the config.xml

Just add the following line(s) in your server definition :

<server>

<name>AdminServer</name>

<self-tuning-thread-pool-size-min>100</self-tuning-thread-pool-size-min>

<self-tuning-thread-pool-size-max>200</self-tuning-thread-pool-size-max>

[...]

</server>

2) Adding some JVM parameters

Personally, that's my favorite option since I don't like when people go in a generated config file and mess up with tags. If you're sure of what you're doing, that's ok, but it's safer the following way :

add the following option in your command line : 
-Dweblogic.threadpool.MinPoolSize=100

Observing the result

Performance Tuning Part - 3 : Work Managers

1]. WebLogic Server allows you to configure how your application prioitizes the   

     execution of its work. 

2]. Based on rules you define and by monitoring actual runtime performance, WebLogic   

     Server can optimize the performance of your application and maintain service level  

     agreements. 

3].  You define the rules and constraints for your application by defining a Work Manger  

      and applying it either globally to WebLogic Server domain or to a specifi  

      application component.

4]. In WebLogic Server 9.0 there is a single thread pool, in which all types of work are  

     executed. WebLogic Server prioritizes work based on rules you define, and run-

     time metrics, including the actual time it takes to execute a request and the rate at

     which requests are entering and  leaving the pool.

5]. The common thread pool changes its size automatically to maximize

      throughput. The queue monitors throughput over time and based on history,

      determines whether to adjust the thread count. 

     For example, if historical throughput statistics indicate that a higher thread count  

     increased  throughput, WebLogic increases the thread count. Similarly, if statistics

     indicate that fewer threads did not reduce throughput, WebLogic decreases the  

     thread count. This new strategy makes it easier for administrators to allocate

     processing resources and manage performance, 

     avoiding the effort and complexity involved in configuring, monitoring, and tuning

      custom executes queues.

6]. Administrators can configure a set of scheduling guidelines and associate

     them with one or more applications, or with particular application components.

For example,

  

you  can associate one set of scheduling guidelines for one application, and another  

  set of guidelines for other application. At run-time, WebLogic Server uses these

  guidelines to assign  pending work and enqueued requests to execution threads.

7] .

Work Managers can be configured at the domain level, application level, and module level in one of the following configuration files:

• config.xml—Work Managers specified in config.xml can be assigned to any application, or application component, in the domain. You can use the Administration Console to define a Work Manager.
• weblogic-application.xml—Work Managers specified at the application level in can be assigned to that application, or any component of that application.
• weblogic-ejb-jar.xml or weblogic.xml—Work Managers specified at the component-level can be assigned to that component.
• weblogic.xml—Work Managers specified for a Web Application.

Work Manager Stanza

<work-manager>

<name>highpriority_workmanager</name>

   <fair-share-request-class>

      <name>high_priority</name>

      <fair-share>100</fair-share>

   </fair-share-request-class>

   <min-threads-constraint>

      <name>MinThreadsCountFive</name>

      <count>5</count>

</work-manager>

To reference the Work Manager listed above in the dispatch policy of a Web Application, add the below code into the Web Application's web.xml file:

Referencing the Work Manager in a Web Application

<init-param>

   <param-name>dispatch-policy</param-name>

   <param-value>highpriority_workmanager</param-value>

</init-param>

8]  To manage work in your applications, you define one or more of the following Work Manager 

     components:

• Fair Share Request Class:
• Response Time Request Class:
• Min Threads Constraint:
• Max Threads Constraint:
• Capacity Constraint
• Context Request Class:

• fair-share-request-class—Specifies the average percentage of thread-use time required to process requests.

For example, assume that WebLogic Server is running two modules. The Work Manager for ModuleA specifies a fair-share-request-class of 80 and the Work Manager for ModuleB specifies afair-share-request-class of 20.

During a period of sufficient demand, with a steady stream of requests for each module such that the number requests exceed the number of threads, WebLogic Server will allocate 80% and 20% of the thread-usage time to ModuleA and ModuleB, respectively.

• response-time-request-class—This type of request class specifies a response time goal in milliseconds. Response time goals are not applied to individual requests. Instaead, WebLogic Server computes a tolerable waiting time for requests with that class by subtracting the observed average thread use time from the response time goal, and schedules schedule requests so that the average wait for requests with the class is proportional to its tolerable waiting time.

For example, given that ModuleA and ModuleB in the previous example, have response time goals of 2000 ms and 5000 ms, respectively, and the actual thread use time for an individual request is less than its response time goal. During a period of sufficient demand, with a steady stream of requests for each module such that the number requests exceed the number of threads, and no "think time" delays between response and request, WebLogic Server will schedule requests for ModuleA and ModuleB to keep the average response time in the ratio 2:5. The actual average response times for ModuleA and ModuleB might be higher or lower than the response time goals, but will be a common fraction or multiple of the stated goal. For example, if the average response time for ModuleA requests is 1,000 ms., the average response time for ModuleB requests is 2,500 ms.

• context-request-class—This type of request class assigns request classes to requests based on context information, such as the current user or the current user's group.

• max-threads-constraint—This constraint limits the number of concurrent threads executing requests from the constrained work set. The default is unlimited. For example, consider a constraint defined with maximum threads of 10 and shared by 3 entry points. The scheduling logic ensures that not more than 10 threads are executing requests from the three entry points combined.

A max-threads-constraint can be defined in terms of a the availability of resource that requests depend upon, such as a connection pool.

A max-threads-constraint might, but does not necessarily, prevent a request class from taking its fair share of threads or meeting its response time goal. Once the constraint is reached the server does not schedule requests of this type until the number of concurrent executions falls below the limit. The server then schedules work based on the fair share or response time goal.

• min-threads-constraint—This constraint guarantees a number of threads the server will allocate to affected requests to avoid deadlocks. The default is zero. A min-threads-constraint value of one is useful, for example, for a replication update request, which is called synchronously from a peer.

A min-threads-constraint might not necessarily increase a fair share. This type of constraint has an effect primarily when the server instance is close to a deadlock condition. In that case Then, however, it the constraint will cause WebLogic Server to schedule a request from a even if requests in the service class have gotten more than its fair share recently.

• capacity—This constrain causes the server to reject requests only when it has reached its capacity. The default is zero. Note that the capacity includes all requests, queued or executing, from the constrained work set. Work is rejected either when an individual capacity threshold is exceeded or if the global capacity is exceeded. This constraint is independent of the global queue threshold.

Weblogic Server - Coherence Configuration Example

Weblogic Server - Coherence Configuration

For theoretical knowledge on coherence read my this post - http://weblogicserveradministration.blogspot.com/2011/05/oracle-coherence-37-coherenceweb.html

In this post I am going to cover practical example on Coherence

I have used Weblogic Server 10.3.5 + Coherence 3.6

High Level Steps

1.  Install weblogic server 10.3.5 with coherence 3.6 or 3.7
2.  Create a domain
3.  Create a machine, start node manager and check status from console if it's accessible
4.  Create a a simple cluster with two managed servers, and assign both managed servers to 
      machine
5.  Create a Coherence cluster and assign your above defined cluster to coherence cluster
      [ OR instead of above step2 and step3, you can just create two managed servers, then  
         create a coherence cluster and assign both managed servers to this coherence cluster ]
6.  Start a cache server
7.  Start both managed servers
8.  Deploy shared library files
9.  Create a testing application and deploy on cluster
10.Test 

Steps

1. For installation see my other post 
http://learn-weblogic.blogspot.in/2013/07/weblogic-server-installation-console.html

2. For domain creation see my other post
http://learn-weblogic.blogspot.in/2013/07/create-domain-in-gui-mode.html
http://learn-weblogic.blogspot.in/2013/07/weblogic-domain-creation-in-console.html
http://learn-weblogic.blogspot.in/2013/07/domain-creation-in-console-mode-on.html

3. For machine,node manager configuration see my other post
http://learn-weblogic.blogspot.in/2013/07/configure-start-stop-node-manager-step.html

4. To create a simple cluster and assign servers to cluster see my other post
http://learn-weblogic.blogspot.in/2013/07/vertical-clustering-step-by-step.html

5. Create a coherence cluster and assign your above created cluster to this coherence cluster

a. Login to admin console
b. Click on Coherence Clusters option on left hand side panel
c. Do the configuration like below and save

Unicast Listen Address - your machine hostname or i.p
Unicast Listen Post - 8085 ( or any other available port of your machine )
Multicat Listen Address - 231.1.1.1 ( or any multicast range available i.p but make sure this need to update in coherence server startup script which i will explain later )
Multicast Listen Port - 7777 ( or you can use any other available port of your machine but make sure this need to update in coherence server startup script which i will explain later )

After creating coherence cluster, click on Target tab and assign your previously create simple cluster to this coherence cluster

Now you can see like below under coherence cluster option

6. Start Cohrence Server

Copy the below contents, paste in a text file and rename it as .bat ( on windows )
( if you are on unix based systems then change scripts variable settings, path etc accordingly )

Start-Coherence.bat

setlocal

set COHERENCE_HOME=C:\Oracle\Middleware2\coherence_3.6
set COH_OPTS=%COH_OPTS% -server -cp %COHERENCE_HOME%\lib\coherence.jar;%COHERENCE_HOME%\lib\coherence-web-spi.war;
set COH_OPTS=%COH_OPTS% -Dtangosol.coherence.management.remote=true -Dtangosol.coherence.cacheconfig=/WEB-INF/classes/session-cache-config.xml -Dtangosol.coherence.distributed.localstorage=true -Dtangosol.coherence.clusterport=7777 -Dtangosol.coherence.clusteraddress=231.1.1.1 -Dtangosol.coherence.session.localstorage=true
java %COH_OPTS% -Xms256m -Xmx256m -XX:MaxPermSize=256m com.tangosol.net.DefaultCacheServer
:exit

Now start above create script

Output should be like below

7. Start both managed servers from console

8.  Deploy below shared libraries on your cluster ( During deployment make sure to choose 

     option deploy this file as library not application for both files )

coherence-web-spi.war from  ORACLE_HOME\coherence_3.6\lib and  active-cache-1.0.jar  
  from  ORACLE_HOME\wlserver_10.3\common\deployable-libraries

9.  Create a testing application like below

[1] Create a folder CoherenceTest
[2] Inside CoherenceTest folder create 
      a. META-INF folder, Inside it a file with name manifest.mf with below contents


Extension-List: active-cache
active-cache-Extension-Name: active-cache
active-cache-Specification-Version: 1.0
active-cache-Implementation-Version: 1.0


 [3] WEB-INF folder
        
        3.1 inside it, create a file web.xml with below contents

               <?xml version = '1.0' encoding = 'windows-1252'?>
               <web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
               xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web- 
               app_2_4.xsd" 
               xmlns="http://java.sun.com/xml/ns/j2ee" version="2.5">
              <description>Empty web.xml file for Web Application</description>       
             </web-app>
        
         3.2 inside it, create a file weblogic.xml with below contents

         <weblogic-web-app xmlns="http://xmlns.oracle.com/weblogic/weblogic-web-app"  
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"  
         xsi:schemaLocation="http://xmlns.oracle.com/weblogic/weblogic-web-app 
         http://www.oracle.com/technology/weblogic/weblogic-web-app/1.1/weblogic-web-app.xsd">
         <library-ref>
           <library-name>coherence-web-spi</library-name>
         </library-ref>
         <coherence-cluster-ref>
            <coherence-cluster-name>CoherenceCluster</coherence-cluster-name>
         </coherence-cluster-ref> 
           </weblogic-web-app>

( Make sure here cluster name exactly the same you have given to your coherence cluster )

        3.3 inside it, create a folder with name lib and copy coherence.jar file from 
               COHERENCE_HOME\lib to here ( ORACLE_HOME\coherence_3.6\lib in my case )
        
 [4]. A jsp file with name counter.jsp ( copy and paste below code inside it )


<html>
    <body>
<h3>
      Counter :
      <%
         Integer counter = new Integer(1);
         HttpSession httpsession = request.getSession(true);
         if (httpsession.isNew()) {
                httpsession.setAttribute("count", counter);
                out.println(counter);
         } else {
                int count = ((Integer) httpsession.getAttribute("count")).intValue();
                httpsession.setAttribute("count", new Integer(++count));
                out.println(count);
         }
      %>
      </h3>

    </body>
</html>


Below is the structure

10. Deploy this CoherenceTest application as in exploded form on your cluster

11. Test

Now, first access you application using first managed server URL

http://host:first_managed_server_port/CoherenceTest/counter.jsp

it will show you as counter : 1

After that access your application using second managed server URL

http://host:second_managed_server_port/CoherenceTest/counter.jsp

it will show you counter : 2

So, here session shared on your external coherence server and shared across servers on your cluster..

you are done...cheers!!!!!!!