IBM WebSphere Application Server Notes

Clustering WAS

app server -> node -> cell -> cluster -> cell

Clusters can't span multiple cells XD (extended deployment) enterprise version of ND "federated appservers" - belonging to the same cell JSESSION - HTTP session id, clone id, EPOC (Clone id is for session affinity, EPOC is a version number for the synching caching of session at individual servers) Memory to memory is almost as slow as DB session replication. Serialization takes 90% of time, net I/O is 5% and only 5% is writing to either memory or DB Admin console runs on a web app part of WAS, talks to Admin Services (JMX objects) wsadmin (console app) talks to Admin Services over tcl/tk (jacl) or jyphon to Admin Services wsadmin can use direct access to WAS xml's with "none" protocol option in case admin services are down. It wont do runtime changes in this mode tracing CAN be enabled in runtime! the default tab is "configuration" meaning it is going to be remebered and turned on/off at the next restart Thread (core) dump for jvm: kill -3 pid (it might put it into an random (current dir) location) splitting web container and an ejb container does NOT help performance since it talks directly when on the same box and has to use RMI/IIOP (Corba) stack with ORB to communicate over the net. app servers can not be added to clusters. The clusters should be either based on one template server or have servers be re-created (deleted and then created) to become functioning clusters with identical app servers

It is good to install ND on a VMWare, so that loosing the host wont require reinstalling/configuring ND ND does not need many resources or be available

WebSphere config files

Starting with /opt/IBM/WebSphere/AppServer

• Servers are under profiles/AppSrv01/config/cells/xxxxCell01/nodes/xxxxNode01/servers/
• Passwords are under

LTPA

LTPA contains SYMMETRIC keys. time sensitive - client and server should be within 5 min of each other WebSphere supports exactly 1 LDAP

Sessions persistance (can combine different ideas)

• store in memory. good idea (?). bad in dealing with big or long lived objects.
• store in a DB. mediocre idea. CMP for Entity beans.
• Statefull Session Bean. bad idea. No work load management, session persistance and replication.

In v6.0 Statefull Session Beans can use memory-to-memory. still a bad idea.

WAS ND location

Regarding the Deployment Manager being installed on the same physical server as one of the nodes.This is not generally done, unless resources are extremely limited, and the environment is used for testing/development purposes.
One major drawback that I can think of - Port conflicts, SOAP, Web Container ports, etc...
This can lead to a lot of confusion for customers, especially as far as wsadmin scripting, launching Tivoli Performance viewer, web container port definitions in the plugin, etc...
The Deployment Manager is a very lightweight application/function. I have had good success with just having them on a customers VM infrastructure.

Logs locations for an embedded WAS

C:\Program Files\IBM\Rational\SDP\6.0\runtimes\base_v6\profiles\default\logs\server1\

websphere scripting example

to get all configs