All Things WebSphere

Enhancements to the Liberty profile are as follows:

• Certification to the JEE 6 Web Profile, providing the assurance that applications leverage standards-compliant programming models
• Additional programming models such as web services that enable the expansion of Liberty profile applications beyond web applications
• New messaging capabilities, including support for JMS and message-driven beans, and a new single server message provider
• Ability to add Liberty features through a new system programming interface, enabling the customization of Liberty profile capabilities to meet your business needs through insertion of custom Liberty features
• Support for the NoSQL database MongoDB, a scalable, well-performing, and easy-to-use document-style NoSQL database
• Enhancement to security support, such as federated repositories, custom user registry, trust association interceptor, password hashing, and encryption of passwords in server configurations, which improves security for Liberty application deployments
• High Performance Extensible Logging (HPEL) for Liberty servers, which enables better administration and serviceability
• New Liberty administration features
• Clustering of server instances
• Support for caching via the WebSphere Web Cache (DynaCache) and distributed caching with WebSphere eXtreme Scale
• Ability to install the entitled WebSphere Application Server edition on developer
machines for development and unit testing purposes•
• WebSphere Application Server V8.5.5 tooling bundles updated with Rational®
Application Developer (RAD) V9 and the WebSphere Application Server Developer
Tools (WDT) V8.5.5

For details see http://www.ibm.com/common/ssi/cgi-bin/ssialias?infotype=AN&subtype=CA&appname=gpateam&supplier=897&letternum=ENUS213-137&pdf=yes

Scenario :  

Following is a comparison of Liberty vs a homegrown Tomcat "kitchen sink" type  server.

Server provisioning:
- Liberty, by design,  allows you to include only the features you need for your applications .
- Liberty  "minify" will subset the runtime for you, based on the configuration of the server
- produces a deployable binary server
- Homegrown is monolithic, will require significant manual effort and testing to figure out how to get back to "right-sized" server environment
-Or customer will need  to always deploy the 60MB homegrown server

- Liberty - configuration changes are dynamic - don't require server restart (i.e. jms, jdbc, vips)
- Homegrown - configuration changes will probably require restart

- Liberty - all the configuration goes in server.xml (or xml files included by server.xml) at customer's choice
-unique properties can be managed external to the server.xml, which allows customization per environment (Dev, FVT, Prod, ...)
- Homegrown - all the packages added to Tomcat will have their own config method/files

- Liberty log / trace files are consolidated
- Trace setting are consistent across components
- Homegrown will have logs/traces in multiple locations
- Homegrown components will NOT have trace setting suitable for production debug

Extensibility:
- Liberty runtime  can be extended by adding features in an architectural fashion, consistent with IBM developed features
-  Can create wrapper for 3rd party libraries which allows configuration of the new "feature"  consistent with IBM developed features
- Homegrown only allows  ad-hoc integrations of 3rd party jars

Dynamicity: 
- Liberty - config changes are dynamic - don't require server restart (i.e. jms, jdbc, vip settings)
- Homegrown, - config changes will probably require restart

Support
Liberty is fully supported by IBM
Homegrown?  middleware support team  + App teams + OSS communities
OSS communities (or public individuals) don't provide formal support.  Its based on best effort and interest as determined by the particular community / individual


Liberty - In the service stream Liberty has strict backward compatibility requirements
- no regressions on service releases
- new behaviors in service must be intentionally enabled by customer
Homegrown - Open Source communities don't adhere to strict backward compatibility.

Standards:
Liberty APIs are primarily based on open standards, allowing flexibility and a wider range of applications to work.
Homegrown - some APIs are based on standards but many are not. (i.e. "stax-2" is not a standard)

Licensing
- Liberty - IBM vet's all the OSS that we deliver and the code we develop.
- Homegrown - due diligence  is customers responsibility

Security differences
- Liberty supports hashing/encryption of passwords  in config, can be kept in separate property file
- Supports seamless integration with Tivoli and other authentication and authorizaton products.
- Homegrown security is likely to be a hodge podge of custom integration with different vendors.

Application Deployment
- Liberty allows automatic "drop in" of new app versions.  No server restart required.
 - Homegrown - Tomcat allows "drop in" deployment, but most likely the extensions do not

Central server management
Liberty collective will allow customer to build large administrative clusters
- i.e. start, stop, update config sent  to LibertyController which updates all servers in the collective
Homegrown - customer would need to develop management framework

Performance 
Liberty is significantly better than Tomcat

