All Things WebSphere

Recently I had an opportunity to present at IMPACT 2011 WebSphere Software group conference on various Java EE6 specifications that we have been working on in WebSphere Application Server 8. I also threw in my WebSphere eXtreme Scale pitch for free :).  All session slides are available here http://www.websphereusergroup.org/kelapure/blog/documents.one

Servlet 3.0 is a new specification that is part of the Java EE 6 technologies. This session will introduce you to the new features of Servlet 3.0 and explain how you can leverage them in your applications. The session will focus on two major themes: ease of development, and improving application scalability. This session is intended for Java EE developers, administrators, and architects.

Now that cloud and its enabling technologies like application, platform, software virtualization are hot and sexy, I am jumping on the bandwagon too :-) with some specific advice regarding WAS deployments in the cloud.

In order to leverage the full awesomeness of  your WAS virtualized deployment, it is critical to do the following :

Tuning WAS for idleness: WAS system components can sometimes be more chatty than teenagers aka in corporate speak WebSphere schedules timed events to check for system updates and the availability of other servers; keeping the entire infrastructure up-to-date and running flawlessly. There are several configurable timers and options which affect the amount of background processing during idle windows. It is critical to tune these timer threads and system daemons to reduce background processing within the application server. This helps the hypevervisor technology manage the guests better. It allows virtual images to swap in and out, thereby leading to better resource utilization and less over-commit. Follow the recommendations in the document below for tuning WAS, for idleness in dense virtual environments:  http://bitly.com/lC0YQe
http://webspherecommunity.blogspot.com/2011/05/tuning-for-idleness-service.html

Tune the JVM: In order to use Java effectively in the cloud you should avoid over commit, use less and share more.
– Avoid over-commit
  •  Matching scenarios: sandbox, legacy systems
  •  Limits cost savings
– Use Less
   •  Trade off some performance for memory
   •  Classic speed/space trade-off
   •  Easy - Just some Java command line tuning
– Share More
   •  Requires multiple JVMs per Guest OS
   •  Easy – one additional Java command line option  -Xshareclasses

Enable class sharing between JVMs using the -Xshareclasses JVM argument. This reduces the physical RAM usage when running multiple JVMs and improved start-up time. This option is ONLY available on the IBM JDKs. The shared cache contains Application classes, Metadata (JIT data, class file locations, debug, ...) and Ahead-of-time (AOT) compiled code which is shared across JVMs on the same guest OS. Tuning the shared class cache.

Select the right garbage collection policy i.e. optimize for throughput, pause time or short lived objects/web. Correctly set the heap sizes for your JVMs. Remember the maximum heap size setting should be 43% larger than the maximum occupancy of the application. Generally speaking, tune and restrict the JVM heap size to as small a value you can live with.

The five recommended tools that every WebSphere Application Server sysadmin and developer should have in his arsenal to debug and resolve problems are

• IBM Monitoring and Diagnostic Tools for Java 
• Dump Analyzer 
• Garbage Collection and Memory Visualizer (GCMV) 
• Memory Analyzer (MAT)
• Health Center

• IBM Thread and Monitor Dump Analyzer for Java (TMDA) [Tech Preview]

When to apply these tools is summarized by the table below:

Often times it becomes critical in operational scripting or even in your application code to determine the current runtime version of WAS. The Server mbean provides exactly this facility.
Below is a set of wsadmin script commands using AdminControl that you can use to query the Server mbean.


wsadmin>set server [$AdminControl completeObjectName cell=smitaNode02Cell,node=smitaNode02,name=server1,type=Server,*]
WebSphere:name=server1,process=server1,platform=proxy,node=smitaNode02,j2eeType=J2EEServer,version=8.0.0.0,type=Server,mbeanIdentifier=cells/smitaNode02Cell/nodes/smitaNode02/servers/server1/server.xml#Server_1183122130078,cell=smitaNode02Cell,spec=1.0,processType=UnManagedProcess


wsadmin>$AdminControl getAttribute $server state
STARTED


wsadmin>$AdminControl getAttribute $server platformName
ND


wsadmin>$AdminControl getAttribute $server platformVersion
8.0.0.0


wsadmin>$AdminControl getAttribute $server serverVersion
--------------------------------------------------------------------------------
IBM WebSphere Product Installation Status Report
--------------------------------------------------------------------------------


Report at date and time April 26, 2011 3:09:10 PM EDT


Installation
--------------------------------------------------------------------------------
Product Directory        C:\WebSphere8\f1116.06
Version Directory        C:\WebSphere8\f1116.06\properties\version
DTD Directory            C:\WebSphere8\f1116.06\properties\version\dtd
Log Directory            C:\Documents and Settings\All Users\Application Data\IBM\Installation Manager\logs


