Tridion Event System Timeout

4
votes

I am currently running Tridion 2011 SP1.

I am writing some code that runs whenever a page is published. It loops through each component template in the page, gets the component and writes out various fields to an XML document. For pages with many component templates or components with many fields this process can take a while to run. If the process takes more than 30 seconds I get an error

The operation performed by thread "EventSystem0" timed out.

Component: Tridion.ContentManager
Errorcode: 0
User: NT AUTHORITY\NETWORK SERVICE

followed by another

Thread was being aborted.


Component: Tridion.ContentManager
Errorcode: 0
User: NT AUTHORITY\NETWORK SERVICE

StackTrace Information Details:
   at System.RuntimeMethodHandle.InvokeMethod(Object target, Object[] arguments, Signature sig, Boolean constructor)
   at System.Reflection.RuntimeMethodInfo.UnsafeInvokeInternal(Object obj, Object[] parameters, Object[] arguments)
   at System.Delegate.DynamicInvokeImpl(Object[] args)
   at Tridion.ContentManager.Extensibility.EventSubscription.DeliverEvent(IEnumerable`1 subjects, TcmEventArgs eventArgs, EventPhases phase)

I believe I have three options.

1. Increase the timeout

This seems like a lazy solution and only hides the problem. There is no guarantee that the timeout problem won't reoccur. I'm also not sure where the timeout value is stored (I've tried changing a few values in the Tridion Content Manager.msc snap-in but no luck).

2. Do less in the actual event handler routine and have a separate process do all the hard work

This doesn't seem like the correct solution either. I would really like to keep all my event handler code in the one place. We have a solution like this in place for our live 5.3 installation and is a nightmare to maintain (it is very old and poorly written).

3. Make my code more efficient

My components have many fields and my code must delve deeper into each field if they are ComponentLinks. I guess because the properties of Tridion objects are lazy loaded there is one call to the API/database for each property I access. It takes on average 0.2 seconds to retrieve a property which soon stacks up when accessing multiple properties. If there was a way to retrieve all properties in one call this would be useful.

Any ideas?

5
tridion
Check if you have any exception in the Tridion event log. Do you know what exactly is timing out? - Andrey Marchuk
I am making a lot of calls to the API to get components linked to a component. Each call takes 0.2 seconds on average. Say I have a page with 20 components and each one of these components has 10 linked components, that's 200 calls to the Tridion API to get all the information I need. 200 calls * 0.2 seconds is 40 seconds. It seems to have a 30 second timeout limit therefore an exception is raised. - Kevin Brydon
That's an interesting question Kevin. I'm afraid that getting hundreds of components just takes time. Increasing the time-out sounds like the worst of your options. As I recently tweeted it changes "the software says this action takes too long" to "the user says this action takes too long". Is adding 30 seconds to any publish actions considered acceptable? - Frank van Puffelen
In my case it doesn't really matter how long it takes the event handler to complete. The important thing is that it is allowed to complete. The users will be aware that if they publish a page with hundreds of components they won't see the changes for some considerable time, but they are assured that the changes will happen at some point in the future. I can always add some code that provides some way to update the user on progress. How would I increase the timeout? - Kevin Brydon

5 Answers

6
votes

Have you considered running your event asynchronously? You can do this by changing the following line:

EventSystem.Subscribe<IdentifiableObject,TcmEventArgs(....)

to

EventSystem.SubscribeAsync<IdentifiableObject,TcmEventArgs(....)
2
votes

One thing you might consider doing is using the Component's .ToXml() method and get your values from the XML DOM instead of using the Tridion API. This is usually considerably faster, and you can use XSLT or Linq to "walk" through your fields.

If you are really only interested in fields, then just use the .Content (and .Metadata) properties and, again, use Linq or XSLT or whatever technology you want to parse the xml (except RegEx perhaps).

2
votes

You are simply doing a lot of processing and that takes time. Maybe there's a technical fix, but the first thing to do in this situation is to go back to Why and What? Publishing a page is fundamentally about rendering the HTML and binaries that you want to output for that page. How long should that take?

So please could you tell us why you are doing this? Perhaps part of the effort can be moved somewhere else without compromising on good design. If we know what the purpose is, perhaps we can help more.

2
votes

SDL Customer Support have advised that I increase the timeout. While not a great solution its the only one that is available. To do this

  1. On the server that the content manager is installed open the Tridion.ContentManager.config which should be located in the config/ subdirectory of the Content Manager root location, which defaults to C:\Program Files\Tridion\ or c:\Program Files (x86)\Tridion\
  2. Find the <eventSystem> node
  3. Increase the threadtimeout value (this is in seconds) to something higher (I put it to 120)
  4. Save the Tridion.ContentManager.config and restart the Tridion Content Manager Service Host service

Further documentation is available http://sdllivecontent.sdl.com/LiveContent/web/pub.xql?action=home&pub=SDL_Tridion_2011_SPONE&lang=en-US#addHistory=true&filename=ConfiguringEventSystem.xml&docid=concept_48C53F76CBFD45A783A3975CA72ECC49&inner_id=&tid=&query=&scope=&resource=&eventType=lcContent.loadDocconcept_48C53F76CBFD45A783A3975CA72ECC49. It does require a username and password to access.

0
votes

If you really need the processing time then I think you should write a web service that performs the actions you need, which you can call from the event handler. This would not influence user experience (in the case of a synchronous event handler) as much either.