Someone asked this questions on a forum
difference between High Availability and Work Load management ?
I tried to make it simple and easily understandable. So don’t take this as definition 🙂
Work Load management – How you distribute the load and manage it.
High Availability – How much time your solution/application is available.
Say you have an application. You define that this application must be available 364 days in a year. That is application’s availability. How do you achieve this? Create a failover system, backup plan, monitoring etc ..
Now you need the response time to be 1-2 seconds. This is not covered in above statement of availability. How do you achieve this then? you take multiple servers and distribute the incoming load among them to maintain the response time you need.
When to generate ? How to generate ? how to debug ?
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,*]
wsadmin>$AdminControl invoke $jvm dumpThreads Continue reading
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)
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
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
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