The process of making Java application is called as deployments. When the development is completed the code needs to be packaged and it is suppose to deployed to Weblogic.
→ Weblogic has the capability of understanding the deployments,understanding the technologies involved, understand the code architecture and provide facility for deployments to run. Once the deployment is successful then only we will be able to access website or application.
→ Deployments are as 2 types:
1. APPLICATION:
2. LIBRARY:
→ Applications are of 2 types:
1. war(web archive)
2. ear(enterprise archive)
WAR:-
→ war is an application which contains the navigation rules or Presentation logic inside it and it is suitable for small scale Applications.
Example: enaadu.net
EAR:-
→ ear is an application type which contains heavy business logic. Ear will contain both presentation and business logic. It means ear may contain war files. Depends on the
Application type the ear contains one or more than war files. In this case multiple navigation rules are accessing the same business logic.
DIFFERENCE BETWEEN WAR AND EAR:
WAR | EAR |
1.war file contains an extension of .war. Ex: icici.war | 1.ear file contains an extension of .ear Ex: icici.ear. |
2.war mainly contains navigation rules | 2.ear contains both navigation and business logic |
3.war can be deployed as an application | 3.ear can also be deployed as an application. |
4.war file contains technologies like struts,mvc,spring,jsf etc. | 4.ear contains EJB,HIBERNATE,WEBSER SERVICES along with war technologies. |
5.war contains a folder called WEB-INF. | 5.ear file contains a folder called APP-INF |
6.war file contains deployment descriptor called web.xml. | 6.ear file contains deployment descriptor Called application.xml and Weblogic.xml. |
LIBRARY:
→ Library is a piece of shared code which can be shared by any number of war or ear files.
→ using shared libraries we can avoid maintaining duplicated copies of code.
→ Libraries are will be in the format of Jar files.
→ while deploying Jar file, during the deployment we will select the deployment type as library.
STEPS FOR DEPLOYMENT:
1.Get the war or ear or Jar file.
2.login to console and select the deployments.
3.select the install.
4.browse the application.
5.select the deployment mode.
6.select the deployment type.
7.Target the Application.
8.complete the deployment
9.when deployment is completed it is mandatory that we have to activate that Application.
DEPLOYMENT ORDER:
→ when we have the multiple applications we may have dependency between these applications.
→ To maintaining the dependency or to load the applications in proper order we will define the deployment order number.
→ The default deployment order number is 100.
STEPS TO CHANGE THE DEPLOYMENT ORDER NUMBER:
→ Go to console------>deployments--------->select the application for which you want to change the deployment order.
→ select overview tab------>change the parameter called deployment order.
DEPLOYMENT PLAN:
→ When we have multiple components with ear we can maintain the deployment plan. So that Weblogic loads these components in a specific dependency order.
→ The best option of maintaining these deployment plan by defining in deployment descriptors by developers.
→ Examples of deployment descriptors are web.xml, Application.xml, weblogic.xml.
DEPLOYMENT MODES:
→ We have 3 types of deployment modes in Weblogic.
1.NO STAGE MODE.
2.STAGE MODE
3.EXTERNAL STAGE MODE.
NO STAGE MODE:
→ In the no stage mode we will copy the physical file to all Unix servers, Where Weblogic is running. Once we are done with copying we will follow the normal deployment process to complete the deployments.
STAGE MODE:
→ In the stage mode instead of we copy the file manually, Weblogic copy for us to all Unix servers.
EXTERNAL STAGE MODE:
→ In the external stage mode we will use third party tools to push the files to Unix servers.
.→ out of all above 3 modes NO STAGE MODE is the safest mode, because network bandwidth can't be more or we don't depend on third party tools.
DIFFERENT STATES OF APPLICATION:
PREPARED:- When we deploy the application first time.
ACTIV:- when application is in running.
WARNING:- when there are warnings in application.
ERROR:- when there are errors in application.
EXPLODED FORMATS OF APPLICATION:
→ Exploded formats of application are simple as normal folders. Weblogic understand these files by looking the contents of the file.
→ Exploded formats are useful when we receive ad hoc deployments frequently.
SIDE BY SIDE DEPLOYMENTS:-
→ when we are doing re deployment of the application, there will be inconsistency for the existing user request, means users will be able to see different options in the same request.
→ To avoid this Weblogic provides a option to UPDATE the existing application.
Which is called as side by side deployment.
→ when we follow the side by side deployment Weblogic maintaining 2 versions of the ear and the first version will be expired based on bellow 2 options.
1.Expire the first version, after completion of existing version:
→ whenwe use this option Weblogic stops sending user request to the first version and wait for existing user request to complete.
→ This option is feasible because there will be no impact to the existing user request in version one.
2.Expire the first version, after specific time:
→ when we select this option Weblogic expires the first version of ear, after specific amount of time. This option may not be feasible, because we may not know when the existed user request will be expired.
STEPS FOR SIDE BY SIDE DEPLOYMENT:
1.Get the war or ear file.
2.Goto console----->deployments---->select the application you want to update.
3.select the UPDATE button and browse the updated ear/war file.
4.select an option of expiring the old version.
5.completing the deployment.
HEAP
→ while Weblogic server running it needs some amount of RAM to store temporary data that is objects, sessions etc.
→ so the amount of RAM which we dedicate to Weblogic server is called as HEAP. While user request reach to the Weblogic there will be n number of objects will be created and all these objects will be stored in the heap.
→ once user logout from the application all these temporary objects will be cleared from heap. The default heap size to the Weblogic is 512 MB. Depends on the application usage we may or may not change the heap size. While changing the heap size we may need to consider the bellow points.
1.How big your application is.
2.How many objects it may produced(default objects).
3.Traffic of the application(number of users accessing)
4.fore casting of the application usage.
5.session replication or failover.
NOTE:- The industry standard heap size for large and medium scale applications is 2 GB.
→ when the user request comes in the objects are stored in the heap. When the same user requests are completed the related objects are cleaned from the heap. The process of cleaning objects is called as GARBAGE COLLECTION. The process who does is GC(GARBAGE COLLECTOR).
→ Every JVM has its own GC, which does the cleaning process.
→ The default GC Algorithm is called as MARK AND SWEEP algorithm.
PROCESS OF GC:-
→ GC keeps monitoring the heap size either based on heap usage or based on time intervals. When it monitors the heap, if objects are related to running user request it will not clean those objects. If it fines objects are unreferenced(not associated to any user request) it will sweep/clean those objects. since GC is processing we will have heap size under control.
→ If GC is not processing properly, the unreferenced objects will never get cleared and heap will be completely occupied.
→ If Weblogic does not find enough space in heap it will be crashed by throwing an exception called Out of memory exception.
REASONS FOR GETTING OUTOF MEMORY EXCEPTION:-
1.Not enough heap size allocated to Weblogic.
2.If GC is not happening properly.
3.Unexpected increase in the user requests.
4.Memory leak issues.
→ default heap parameters are defined in “setDomainEnv.sh”(setting Domain environment).
→ setDomainEnv.sh is a file where we have default configuration define to start Weblogic.
→ Default parameters are as shown bellow.
32 BIT | 32BIT | 64BIT | 64BIT | |
SUN | MIN | MAX | MIN | MAX |
256MB | 512MB | 256MB | 512MB | |
JROCKIT | MIN | MAX | MIN | MAX |
512MB | 512MB | 512MB | 512MB |
INDIVIDUAL STARTUP SCRIPTS:
→ If we change heap parameters in setDomainEnv.sh, those changes will be applicable to all Weblogic servers running in the domain.
→ This is not a good option, because having same heap size of manage server,Admin server.
→ To avoid this we will go for an option called writing “Individual Startup Scripts”
→ This option is suitable because using individual startup scripts we can apply changes to individual manage server alone.
SAMPLE STARTUP SCRIPTS:
touch icicims1.sh
#!/bin/sh
#individual startup script to start icicims1
USER_MEM_ARGS= “-Xms2048m -Xmx2048m”
export USER_MEM_ARGS;
./startmanaged weblogic.sh icicims1 t3://localhost:7001
HOW MANY WAYS TO CHANGE THE HEAPSIZE?
→ The preferred way of changing the heap size are given bellow:
1.change the setDomainEnv.sh
2.change the individual startup scripts.
3.change through server start option of Weblogic console.
4.change using Weblogic scripting tool(WLST)
→ out of all above options changing Heap size using “individual startup scripts” is preferred way.
→ Apart from using XMS,XMX parameters there are other few parameters which will be used to improve the performance of Weblogic.
→ some of the important parameters are :
-XMS
-XMX
-XNOOP
-XThroughput
XMS:- It is used to define minimum heap size.
XMX:- It is used to define maximum heap size.
XNOOP:- To inform Weblogic not to perform optimization.
XThroughput:- To improve the completion time of user request and responses.
→ To achieve the best performance of the Weblogic, oracle recommends to have both XMS and XMX values are same.
→ while developers doing the code every object which is opened expected to be closed. If they do not closed it properly, objects will still be in the heap and GC is unable to clean those objects. This situation is called as “Memory Leak”.
HOW TO FIX MEMORY LEAKS:-
→ As temporary fix we can restart the Weblogic to that heap will be closed.
→ As a permanent fix developers needs to identify the unclosed objects, fix it as part of the encoding and redeploy the application.
HOW TO FIX OUTOF MEMORY ISSUE:-
1.Increase the heap size if it is not sufficient.
2.Increase the manage servers if those existing servers are not sufficient.
3.fix the memory leak issue.
HOW TO ANALYZE THE HEAP:-
→ Heap can be analyzed to some extent by taking the heap dump. To take a heap dump use a utility called “Jmap”.
No comments:
Post a Comment