In case you are wondering where I have been all these months. I have taken a new job within IBM as a senior developer working on Cloud based application platform and services.

We just released Project Icap at IMPACT 2013
See https://www.ibm.com/developerworks/community/blogs/icap/entry/home?lang=en

1812 icap-v1.3 0430 from kelapure

Question Should we use dedicated JVMs as HA coordinators. And if so are the recommendations different between WAS versions 7.0, 8.0 and 8.5? 
Yes.
Recommendations are same across v7 and v85
It is a best practice to configure one or more preferred coordinator processes for each core group. This limits the movement of the coordinator and number of state rebuilds.
Configuring preferred coordinators is a best practice.
Ideally, assign processes that do not host applications and are located on machines with spare capacity as preferred coordinators.
http://www3.software.ibm.com/ibmdl/pub/software/dw/wes/0710_largetopologies/LargeWebSphereTopologies.pdf

If you want to configure WebSphere Portal Server to leverage WebSphere eXtreme Scale such that all the dynacache instances offload the cache data to Dynacache please go through the presentation below and the article.



Using WebSphere eXtreme Scale to enhance WebSphere Portal and IBM Web Content Manager performance
http://www.ibm.com/developerworks/websphere/techjournal/1206_inreach/1206_inreach.html

WebSphere Application Server on zOS in v7 introduced dispatch timeout improvements. This is a long way of saying that on zOS when a thread times out waiting on a connection or reading data from a socket, zOS, WAS and the JDK can nudge the request along. Read more here. This is also called ITI (Interruptible Thread Infrastructure). We love acronyms in IBM :-)  This dispatched thread interruption applies to ALL stalled threads, even those consuming excessive CPU.

So how does one set up ITI, ? You get ITI by default IF you do NOT have recovery set to session.

Remove the following JVM custom properties

Add the following properties 
protocol_http_timeout_output_recovery         Servant
protocol_https_timeout_output_recovery        Servant
server_region_stalled_thread_threshold_percent    80

There are also some other cool features like the MODIFY,DISPLAY, THREADS command

MODIFY ,DISPLAY,THREADS,TIMEDOUT,DETAILS
MODIFY ,DISPLAY,THREADS,AGE=30,DETAILS

This command, which offers both a SUMMARY and DETAILS format, displays information about server activity, which you can use for identifying requests that run longer than expected.

Another favorite runtime monitoring and  introspection feature of mine is the Dispatch Progress Monitor. In the flood of trace output from hundreds or thousands of requests, it is difficult to find traces related to the occasional long running request. This is where DPM helps as it can be enabled/disabled at runtime.

To enable the DPM, enter the MODIFY command, as follows:
MODIFY ,DPM, xxxx=
default dump action is the TRACEBACK.

Here is an example with the dump action set to TRACEBACK (and formatted for readability):
BBOJ0118I: ThreadDetails: ASID = 005B, TCB = 0X008CBE88, Request = fffff503,
Is JVM Blocked = false, Tried to interrupt = false, Given up = false,
Internal Work Thread = false, Hung Reason = Not Hung,
SR Dispatch Time = 2008/05/05 12:15:31.371625,
CTL Receive Time = 2008/05/05 12:15:31.366693,
CTL Queued to WLM Time = 2008/05/05 12:15:31.371328,
Details = , ODI Details = .JVM INTERRUPTIBLE THREAD, Monitor ACTIVE.
 
BBOJ0117I: JAVA THREAD STACK TRACEBACK FOR THREAD WebSphere:ORB.thread.pool
t=008cbe88: Dispatch Progress Monitor
Traceback for thread WebSphere:ORB.thread.pool t=008cbe88:
com.ibm.ws390.orb.ClientDelegate.invokeRequestCFW(Native Method)
com.ibm.ws390.orb.ClientDelegate.commonInvoke(ClientDelegate.java:998)

Often times developers will put objects in session and modify them without calling javax.servlet.http.HttpSession.setAttribute(String, Object) or javax.servlet.http.HttpSession.removeAttribute(String).

This is BAD because if session persistence is enabled the session manager does not know that the session is touched and fails to replicate to the persistence store. This persistence store can be another server, a database, a data grid or an appliance.

To solve this problem I have written a servlet that forces a sync and writes out all the session attributes to the persistence store at the end of the servlet request.

Take a look and download the src here ..
If you will also need to add the following filter.xml to your web.xml  sorry not everyone is on servlet 3.0 :-)