3

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.

  • Would you please add specific error message output in your question. – Nickoli Roussakov Nov 12 '13 at 16:14
  • Could you also add some information to this? Such as your current timeout settings, data sizes on your end points and also the number of component you are trying to return? – johnwinter Nov 12 '13 at 16:20
  • Have a look at this answer SDL Tridion times out when publishing multiple items – Siva Charan Nov 12 '13 at 16:47
  • My assumptions were mostly related to client-related timeouts. I think you have server-side timeout ("receive timeout"). Are there any additional error messages in the Event Viewer? What Database do you use ? – Syav4eg Nov 12 '13 at 22:04
5

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.

3

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.