Tuesday, 14 August 2012

The Thread was being aborted

A few weeks ago we started having an issue with a batch, to be precise it's a windows service that calls a web method that calls MS Dynamics CRM to generate a couple of files from data stored in the Dynamics CRM database. At any rate, all of a sudden it stopped working properly, it would fail at some point, reasonably early on in the process, probably it would go through about 1000 records.

Annoyingly, this coincided with a new release so naturally all suspicions fell on the build, this despite my protestation that just because two events occur one after the other does not mean that the first caused the second.

At any rate, after sneakily modifying the code in production to add as much trace logging as we could [Cowboys'r's], we found out to our surprise that it was failing while updating the records in Dynamics CRM. Unfortunately, the error was not very helpful as it seemed to vary between:

Unable to connect to the remote server


The thread was being aborted

After a lot of thinking and googling we thought we had come up with the answer: increase the number of connections.


It seems that when a client makes an authenticated call  a connection is opened and then closed, and since we were making loads of connections while processing our data, this seemed like the most likely culprit, as the connections available get used up.

In order to increase the number of connections available a registry hack and a reboot are needed:
  1.  Open registry editor. [from start | run | regedit]
  2. Navigate to this key [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters]
  3.  Set the TcpTimedWaitDelay key to 1388. [You might need to create this key. It's a DWORD value]
  4.  Set the MaxUserPort key to a high value, anything above 1388 and below 10000 ought to do it. [You might need to create this key. It's a DWORD value]
  5. Reboot.
We did this in one of our servers and in the morning I was extremely disappointed to see that the process had failed, but encouraged that it had processed about 2500 records. 

We ran the process manually a couple of times it was failing at roughly the same point, around 2500 records (by this point in time we had built a significant backlog of data) always with the same error:

The thread was being aborted

And then it hit me, it was timing out, so a simple fix was in order, i.e. increase the timeout on the web.config file of the web service.
<httpRuntime executionTimeout="300" />
I think that the default timeout is 90 seconds and that was clearly not enough to go through the 5000 records it can process daily (yep, it's limited to 5000 records by MS Dynamics CRM. Nope, I did not write the code)

No comments:

Post a Comment