Tridion 2011 SP1 Core Service Timeouts

Question

Has anyone ever experienced timeouts with core service? At times, we experience timeouts while simply reading, getting a list of components. We are using the netTcp binding and we have adjusted timeout settings in the applications config file. This has not helped though. Any thoughts?

I ran a trace on WCF and this is the error I received; 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:05:00.0000001'.

I normally get this when I bump up the timeout to 10 minutes

Here are the settings in my app.config;

<netTcpBinding>
  <binding name="netTcp"
  closeTimeout="00:3:00"
  openTimeout="00:3:00"
  receiveTimeout="00:3:00"
  sendTimeout="00:3:00"
  hostNameComparisonMode="StrongWildcard"
  maxBufferSize="10485760"
  maxBufferPoolSize="524288"
  maxReceivedMessageSize="10485760"
  transferMode="Buffered">
  <readerQuotas maxDepth="32"
  maxStringContentLength="8192"
  maxArrayLength="16384"
  maxBytesPerRead="4096"
  maxNameTableCharCount="16384" />

  </binding>

    </netTcpBinding>
  </bindings>    

I am reading through 4100 components.

Actually reading the components went fine. I encountered no timeouts this time. However, when updating, I always get a timeout. Sometimes it is right away and sometimes it times out server components in. Why am I updating components this way? We have a large amount of content that needs ported to another environment/database. The developers of this content do not clean up there invalid components. So, I am searching there content folders for invalid components. I then send them a report on what to fix.

I spoke with our DBAs and they ensure me that there are no problems with the database. I wish I could see for myself. :) No permissions to run performance queries against the CM database.

I am checking into Siva's post. This might be the answer to our issue as well.

Answer 1

It can depends of many reasons:

1) If you have timeouts all time - there is something with your connection/ configuration(for example configuration timeout is too small).

2)If you have them from time to time (as I understood it's your situation) here can be another reasons and another solutions and ways to analyze them. First of all - don't despite connection problems (you can get this by profiling your applications, for example with Fiddler and Wcf servers, for example with enabling tracing).

From my experience of the implementations of the WCF-related applications (mostly it was with Tridion CoreService :)) - the main reason of such problems or performance law quality - is non closed WCF - clients. So - you create always new clients and not dispose them:

CoreServiceClient = new CoreServiceClient();
// Here your logic
CoreServiceClient.Close();

Note, that you can have network/server limitations on the number of connections and new connections will wait while old are not closed and you will get timeout exceptions.

Also you can have application where you have more opened connections then limitations are (by design)...

Another one example I faced about week ago and we were not able to find reason for few days with other developers: You have StreamDownloadClient and code like this:

Stream stream = _streamDownloadClient.DownloadBinaryContent(itemId);
using (FileStream fileStream = new FileStream(location, FileMode.OpenOrCreate,FileAccess.Write))
{
  stream.CopyTo(fileStream);
}

So you don't close stream, which you have received with StreamRequest. After some such calls (totally randomly) we were not able to do any call to server (even with other clients, related to other endpoints).

The main I want to say - application-related problems with timeout can be different and sometimes it is very hard to understand, what the reason of problem. And without any other information about your application we can't help you.

Answer 2

If you're getting a timeout - any type of timeout, not just CoreService - then something is taking too long.

Modifying the timeout may help temporarily, but is not addressing the root cause, which is that some part of your SDL Tridion implementation is not behaving properly.

The most common issue is database performance, so make sure you execute the database performance as often as required by your environment.

2nd most common would be network performance, but that's a harder one to crack. Adding details about the error message shown by Tridion may help us get you a more detailed answer.