Product List
--------------------------------------------------------------------------------
NDTRIAL                  installed


Installed Product
--------------------------------------------------------------------------------
Name                  IBM WebSphere Application Server Network Deployment
Version               8.0.0.0
ID                    NDTRIAL
Build Level           f1116.06
Build Date            4/19/11
Architecture          x86-64 (64 bit)
Installed Features    IBM 64-bit SDK for Java, Version 6


--------------------------------------------------------------------------------
End Installation Status Report
--------------------------------------------------------------------------------


wsadmin>$AdminControl getAttribute $server processType
UnManagedProcess


wsadmin>


This exact same code can be written in java as well using the AdminClient interface
See http://www.ibm.com/developerworks/websphere/techjournal/0302_cundiff/cundiff.html
also http://alvinabad.wordpress.com/2009/02/15/automating-websphere-using-jmx/

With these tools in hand you can interrogate all the characteristics of your current WAS server :
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.websphere.javadoc.doc/public_html/mbeandocs/index.html

Today I want to highlight a free edition of WebSphere Application Server for Developers i.e. WAS4D

WAS4D is a standalone WebSphere Application Server development runtime which is

• Free offering for projects that don't warrant the expense of a priced and supported runtime on the developer desktop.

• Same as the WAS server type provided in Rational Application Developer for test and debug.

• Identical to the production runtime environment your applications will eventually run on. 

• Licensing restricted to development use only.

http://www.ibm.com/developerworks/downloads/ws/wasdevelopers/index.html
Please use WAS4D to develop your JEE applications for free :-)

Sometimes customers get conflicting advice on the WebSphere Application Server HAManager component like so ...

1. I would enable HA on everything........ Even if applications aren't using it or don't need it, there are components/functions of WAS that rely on it 
2. You can disable the HA Manager if the applications do not require it 

The two statements are less conflicting than they may appear. The points to consider when enabling or disabling HAManager with WebSphere are as follows:

1. The HA Manager will use a certain amount of resources (CPU and memory).
2. There are a number of WebSphere components (Memory-to-memory cache replication, Session memory persistence, Stateful Session Bean failover, Singleton failover, Workload management routing, On-demand configuration routing & transaction log failover) that use the HA Manager. These components will add their own resource usage on top of what the HA Manager uses by itself. Depending on the topology, that resource usage may be significant.
3. New dependencies can be created on the HA Manager at any time. These dependencies may be added in the service streams (Feature in Service). While we strive to keep the list of dependencies (in the Info Center or Large Topology White Paper) up-to-date, new dependencies can be added without our knowledge.
4. Customers may consider disabling the HA Manager to save resource.

Generally speaking, we don't recommend that customers disable the HA Manager. We do recommend applying the most current tuning. A number of customers have disabled the HA Manager and caused themselves problems. The most common symptom will be an application routing issue. If a customer decides to disable the HA Manager, proceed with caution. Realize that you may need to re-enable it in the future.

 http://www.ibm.com/developerworks/websphere/library/techarticles/0710_largetopologies/0710_largetopologies.html

The com.sun.faces.util.LRUMap object can hold on to a lot of memory as this is used to hold the various JSF views in the session. There are two types of JSF Views stored in the session. Logical Views in session and Number of views in session: A logical view is a top level view that may have one or more actual views inside of it. This will be the case when you have a frameset, or an application that has multiple windows operating at the same time. The LOGICAL_VIEW_MAP map is an LRU Map which contains an entry for each logical view, up to the limit specified by the com.sun.faces.numberOfViewsInSession parameter. Each entry in the LOGICAL_VIEW_MAP is an LRU Map, configured with the com.sun.faces.numberOfLogicalViews parameter.

By default the number of views stored for each of these maps is 15. Therefore you can see how it could end up using a lot of memory. The value of com.sun.faces.numberOfViewsInSession and com.sun.faces.numberOfLogicalViews does not have to be "4", it can whatever you feel is adequate for your application.If either of these parameters are not in the application then it will store up to 15 view in the LRU Maps. Setting these values to something lower will result in lower memory usage by JSF.

The actual number depends on your application. Basically, if we can't find a JSF view in the session to restore we will create new one. In general, a complex application is one that would allow a user to move back and forth to pages (think something like a wizard), or an application that contains framesets or a lot of pop up windows. For example, if a pop up window is used to fill out some information and then click submit to go back to the original page... that would require storing more views in session.

But I've always found 15 to be a high number, especially if the views are large (contains quite a lot of JSF components and their state). One thing to remember is each LogicalView can contain the set number of Actual views. That is where the idea of a frameset comes in -- one logical view for the parent page, and the actual views are the different frames.

You can find more information at the following  link, starting with, "A comment on the numberOfXXX parameters."