The client was unable to reuse a session with SPID xxx, which had been reset for connection pooling. The failure ID is 29. This error may have been caused by an earlier operation failing. Check the error logs for failed operations immediately before this error message.

I was thinking that this is the same issue as described in http://support.microsoft.com/kb/2543687 but as per this KB, issue is currently being investigated and scenario described in the KB is not matching the issue I'm troubleshooting.

SQL Server 2008 instance with 8 processors will create 576 worker threads but in sp_configure it is hardcoded to 128 threads which caused contention in this case.

So we then changed this value to

EXEC sp_configure'max worker threads',0

RECONFIGURE WITHOVERRIDE

and restarted instance, now we longer have the 18056 error.

More information:

THREADPOOL waits only occur when a task is waiting to get assigned to a worker thread. This wait means server is out of worker threads and can’t bind the new connection request to a worker thread. In most cases the cause of THREADPOOL waits is that existing workers created by SQL Server are tied up with a long blocking chain or running long running pre-emptive work such as extended stored procedures. So when the connection (login) cannot get a worker thread, sp_reset_connection command timed out and it recorded the Error: 18056, Severity: 20, State: 29. The client was unable to reuse a session with SPID 350, which had been reset for connection pooling. The failure ID is 29.