|
Home > Archive > BizTalk Server > June 2006 > disabled port after reboot
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
disabled port after reboot
|
|
|
| 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.
| |
|
| 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. 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.
>
| |
| Greg Forsythe 2006-06-01, 1:17 am |
| 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.
>
| |
|
| 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 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...
>
>
>
|
|
|
|
|