Patching AM7.1 and restarting the container: why and how

Patching AM7.1 and restarting the container: why and how

Introduction

OK, so you have AM7.1 installed, and you want to patch it and have the localization updated as well, but you don't really know why there are two patches and not only one, what is this redeployment about, and what restarting the webcontainer really implies... Well, this document will help to understand things ! More inline ... :)

Notes on terms

In order to know what we are talking about:

  • Patch

    After a company releases an application, new features are thought up for it and the existing ones need to be perfected or repaired. Usually, the company chooses to continue to develop its product and to add/modify/fix features. A new version of the application comes up and a patch for the old version is created. This patch replaces the files in the old version by those that are different in the new version and can even adds or removes some files. This patch is called the Base Patch
    If case you want to have the localization of your AM7.1 application patched as well, you will have an extra patch: the L10N Patch. This patch will not change any feature, but will update the localization according to the new feature that have been changed by the base patch.
  • Redeployment

    First imagine a standalone application that does not require a container to run in (some .exe or .bin file). When this application is loaded into the system memory, it also often loads much information from the configuration and data files. Changing these configuration files will have no effect on the already running application, because they were read and used only once, at the startup. That is why you have to start and stop the application for the changes of the configuration and data files to take effect.

    Now, an application that is not standalone needs a container to run in. Such container is for example an Application Server. This container provides various services for the application; we can very roughly compare it to the operating system a standalone application runs in. The analogy with the standalone application then gets obvious - if you change the source files (data and configuration), you again need to start and stop the application, that is redeploy it.

AM patching process: Base Patch and L10N Patch

Both patches are similar in the way that they change some files of the application. What about the differencies ?

  • Base Patch

    When you apply an application patch, you change various configuration files, deployment descriptors and such. Then you MUST redeploy the application, i.e. untie all bonds between the container and the application and then create these bonds anew. It is good to restart the container afterwards, and necessary for Sun Java Web Server and Sun Java Application Server.

    Question:

    • Why restart the container after redeployment? I though redeployment should remove the application completely and then add it again, as if it never was there before?

    That's true, in theory you should not see any difference between redeploying the application and redeploying the application with a subsequent restart of the container.
    Practically, there are good reasons for restarting the container. One of the most important reasons is avoiding the feared PermGen error. This error is caused by insufficient static objects memory in the application server. This insufficiency is caused by memory leaks during redeployment, which decrease the static objects memory size.
    A detailed article on PermGen error can be found at How to fix the dreaded "java.lang.OutOfMemoryError: PermGen space" exception or Classloader leaks: the dreaded "java.lang.OutOfMemoryError: PermGen space" exception
  • L10N Patch:

    Whenever the server displays a page, it dynamically loads the necessary l10n strings from a defined place in a defined l10n file.
    When you apply an l10n patch which just changes locales (but does not add one), you do not actually change any real "configuration" files. You just change the content of the l10n files.
    The structure of the l10n files is standardized and no files are added or removed during the patch process. Next time the server displays a page, the patched strings are loaded.
    So, in theory, you do not need to redeploy the application or restart the container. Practically, however, you still need to restart the container.

    Question:

    • Why restart the container when the files are changed and next time I want to display a page the server will load the correct strings?

    This has something to do with how the server works:
    The AM7.1 uses the JSP technology for defining the web pages. When you access a web page that is made by JSP, the server must compile the page into html according to its JSP definition. Only after that can it send you the html page for display. In order to save the computing time, the html page is compiled from the JSP only once (the first time) and then saved. Whenever there is a request for this page, the compiled version is used instead of making a new version of the page from the JSP.
    If the pages are always compiled only once, they cannot reflect any changes in JSP or l10n source files after they had been compiled. This is why you need to either redeploy the application or restart the container so the changes take effect (restart and redeploy both flush the JSP generated pages memory). Since by merely redeploying the application you would be threatening yourself with the PermGen error (description above), it is much better to restart the container instead.
    Note that restarting the container is not always necessary if monitoring of JSP pages changes is enabled (server recompiles the JSPs automatically upon their change). However, the monitoring might not work for l10n files (which are not JSPs), so restarting the container is the best thing to do all the same.

Example1: patching AM7.1 on AS9.1, under Linux

  1. Copy the patches for AM to your system.
  2. Patch your AM with the base patch: untar the base patch and run it <PATCH_PATH>/installpatch.
  3. Redeploy the application: change the amsilent file to meet your configuration and run the following
        # cd /opt/sun/identity/bin
    # vi ../amsilent
    # ./amconfig -s /opt/sun/identity/amsilent
    Note that the value DEPLOY_LEVEL in amsilent is set by default by the patch to 21: the redeployment value.
  4. Restart the container.
  5. Apply the l10n patches and restart the container.

Example2: patching AM7.1 on WS7.0, windows

  1. Copy the patches for AM to your system.
  2. Stop all javaES services or instances including the DS server.
  3. Patch your AM: unzip the base patch and run: (To run PERL scripts \*.pl use e.g. ActivePERL)
        prepatch.pl   
     
        126359-01.exe 
     
        postpatch.pl  

    		  
  4. Change the generated configuration file to meet your configuration:
        JAVAES_BASE-DIR/identity/setup/AMConfigurator.properties.temp

    		  
  5. Rename modified file to:
        JAVAES_BASE-DIR/identity/setup/AMConfigurator.properties
  6. Start DS, WS and all its instances
  7. Redeploy the application:
        cd JAVAES_BASE-DIR/identity/setup/
    amconfig.bat

    		  
  8. Restart the container

Sources:



Powered by ScribeFire.

<script type="text/javascript"> var sc_project=3055623; var sc_invisible=0; var sc_partition=33; var sc_security="2841646f"; </script> <script type="text/javascript" src="http://www.statcounter.com/counter/counter_xhtml.js"></script>
Comments:

Post a Comment:
  • HTML Syntax: NOT allowed
About

Members of the EMEA Globalization Center are blogging about the products that comprise the Java Enterprise System stack.

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today