Websphere application server (WAS) – Thread dump and Heap Dump


When to generate ? How to generate ? how to debug ?

Thread Dumps
If you get unexplained server hangs under WebSphere, you can obtain, from the WebSphere server, a thread dump to help diagnose the problem.

In the case of a server hang, you can force an application to create a thread dump.

On unix/Linux machines find the process id (PID) of the hung JVM and issue kill -3 PID.  Look for an output file in the installation root directory with a name like javacore.date.time.id.txt.
Using wasadmin prompt,
get the handle of the server
wsadmin>set jvm [$AdminControl completeObjectName type=JVM,process=server1,*]
execute
wsadmin>$AdminControl invoke $jvm dumpThreads Continue reading

Advertisements

dynamic cache in WebSphere


Dynamic Cache supports caching of Java servlets, JavaServer Pages (JSP), WebSphere command objects, Web services objects, and Java objects.

*  The concept of caching static information in a browser, proxy or a webserver provides an effective way to reduce network and processing requirements. A larger overhead of many web applications is related to the serving, not of static content, but of dynamic content based on user input and retrieval of data from backend resources such as databases.

How to enable Dynamic Cache
*  Dynamic cache is enabled by default on V6.1 WebSphere AppServers.
*  To enable Servlet and JSP caching from the admin console, navigate to the web container
Servers –> Application Servers -> <select server> -> webcontainer settings –> webcontainer
*  Check ‘Enable servlet caching’
*  Save and restart the Application Server to put the changes into effect.

Specify what to be catched
– Now servlet caching is enabled, if is necessary to define which dynamic content will be cached and the rules by which it will be cached or invalidated. servlet and JSP caching will be policy based using the cachespec.xml file. The preferred location for the cachespec.xml file is within the web applications WEB-INF folder. Continue reading

Work Load Management (WLM) in WebSphere


Work Load Management (WLM)

This is an overview of the options available for WLM in Websphere application server v6 and some common issues and resolutions in WLM

Two types of Workload Management (WLM) in WebSphere Application Server
-Web Server Plug-In WLM
-Enterprise Java Bean (EJB) WLM

=> EJB WLM balances WLM enabled RMI/IIOP requests between clients and clusters

The load balancing occurs for the following:
* JNDI Lookups
* EJB creates
* EJB business methods
* EJB removes

=> Types of clients that support EJB WLM

* AppServers hosting client application
* WebSphere managed Application clients
* Stand alone JavaTM clients Continue reading

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

Setting JVM arguments in WebSphere application server


 JVM arguments are used for configuring how the JVM executed. Any changes to JVM arguments needs restart of that JVM

WebSphere Application Server 7.x/8.x

  1. In the Administration Console select Servers
  2. Expand Server Type and select WebSphere application servers
  3. Click on the name of your server
  4. Expand Java and Process Management and select Process Definition > Java Virtual Machine
  5. Scroll down and locate the textbox for Generic JVM arguments.

WebSphere Application Server 6.1

  1. In the Administration Console select Servers
  2. Select Application Servers
  3. Click on the name of your server
  4. In the Additional Properties section, expand Java and Process Management and select Process Definition > Java Virtual Machine
  5. Scroll down and locate the textbox for Generic JVM arguments.

WebSphere Application Server 6.0

  1. In the Administration Console select Servers
  2. Select Application Servers
  3. Click on the name of your server
  4. Under Server Infrastructure, expand Java and Process Management, and click Process Definition.
  5. Under the Additional Properties section, click Java Virtual Machine
  6. Scroll down and locate the textbox for Generic JVM arguments.

mod_deflate – saves web server traffic by compression


  • The mod_deflate module provides the DEFLATE output filter that allows output from your server to be compressed before being sent to the client over the network.
  • mod_deflate allows Apache2 to compress files and deliver them to clients
  • With mod_deflate, you can compress HTML, text or XML files to approx. 20 – 30% of their original sizes, thus saving you server traffic.
  • Compressing files causes a slightly higher load on the server

How to use it?

1. Enable mod_deflate module

When we install apache2, mod_deflate should also already be installed on system
LoadModule deflate_module modules/mod_deflate.so Continue reading

A little about DCS, cluster members and Cluster member crash


Have you ever been asked this question in the interview?
how do you find out which cluster member was crashed/down?

The general answer we give is to go to administration console and check the individual server status or the cluster member status.
The other option is to use a third-party monitoring tool such as ITCAM, wily introscope, UniCenter and Nagios etc..
Have you ever checked the system.out log file of any individual server when one of the cluster member was stopped?
WebSphere has Distribution & Consistency Services (DCS), which is a part of the HA architecture. Using these DCS messages we can find which member of the cluster is down.

