Shawn_Moore

CA Clarity Tuesday Tip: Clarity 12.1 under Websphere 7

Discussion created by Shawn_Moore Employee on Sep 13, 2011
Latest reply on Sep 13, 2011 by Chris_Hackett
CA Clarity Tuesday Tip by Shawn Moore, Sr. Principal Support Engineer for 09/13/2011

Today's tip is a "heads up" tip that we've learned internally about running Clarity 12.1 under Websphere 7. Thanks to Sean Harp, one of our Senior Engineering Services Architects for the information comprising this tip.


There's a default property in the Websphere plugin that is used in the IBM HTTP Server (IHS) that governs timeouts on requests proxied to the Websphere App Server.

ServerIOTimeout (default = 60s)

The previous default value for ServerIOTimeout under Websphere 6.x was 0, which disables this feature. The default is now 60 seconds under Websphere 7, which definitely causes problems for Clarity as there are several types of operations that do take more than 1 minute to complete via the UI and/or SOAP requests.

What we have seen in the field is that when a long running request into Clarity (XOG, Task baseline, immediate report request) exceeds 60 seconds, the plugin hits this timeout and issues the original request a second time. This results in XOG errors and project lock errors when baselining.

This value should be set in the plugin-cfg.xml file by the Websphere administrator to "unlimited" by explicitly setting it to 0.

ServerIOTimeout=0

This issue can be diagnosed by setting the websphere plugin login to "TRACE" level and performing these long running actions (greater than 60 seconds) and examining the resulting trace log.

[Thu Sep  8 16:40:22 2011] 00004cc8 00000017 - TRACE: lib_rio: wait_on_socket: ServerIOTimeout fired.
[Thu Sep  8 16:40:22 2011] 00004cc8 00000017 - TRACE: returning NATIVE_WOULDBLOCK [timed out]
...
[Thu Sep  8 16:40:22 2011] 00004cc8 00000017 - ERROR: ws_common: websphereHandleRequest: Failed to execute the transaction to '<server>'on host '<host>'; will try another one


Enjoy!

-shawn

Outcomes