SDL Tridion 2011 SP1 HR1.
When I'm hitting the CME in the browser I see the
GetUserSettings is stalling. It is taking 10 minutes - seriously... 10 minutes to receive a response. As detailed below, other
TCM54 calls can be made following this and they are almost instant - resending the
GetUserSettings request via Firebug takes 10 minutes again...
Watching the requests/SQL I note the following
The request on the live server is almost instant. On UAT (on the right hand side) the request is stalled waiting for a response… I can see (through SQL Trace) that the following query is sent to the CMS and returns the correct data almost immediately on hitting the URL:
But the browser stalls calling the webservice and, as shown below responds after a lengthy period of time – nearly TEN minutes every time +/- 30 seconds…
On following this through with Firebug I can see that the xmlHttp request is where the delay starts… I thought the JSON object being empty was significant this is the case in the working Live and problematic UAT instance.
So eventually the CMS hits up… BUT… At this point on testing more, I can confirm that we’re unable open/amend Pages whilst I can still create and amend Components.
Pages are checked out and then stall in the following state (when opening an existing Page):
I’m not seeing any errors/waiting calls in Firebug etc.
Oddly enough I can see other calls (
GetLists etc) to the TCM54 Services are responding with a few ms as one would hope (these use the same xmlHttp request as above). This made me a little nervous about going straight in at the Network guys...
Half way through this investigation I became aware of an error from the Transport Logs:
DEBUG RollingStateRetriever - Unable to read transport state file, not adding to summary batch
So I tested and can see that I am also unable to publish. I’ve confirmed the license and checked all services (rebooted the machine) and have also confirmed the cd_storage, deployer etc look OK (and as shown above, the SQL DB is being queried) – the error that eventually returns is:
The socket connection was aborted. This could be caused by an error processing your message or a receive timeout being exceeded by the remote host, or an underlying network resource issue. Local socket timeout was '00:10:00'.
I’ve raised the issue with the client but they confirm no network changes have been implemented over the weekend - is there any way I can test-out/confirm this.
I’ve confirmed the COM+ services appear to be in order…
So it's inconsistent in which calls, but consistent in the
GetUserSettings call is always 10 minutes - and it's not clear why
GetList and opening Components is OK whilst opening a Page fails .. or rather doesn't register a fail but simply doesn't complete.
Any pointers to an appropriate testing strategy to help nail what element(s) in the chain could be causing/contributing to this issue would be great.
UPDATE: I tried the technique of disabling the Loopback Check (adding the registry DWORD DisableLoopbackCheck = 1 and rebooting) to no avail.
JAVA: (same version as live)
- java version "1.6.0_20"
- Java(TM) SE Runtime Environment (build 1.6.0_20-b02)
- Java HotSpot(TM) 64-Bit Server VM (build 16.3-b01, mixed mode)
The same hotfixes are applied per the working LIVE version.