2

Our BizTalk 2016 environment consists of 2 application server running in a group with CU5 and FP3.

We have 24 applications deployed. Across this applications we have 27 receive locations with the new sFTP WinSCP adapter configured. For all sFTP receive applications we have the "Connection Limit" configured to 5. We have 6 different sFTP Server we are connecting to.

After approximate 2 hours, we have the following event log warnings and the receive locations stop working:

"The adapter "SFTP" raised an error message. Details "The WCF service host at address "sftp://..." has faulted and as a result no more messages can be received on the corresponding receive location. To fix the issue, BizTalk Server will automatically attempt to restart the service host."

Against the event log message the service host is not restarting automatically.

Has someone any idea how to fix this issue?

Dijkgraaf
  • 11,049
  • 17
  • 42
  • 54
David Troska
  • 21
  • 4
  • You might have to set the Logging on that particular receive location and look at that. Warning: We've noticed that there are a large XML log files with a .tmp extension being generated in the %TEMP% folder for the BizTalk host user after applying CU5 and the new WinScp, although the logs appear to be for a port that we have not enabled logging for. We've also had a receive location stop receiving silently after getting a number of these warnings and have had to restart the Host Instance manually. Also check the frequency of the polling, the default is 5 seconds! – Dijkgraaf Feb 19 '19 at 20:08
  • Logging is enabled for the receive loacations and we see that the adapter stops working as at some point no more loggs are written. Our polling intervalls are from 15 Minutes up to 240 Minutes. After a manually host instance restart the receive locations are working for a while but than they get in the same issue. Unfortunately a manual host instance restart is not a solution for us, as we need to receive the data from the respective SFTPs for 24/7. – David Troska Feb 20 '19 at 09:11
  • Another thing that seems to help is to set a schedule on the ports for which you only expect files during certain times. We had an issue in 2013 R2 with a port that would silently stop picking up. Since we set a schedule on it, the issue has not re-occured. – Dijkgraaf Feb 25 '19 at 03:30
  • Did you find a fix or workaround in the meanwhile – Frédéric Gobert Jul 24 '19 at 13:05
  • As we had seen that one of the TrackingData_x_x tables had more and more data that couldn't be processed by the biztalk jobs the Microsoft support suggested us 1. to increase the worker threads 2. to disable not necessary tracking data (we disabled alle orchestration tracking and message tracking, since we use biztalk360 for receive and send port autocorrection) This worked for us with the sFTP problem. – David Troska Jul 24 '19 at 13:38
  • Hi, I increased the minimum worker threads from the host instance from the default 25 to 100. This indeed seems to have done the trick, memory of the host instance is stable and the 50 SFTP receive locations running on the instance are still all functioning. With the defualt worker threads locations would start to stop working after a couple of hours. So do you think we can conclude thread starvation causes this problem? – Frédéric Gobert Jul 25 '19 at 06:10

2 Answers2

1

Try out CU7 as it includes a couple of SFTP fixes.

r3verse
  • 1,000
  • 8
  • 19
0

The latest version of BizTalk Health Monitor comes up with the following Important Warning

The host instances of 'hostinstancename' need more worker threads per cpu to run correctly SFTP Receive Locations. Increase so the "Maximum Worker Threads" property to 500 for these host instances and be sure they are dedicated for this SFTP Receive Locations

So things to look at are

  1. Have a dedicated host for receive locations using SFTP
  2. Increase the Maximum Worker threads setting to 500
  3. Check how frequently you poll (the default is 5 seconds)
  4. Put a schedule on to only poll during the periods you need.
  5. Disable message body tracking if it is not needed.

enter image description here

Dijkgraaf
  • 11,049
  • 17
  • 42
  • 54