Configure IHS logging to show which WAS server handled a request

LogFormat "%h %l %u %t \"%r\" %>s %b %{WAS}e" sometag

It can also be useful to capture the JSESSION ID as follows... 
LogFormat "%h %l %u %t \"%r\" %>s %b \"%{JSESSIONID}C\"" sometag

IHS ServerIOTimeout

There can be a number of reasons for seeing a message like the one below in your http_plugin.log

ERROR: ws_common: websphereHandleRequest: Failed to execute the transaction to 'myClusterMember' on host 'myHost'; will try another one

... but a common reason is that ServerIOTimeout in plugin-cfg.xml is set too low 

To verify, set your log level to trace (i.e in plugin-cfg.xml change LogLevel from "error" to "trace"), wait for RefreshInterval (or bounce IHS if you're impatient) and look for the following message...

lib_rio: wait_on_socket: ServerIOTimeout fired.

Point to note.. if you are seeing this message in an environment where you have SSL Client Authentication enabled (aka 2-way SSL) chances are that you'll also be seeing GSK errors (look for PARTNER CERTIFICATE). I saw this and spend a while chasing down a non-existent trust issue. I then realised that the reason this was happening is because (I think) that the ServerIOTimeout was firing during the SSL handshake.

ps... don't forget to set your LogLevel back to "error"

Wrong HTTP host header when deploying a BPD from Process Centre

An interesting issue I came across recently with regard to deploying a BPD from Process Centre ...

This assumes you're deploying to a cluster of Process Servers (v7.5.1) that are sitting behind an IHS webserver and that you have set up things in 100Custom.xml such that the deployment is routed via that webserver

It also assumes that you have removed all virtual host aliases on the process server cell leaving only the webserver port... i.e no http(s) comms will match a vhost alias except that of the webserver

If you have this setup, the deployment will fail and flag the following error in Process Centre's AppTarget SystemOut.log

....

....
Caused by: com.lombardisoftware.core.TeamWorksException: Could not retrieve data, HTTP response code: Not Found 

....

....

On enabling trace within your IHS plugin you'll notice that the POST request over which the deployment is being attempted trying  to match a vhost entry of  <hostname>:443 even though you've set your process server port to 11000 and that is the actual TCP port being used.

....

....

TRACE: ws_common: websphereVhostMatch: Failed to match: lonbpmwebst.gslb.db.com:443
....

....

I'm not sure why yet, but it seems that for some reason the $WSSP plugin header is being set to 443, which, if you're as OCD as I am won't exist because you would have removed that particular vhost entry. 

The workaround for now is to recreate the 443 alias under the relevant virtual host but it's not elegant.