01-18-05 12:50 PM
We've solved the problem by opening a support case with Microsoft Support.
Here are a summary of the problem and the solution.
Symptom:
We were seeing some weird periodic blocking of access to the network file
share from the machines running BizTalk, which, running in a group, both had
20 file receive locations pointing to the same network fileshare in
different directories. Other machines accessing the same file share
simultaneously did not show the blocking. Stopping the BizTalk service also
removed the blocking.
Identification:
MS Support sent various KB's concerning exhausting the number of concurrent
SMB connections. This led us to the performance counter "Current Commands"
on the "Redirector" object. Looking at this counter immediately showed the
periodic behaviour:
BizTalk made the value climb to 50 after start-up and kept floating under
50, sometimes coming down to 40. Looking at the curve showed that this was
clearly some maximum value.
When we then tried to perform some simple copying of files on the same
machine while the value was 50 or 49, the value would climb over 50, and the
copying would block/stall.
Once (seemingly randomly) the counter dropped below 50 again, the copying
would complete immediately.
Stopping the BizTalk service made the counter drop to 0.
Troubleshooting and experimentation:
We experimented a bit with some registry keys relating to the resources
available for SMB connections, primarily:
<http://www.microsoft.com/resources/.../2003/all/deplo
yguide/en-us/Default.asp?url=/resources/documentation/WindowsServ/2003/all/d
eployguide/en-us/58903.asp>
But it didn't seem to have any effect. Also there are other registry keys to
control the maximum NetBIOS connections.
Solution:
In an attempt to instead lower the needed number of SMB connections, MS
suggested that the high number of connections could be caused by BizTalk
file receive locations simultaneously using directory change notification
and simple directory polling, and suggested turning of the polling with:
Registry hive -
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControl
Set\Services\BTSSvs{GUID}\.
Key Name - FileReceivePollingInterval
Type - DWORD
Value - 1 (That's right, "1" actually disables it, not "0" as you would
expect.)
This is actually a documented key:
<http://msdn.microsoft.com/library/d...n-us/operations
/htm/ebiz_ops_adapt_file_lahz.asp>
This made the counter drop to coincide with the number of enabled file rec.
loc.s - 20.
Best regards
Rasmus Kristensen
"Rasmus Kristensen" <rasmus.kristensen@accenture.com> wrote in message
news:e8o6kP89EHA.2676@TK2MSFTNGP12.phx.gbl...
> Hi,
>
> I have two BizTalk Server 2004 servers in a group, with file receive
> locations on a network fileshare.
> I have experienced that when I drop a file in a file receive location, it
> sometimes takes a while to be picked up by BizTalk, and sometimes not
being
> picked up at all, due to the file receive location have been disabled,
> because all the network retry attempts have been exhausted.
>
> I have verified that the user account running biztalk have fileshare
access
> and NTFS permissions on the fileshare.
>
> I'm also able to access the fileshare from another server, and getting
fast
> response from the fileshare, but when logged on the biztalk servers, and
> browsing the the fileshare, response is slow.
>
> Have anybody seen this behaviour or something like it?
>
> Kind regards
>
> Rasmus Kristensen
>
>
[ Post a follow-up to this message ]
| 