Here is an example:

I’ve a cell with name Test-Cell, which has a cluster with 6nodes each having 2 servers.
I’ve stopped one of cluster members. Then if you see the System.Out log file, you see message similar to the below:

[3/3/10 18:00:37:758 CET] 00000026 RoleMember W DCSV8104W: DCS Stack DefaultCoreGroup.TestRepln at Member Test-Cell\node01\server01: Removing member [Test-Cell\node02\server02] because the member was requested to be removed by member Test-Cell\node02\server01. Internal details VL suspects others: CC-Situation Normal
[3/3/10 18:00:38:176 CET] 00000023 VSyncAlgo1 I DCSV2004I: DCS Stack DefaultCoreGroup at Member Test-Cell\node01\server01: View synchronization completed successfully. The View Identifier is (22898:0.Test-Cell\node02\server01). The internal details are None.
[3/3/10 18:00:38:207 CET] 00000023 VSyncAlgo1 I DCSV2004I: DCS Stack DefaultCoreGroup.TestRepln at Member Test-Cell\node01\server01: View synchronization completed successfully. The View Identifier is (331:0.Test-Cell\node02\server01). The internal details are None.
[3/3/10 18:00:38:537 CET] 00000024 CoordinatorIm I HMGR0218I: A new core group view has been installed. The core group is DefaultCoreGroup.
[3/3/10 18:00:39:228 CET] 00000026 DataStackMemb I DCSV8050I: DCS Stack DefaultCoreGroup.TestRepln at Member Test-Cell\node01\server01: New view installed, identifier (332:0.Test-Cell\node02\server01), view size is 11 (AV=11, CD=12, CN=12, DF=12)
[3/3/10 18:00:39:343 CET] 00000021 DRSBuddyManag A CWWDR0006I: Replication instance terminated : Test-Cell\node02\server02

So, from the above messages, it is clear that server02 of Node02 was down and is removed from the coregroup.
After some troubleshooting/changes, i started the server which was down earlier. Now, if you observe the SystemOut.log, you can see the following:

[3/3/10 18:17:13:245 CET] 00000026 RoleMember I DCSV8051I: DCS Stack DefaultCoreGroup.TestRepln at Member Test-Cell\node01\server01: Core group membership set changed. Added: [Test-Cell\node02\server02].
[3/3/10 18:17:13:315 CET] 00000023 MbuRmmAdapter I DCSV1032I: DCS Stack DefaultCoreGroup.TestRepln at Member Test-Cell\node01\server01: Connected a defined member Test-Cell\node02\server02.
[3/3/10 18:17:30:337 CET] 00000023 VSyncAlgo1 I DCSV2004I: DCS Stack DefaultCoreGroup.TestRepln at Member Test-Cell\node01\server01: View synchronization completed successfully. The View Identifier is (333:0.Test-Cell\node02\server01). The internal details are None.
[3/3/10 18:17:30:353 CET] 00000026 DataStackMemb I DCSV8050I: DCS Stack DefaultCoreGroup.TestRepln at Member Test-Cell\node01\server01: New view installed, identifier (334:0.Test-Cell\node02\server01), view size is 12 (AV=12, CD=12, CN=12, DF=12)
[3/3/10 18:17:30:354 CET] 00000027 DRSBuddyManag A CWWDR0007I: Replication instance group membership changed: Test-Cell\node02\server02
[3/3/10 18:17:30:356 CET] 00000027 DRSBuddyManag A CWWDR0002I: Replication instance is active : Test-Cell\node02\server02
[3/3/10 18:17:30:358 CET] 00000010 ViewReceiver I DCSV1033I: DCS Stack DefaultCoreGroup.TestRepln at Member Test-Cell\node01\server01: Confirmed all new view members in view identifier (334:0.Test-Cell\node02\server01). View channel type is View|Ptp.

You can see a meesage that it added a new member to the coregroup.

About DCS:
There are two main versions of DCS: Core DCS and Data DCS. There is one Core DCS per process and it provides membership services among peer processes. These processes together form a Core Group. A process may be a member in one or more named Core Groups. Applications running on these processes can be members of application groups. Application groups are subsets of a particular named core group. A Data DCS component can be associated with each member of an application group.
DCS provides a mechanism for communicating information (distribution) among members with a given quality of service. Failure detection mechanisms that support and allow guaranteed quality of service are an inherent part of DCS and its services. DCS supports WebSphere components’ state replication requirements (like http session and stateful beans) as well as the distribution and synchronization of WebSphere artifacts for performance, scalability, and availability

you might see the same post else where on internet … because many are just copying the content with a reference to the origina.l post