Session replication in WebSphere


What is session?
————————–
*  A Session is a series of requests to a servlet, originating from the same user at the same browser

How session works?
——————————
*  session ID Allows to keep track of individual users
*  Session ID generated on first request and send back to browser with first response.
*  Session ID then arrives with each subsequent request
*  Cookies, URL rewriting and SSL (if request is on HTTPS) are ways to track the session IDs

Distributed sessions
——————————
Session management can store session-related information in …
*  In application server memory (the default). This storage options is knows as in-memory sessions.
*  In a database. This storage option is known as database persistent sessions.
*  In another WebSphere Application Server instance. This storage option is known as memory-to-memory sessions.

*  Distributed sessions are essential for using HTTP sessions for the failover facility
*  Plug-in maintains Session affinity by sending requests with session ID to cluster member where that session has been previously created
*  On the failure of cluster member, plug-in routes requests to other members
*  When cluster member receives a request associated with a session ID that it currently does not have in memory, it can obtain the required session state by accessing the external store (database or memory-to-memory). Continue reading

WebSphere Admin Toolkit : apachectl command


Everyone likes tweaks and hacks but the most important thing is that that feature is already present and we just don’t about it or don’t know how to use it.  In part2 of out AdminToolkit, you’ll learn how to use apachectl of IBM http server / Apache as a power user.

apachectl is a front end to the Apache HyperText Transfer Protocol (HTTP) server. It is designed to help the administrator control the functioning of the Apache httpd The apachectl script can operate in two modes. First, it can act as a simple front-end to the httpd command that simply sets any necessary environment variables and then invokes httpd, passing through any command line arguments. Second, apachectl can act as a SysV init script, taking simple one-word arguments like startrestart, and stop, and translating them into appropriate signals to httpd.

  • 1. Know what modules are loaded

# ./apachectl -l
this will display all the modules that are compiled into your installation of IHS/Apache

  • 2. Syntax issues

This happens to everyone. You make some changes to your config file and restarts IHS/Apache but it fails with error message syntax error. you can use apachectl -t to test your config file before restarting your IHS/Apache, to know if the config file has correct syntax.

# apachectl -t -f conf/httpd.conf_joseph
Syntax OK

  • 3. Have ever been asked to change DocumentRoot temporary ?

you can do it without restarting your server… using

# ./apachectl start -c "DocumentRoot /var/new/html" The above command starts your server with /var/new/html as docroot.  
  • 4. change loglevel temporary ?

It is possible to change the LogLevel temporary. the below command sets the loglevel to DEBUG temporarily.

apachectl start -e debug

  • 5. Startup errors

If you are getting error whilel starting your server and wants to log the startup errors to separate file  ..use

# ./apachectl start -E file_name

  • 6. What version of the server you are using?

# ./apachectl -v

  • 7. Know where can you use httpd.conf directives

This command will display all the httpd.conf directives and the places where they are valid. For a specific directive, it tells all the possible values and where it can be used inside the httpd.conf.

# ./apachectl -L

  • 8. Testing your changes.

The best practise is to make a backup of the httpd.conf file and then edit it . The other idea is to take a backup, edit the backup file, test your changes and then make the changes to the original. Now i have two config files httpd.conf [orginal] and httpd.conf_joseph [with new changes/configs]. Before i stop my IHS/Apache, i want to make sure that, my new httpd.conf will run with out erros.

This can be achieved by using “apachectl -f “
# ./apachectl -f conf/httpd.conf_joseph 

The above command specify an alternate ServerConfigFile. After running the above command, try ‘ps -ef|grep httpd’ .. you should see httpd.conf_joseph as argument to httpd.

here is what you do :
cd APACHE/bin

  • cp httpd.conf httpd.conf_joseph
  • Make your changes in httpd.conf_joseph
  • apachectl -f conf/httpd.conf_joseph
  • ps -ef|grep httpd
  • your changes are good 
  • cp httpd.conf_joseph httpd.conf
  • apachectl restart

WebSphere Application Server v6.1 Fix pack silent installation notes


This is for all the readers who are using WebSphere Application Server v6.1. Below are the detailed instructions on how to install a fix pack using silent installation method.

Update Installer

Now you’ve downloaded the required fix pack files and update installer.

Installing Update Installer

  • Unpack the downloaded update installer file.
  • It creates a directory with name ‘updateinstaller’
  • Go to update install directory and look for ‘responsefile.updiinstaller.txt’ file. This file is template for silent installation.
  • Now open responsefile.updiinstaller.txt for editing
    • First you need to accept the license by changing below option to true.
      • -OPT silentInstallLicenseAcceptance
    • If you are installing as non-root, Uncomment the following.
      • -OPT allowNonRootSilentInstall=”true”
    • If you want to disable operating system prerequisite checking, uncomment the following line
      • -OPT disableOSPrereqChecking=”true”
    • If you want to disable the checking for existing Update Installer, uncomment the following line
      • -OPT disableEarlyPrereqChecking=”true”
    • Specify the install location of the product [installation directory for update installer]
      • -OPT installLocation=”WebSphere_root/UpdateInstaller”.
  • Now run the following command to install update installer silently [from the unpacked update installer directory]
    • install -silent –options “response_file_name”
  • This will install the update installer in websphere_root/UpdateInstaller

Download the fixpack

Response files

Now we need to create the response files for installing/applying the fix packs

  • Copy the extracted .pak files from the fix packs to websphere_root/UpdateInstaller/maintenance
  • Go to websphere_root/UpdateInstaller/responsefiles
  • Look for install.txt file
  • Copy install.txt as was_response.txt
  • Now open was_response.txt for editing
    • If you like the installer to check the file permissions before proceeding to install, uncomment the following line
      • -OPT checkFilePermissions=”true”
    • Specify the maintenance package to be installed using the option.
      • -W maintenance.package= “websphere_root/UpdateInstaller/maintenance/WAS_FPxxxx.pak
    • If you like to disable checking  of pre-requisites, uncomment the following like.
      • -OPT disableNonBlockingPrereqChecking=”true”
    • Specify where the websphere installation is using the below option.
      • -W product.location=”websphere_root”.
  • Save the changes to the response file

Applying fix pack

  • Now run the following command to apply the fixpack to websphere application server.
  • Go to websphere_root/UpdateInsaller
  • update.sh -silent -options <responsefile/response_file_name>

For installing fix pack for other components, follow the above stop as described for websphere application server fixpack. All you need to change is the location of the product location and maintenance package file path/names.

Important Notes

  1. Before applying fix pack, please stop all the websphere process on that machine, which are going to be affected.
  2. If you apply the fix pack as ‘root’ to a websphere installation which was installed as non-root, post fix pack installation, the entire product will be owned by ‘root’
  3. Before deciding on a fix pack, look for any security fixes released for that fix pack.  For example If you install FP35 for websphere 6.1 , you need to install a security fix pack for JDK.

WebSphere Admin ToolKit


This series concentrates on different useful tricks, tips and scripts which you can use in your routine administration tasks.  Your contributions are welcome and will be published with your name. When it comes to tips and tricks… experience counts more.

Some examples:

  • you have made some changes in the httpd.conf file and not sure if the syntax or something is correct. So you want to test it before you actually restart.
  • you want to remove the log files older than 30days
  • you forgot the password of your Key database
  • you want to write a wsadmin script. And looking for a help on which functions to use for a task.

If you want to find out all the posts in this series … check out “WebSphereAdminToolKit” category under categories section.