Well the week didn't start in a very good manner but it sure ended that way. At work I've been working with IBM Cognos BI since september when I started at Stockholm University but it's not until now that I get some hang of it. We are working on upgrading the environment from 10.1 to 10.1.2 and as expected some things have changed and need looking into before installing it in the production environment and upgrading the content store database etc. The last major issue was solved today afternoon after a lot of logging and debugging.
The problem was that Internet Explorer 10 performed terribly while Google Chrome and Firefox showed stunning performance improvements. How could this be that IE behaved so much different than FF and Chrome? I started of looking into the developer mode of all three browsers (accessed through the [F12] button and narrowed it down to some specific JS webservice call from client to server and so I thought that this was due to some bad coding in Redmond, that IE simply didn't serialize some XML or something similar fast enough. Then there was the server side of things. Since we run the ISAPI version of the Cognos Gateway I started looking into the IIS log which showed that there were some HTTP requests but it didn't give much clue, for instance it didn't say for how long the requests took to process, but when I looked into the Failed Request Logging feature of IIS it showed that the ISAPI module took 10 seconds to process some of the requests. Where did Cognos spend these 10 seconds and why did only IE experience this?
The answer would unveil itself after activating the Log4J logging features in Cognos. As a first tier in the Cognos BI architecture you will most of the time find a Cognos Gateway running in either CGI or ISAPI mode (depending on the host web server, only IIS supports the ISAPI module) and behind this firs tier you'll find a multitude of services including Report, PowerPlay, Logging, Presentation etc. so the only thing we know so far is that somewhere behind the ISAPI module something is very slow (or at least executes along a different path) for the IE browser. Lucky for me there are extensive logging features built into all of these components which can be turned on/off through the ipfclientconfig.xml which will allow logging on different levels DEBUG/INFO/WARNING etc. through different appenders such as file/network etc. When looking into this for the gateway service there appeared an error message, which only displayed while in the IE browser or logging in (new session), along the lines of "unable to load user capability" and since I had seen this somewhere before in the context of cookies I fired up Fiddler. Fiddler is a great tool for eavesdropping into the HTTP conversation between client and server, it sits in between as a proxy and nowadays you don't even have to configure anything in the browser, just start it up. It seemed that the IE requests lacked all of the cookies named in the Cognos documentation, they weren't passed along with the requests. But why? Well the domain and path attributes of the cookie set by Cognos at log in were actually bad; the subdomain and path was missing and only superdomains were set. The effect of this was that Cognos for every request had to authenticate the user against our Shibboleth and gather the user attributes (groups, roles, abilities) from LDAP and content store respectively. In the normal case this procedure when logging on (the first request of made by the user when not in a session) and then it's not as bad but now this had to be done much more frequent and thus the user experience was terrible. The solution was to set the domain and path attributes for the cookies in the global settings in the Cognos configuration tool. Oh the sweet taste of success!
