Change Integrated Solutions (WebSphere) Console Timeout

In IBM's Integrated Solutions Console (formerly known as WebSphere Console), the administrative interface for WebSphere 6.1, the default console user inactivity timeout is 30 minutes. I happen to think this is a bit short, particularly since most anyone using the console is a highly trusted user, generally an IT administrator who is well-versed in computer and network security practices.

For this reason, and since I find it such a hassle to come back to the console after a short time and be told that "Your session has become invalid", I change the timeout to something I think is more reasonable, like 720 minutes.

Please note that I am referring to the timeout for the admin console, not session timeouts.

If you are using WebSphere Network Deployment (and you should be) edit this attribute in the following file on the Network Deployment machine:

C:\Program Files\IBM\WebSphere\AppServer\profiles\Dmgr01\config\cells\NetworkDeploymentservernameCell01\applications\isclite.ear\deployments\isclite\deployment.xml

Set the attribute invalidationTimeout to the desired value, in minutes, where the maximum value is -1 (do not time out)


Restart the WebSphere service on the Network Deployment machine.


If you are not using Network Deployment.....you should be, so go implement ND and follow the directions above.


If you are still on WebSphere 6 (and maybe 5):

Edit the ${WAS_HOME}/systemApps/adminconsole.ear/deployment.xml file to change the invalidationTimeout attribute value to the desired session timeout. The default is 30.

Restart the application service.

Auto Restart WebSphere Application Servers

So you've installed the EnterpriseOne HTML application on your fancy WebSphere Application Server (uppercase) and you are doing some restart/reboot testing. If you are using WebSphere Network Deployment, as you absolutely should be, you may notice that if you reboot the entire box, the previously running application servers (lowercase) do not restart even though the node agent service is set to automatically start.

This is because a setting in the WebSphere Integrated Solutions Console (fka Network Deployment Console) and not the node agent service startup setting controls the startup state of the application servers.

The restart state behavior of the application servers is determined by what IBM calls the Monitoring Policy settings. These settings tell the node agent what it should do with the java processes after both an internal (to WebSphere) abnormal shutdown and a complete node restart.

The settings we are concerned with are Automatic restart and Node restart state. The first controls how WebSphere will react to an internal application server failure and the default is set to True. The second is how WebSphere will handle a complete node start (reboot) and the default is set to Stopped. This means that if you restart the physical box (or it reboots itself) you will have to manually start the application servers or WebSphere cluster of application servers in the WebSphere Integrated Solutions Console.

My philosophy on automatic starts is that it should be disallowed only in situations where automatically restarting will either undoubtedly fail (ex: failing back an E1 enterprise server on a W2K3 cluster) or could cause corruption. Since WebSphere is mostly at the presentation layer and since Oracle is making extensive progress with Failed Transaction Recovery, I prefer that the application servers start automatically on node restart.

To have the application servers automatically restart, set the Node restart state to RUNNING in the Servers> Application Servers> server_name > Server Infrastructure > Java and Process Management > Monitoring Policy section of the WebSphere Integrated Solutions Console. Click OK, save your changes, and test.

Simplified E1 URL

Wanna see an ugly URL?

http://thisismyservername:82/jde/owhtml


Can we please stop doing this to our EnterpriseOne users? Not only is it tedious and non-descriptive, it looks amateurish.

The use of aliasing and Virtual Hosting techniques in DNS, IBM HTTP Server (Apache), and WebSphere allows E1 JAS instances to be referenced by name instead of by TCP Port Number. DNS mappings, Apache VirtualHosts, and WAS Host Aliases are created to enable this solution. This gets rids of the port numbers.

Paper is here: http://sites.google.com/a/karamazovgroup.com/blogfiles/Home/whitepapers/E1%2CEliminatePortNumbersJAS.pdf?attredirects=0


In addition, we can get rid of the "/jde/owhtml" portion of the URL by using the Apache DocumentRoot directive.

Paper for this part is here: http://sites.google.com/a/karamazovgroup.com/blogfiles/Home/whitepapers/E1%2CSimplifiedURLusingDocumentRootv1.00.pdf?attredirects=0

These white papers are a bit dated in the WebSphere area but the methods remain the same.

When you get done you will have proper URL's that look something like this:

http://e1development
http://e1prototype

or

http://e1dv.domain.com
http://e1py.domain.com

or

http://whatevernameyourlittleheartdesires

Load Balancing at all Levels in EnterpriseOne with Web Technology

I am surprised to hear that so many people are not using all available methods to load balance and create redundancy in their E1 systems. This is not the first time I have read someone mention that Network Deployment is not a good solution. I think that ND is the only really feasible application-level load balancing and failover device available. I try to introduce redundancy into my system at every level in the following ways:


1) Network- Accomplished using either DNS round-robin, NLB, or a hardware device.

I haven't worked with NLB yet but apparently it offers improvements over DNS like fault tolerance and intelligent load balancing.

- DNS will continue to send network traffic to a down server and is rather dumb when balancing.

Note: DNS round-robin will recognize when just an HTTP server is down and route to the other HTTP server

- NLB will stop sending diners to the dead waiter's table : - )
- NLB is also supposedly session sensitive, meaning that it will continue to send packets to the server holding the active session.



Another possibility is using IBM's Edge Components that are included with the Tech Foundation.

If you have a lot of money a hardware load balancing device is the way to go


2) HTTP - Multiple HTTP servers (Apache or IIS) preferably on separate servers from WebSphere.

It is not always economically feasible to separate these from WAS but to ensure high availability
at the HTTP level one must have more than one HTTP server, fronted by a method mentioned above balancing the load to these servers.


3) WebSphere - On WAS 4 we cloned software JAS servers in server groups (Vertical and Horizontal) to ensure high availability at the WAS level. In WAS5 and WAS6 all we do is create a cluster of JAS servers and manage them with Network Deployment. There are a couple of items that need to be done with ND but this works and the load balancing works. Not sure why we would not take advantage of this and heck, it is easy to create a cluster. The use of a vertical cluster ensures efficient utilization of memory on the box and several small JVM's have much more efficient garbage collection than one large JVM. I am not sure how others are scaling their web systems without using WAS clustering. If you use a single instance and increase the JVM heap size to accommodate additional users the system will pause too long during garbage collection. I create 3 or 4 instances using clustering and give each one a 512 or 768 MB heap size.

As far as the comment about how NLB load balances, if you have sticky sessions configured you should get the same server as last time. NLB cannot determine that a JAS session is not responding and will continue to send network traffic to that box. If the server (hardware, OS, NIC, etc.) stops responding then and only then will NLB redirect. You have to count on WAS clustering (using Network Deployment) to direct away from failed JAS instances.

You have to use the right tools for the right job- NLB will redirect away from failed hardware, the HTTP WAS plug-in will redirect away from failed WebSphere servers, WAS clustering will redirect away from failed JAS instances.