I have a BTS environment with separate bts / sql servers, every Sunday we do
a scheduled reboot, this has worked for about six months without issue.  Thi
s
past week a receive port was disabled as a result.  I think that the sql
server (which houses a file share that is referred to by the port) went off
line before the sql connection was broke with bts.  When bts tried to check
the file share and found that it was not available it disabled the port.
when the sql server came back online bts reconnected and all of the hosts
restarted without a problem, however the receive port was still disabled.

My questions are:
1. Is this expected behavior?
2. Are ports not supposed to auto-recover if they fail for some reason?
3. What is the recommended way to handle a situation such as this?

Thanks for any advice anyone can offer.

[ Post a follow-up to this message ]

hey guys - can I get a response here?

"Bill" wrote:

> I have a BTS environment with separate bts / sql servers, every Sunday we 
do
> a scheduled reboot, this has worked for about six months without issue.  T
his
> past week a receive port was disabled as a result.  I think that the sql
> server (which houses a file share that is referred to by the port) went of
f
> line before the sql connection was broke with bts.  When bts tried to chec
k
> the file share and found that it was not available it disabled the port.
> when the sql server came back online bts reconnected and all of the hosts
> restarted without a problem, however the receive port was still disabled.
>
> My questions are:
> 1. Is this expected behavior?
> 2. Are ports not supposed to auto-recover if they fail for some reason?
> 3. What is the recommended way to handle a situation such as this?
>
> Thanks for any advice anyone can offer.
>

[ Post a follow-up to this message ]

Bill,

1. Yes, this expected behaviour
2. The receive location will retry until the retry limit and then be
disabled requiring manual or programmatic intervention
3. Monitor for receive location failures and programmatically re-enable,
monitor and send notifications for manual intervention, use a more resilient
protocol like MSMQ

There is no differentiation between manually disabled and disabling caused
by failure. You do not want Biztalk to re-enable a receive location that has
been manually disabled. If you implement a monitor program you will need to
be able to specify which receive locations you are monitoring and be able to
change this. You do not want this program to re-enable a receive location
that you have turned off.

Greg

"Bill" <Bill@discussions.microsoft.com> wrote in message
news:4938C034-3F02-476B-9C13-C6D5F319D078@microsoft.com...
>I have a BTS environment with separate bts / sql servers, every Sunday we
>do
> a scheduled reboot, this has worked for about six months without issue.
> This
> past week a receive port was disabled as a result.  I think that the sql
> server (which houses a file share that is referred to by the port) went
> off
> line before the sql connection was broke with bts.  When bts tried to
> check
> the file share and found that it was not available it disabled the port.
> when the sql server came back online bts reconnected and all of the hosts
> restarted without a problem, however the receive port was still disabled.
>
> My questions are:
> 1. Is this expected behavior?
> 2. Are ports not supposed to auto-recover if they fail for some reason?
> 3. What is the recommended way to handle a situation such as this?
>
> Thanks for any advice anyone can offer.
>

[ Post a follow-up to this message ]

Thanks Greg that is the confirmation I was looking for.

"Greg Forsythe" wrote:

> Bill,
>
> 1. Yes, this expected behaviour
> 2. The receive location will retry until the retry limit and then be
> disabled requiring manual or programmatic intervention
> 3. Monitor for receive location failures and programmatically re-enable,
> monitor and send notifications for manual intervention, use a more resilie
nt
> protocol like MSMQ
>
> There is no differentiation between manually disabled and disabling caused
> by failure. You do not want Biztalk to re-enable a receive location that h
as
> been manually disabled. If you implement a monitor program you will need t
o
> be able to specify which receive locations you are monitoring and be able 
to
> change this. You do not want this program to re-enable a receive location
> that you have turned off.
>
> Greg
>
> "Bill" <Bill@discussions.microsoft.com> wrote in message
> news:4938C034-3F02-476B-9C13-C6D5F319D078@microsoft.com... 
>
>
>

[ Post a follow-up to this message ]