BizTalk Server - BTS Host thread abort issue

Author

BTS Host thread abort issue

Imran Shafqat

2004-09-22, 9:53 pm

Hi All,

In several situations where my application uses custom threads, I noticed
that BizTalk Host kills my timer thread although I'm using Server Timer
(System.Timers) . The behavior is completely in predictable. However I found
this persistent. Are there any guidelines or design considerations in
maintaining custom threads in BizTalk Server. Any help or pointer would be
highly appreciated.

Thanks in advance,

Irfan Ulhaq.

Matt Milner

2004-09-23, 5:51 pm

Where are you using custom threading? In components called by your
orchestration? Is there some reason you are not using the parallel or listen
shapes to handle this for you?

matt

"Imran Shafqat" <imranshafqat@hotmail.com> wrote in message
news:uvt9OAKoEHA.2900@TK2MSFTNGP09.phx.gbl...
> Hi All,
>
>
>
> In several situations where my application uses custom threads, I noticed
> that BizTalk Host kills my timer thread although I'm using Server Timer
> (System.Timers) . The behavior is completely in predictable. However I
> found
> this persistent. Are there any guidelines or design considerations in
> maintaining custom threads in BizTalk Server. Any help or pointer would be
> highly appreciated.
>
>
>
> Thanks in advance,
>
>
>
> Irfan Ulhaq.
>
>
>
>
>

Irfan Ulhaq

2004-09-24, 7:47 am

Hi Matt,

The threading is used in Adapters as there is no reason to use in piplelines
or orchestrations. let me explain the scenario,

HA Scenario:

In our problem scenario we have BizTalk clustered environment. Multiple
instances of Receive Ports (Adapter) are running on separate machines
pooling to same source location, to provide High Availability. This ensures
that no request is delayed or dropped. If one instance of receive location
is down, the other(s) are ready to process. However, a single request should
only be processed once.

So among the Nodes providing HA, a mechanism is developed to ensure that
only one node is Active at an instance of time and is available to process a
request, the others stay Passive. However, if the Active node is down, one
of the passive nodes get Active. This we call HA cluster. However, no two
Nodes should be Active at the same time. If a node got down, rejoins the HA
cluster, it will have to stay passive, as there is already an Active node
present in the HA cluster.

We have implemented this using .Net Remoting for inter Node communication
and Server Timers (System.Timers.Timer) providing the threading mechanism to
simultaneously controlling the Active and Passive mechanisms for a HA Node.
We call the Active Node as Primary, and Passive Node as Backup.

A Node that first becomes Primary starting sending remote signals to every
other Node after Time Interval T, using a Timer Callback method. A Backup
node periodically (after Time Interval T) checks if it is receiving signal
from a Primary node by another Timer CallBack method. If a Backup Node stops
receiving Primary signals, it attempts to become Primary based on its
priority among the other HA clustered Nodes. This results in one of the Node
replacing the previous Primary Node, and becoming New Primary. This new
Primary again starts sending remote signals to all other HA Nodes at T
Intervals.

This all is coded into the Adapter logic as a Signal HA Manager class. And
these Time threads should constantly be running forever, to ensure HA
results.

However we've noticed that during some cases that these timer threads are no
more become available and from that it is concluded that there might be some
guidelines in maintaining threads in BTS 2004.

Regards,

Irfan Ulhaq

"Matt Milner" <matt.milner@m3technologypartners dot com> wrote in message
news:eEiFdtXoEHA.648@tk2msftngp13.phx.gbl...
> Where are you using custom threading? In components called by your
> orchestration? Is there some reason you are not using the parallel or
listen
> shapes to handle this for you?
>
> matt
>
>
> "Imran Shafqat" <imranshafqat@hotmail.com> wrote in message
> news:uvt9OAKoEHA.2900@TK2MSFTNGP09.phx.gbl...
noticed[vbcol=seagreen]
be[vbcol=seagreen]
>
>

Matt Milner

2004-09-29, 8:02 pm

Ah, I see. I understand the reason for you what you are doing, but I think
you are going to run into trouble as there is likely a threading conflict
with the biztalk adapter framework managing threads outside of your control.
Since it is a problem with your timer threads, I doubt creating your own
thread pool would do you much good, eh?

Two suggestions I would have for you that might make this easier and the
code less complex:
1) instead of having to write your own clustering logic, is there a way that
you can have all services running but do locking on the data that you are
receiving. For example, if you setup a FILE receive location to run on in a
host that has multiple host instances, once one instance of the adapter
starts processing a file, the first thing it does is lock the file. This
way, when the second instances comes along to receive, it sees that file as
locked and skips over it for that turn.

2) the other option is to setup your host instances for the receive host you
are using to be installed on each machine. You can monitor the windows
service on the machine to make sure it is running and if not, start the
service on another machine. I don't think these services are cluster aware,
but you might be able to use the windows clustering. If not, any type of
managment system like MOM should allow you to monitor the service and start
another one on a different machine.

HTH,
Matt

"Irfan Ulhaq" <iulhaq@xavor.com> wrote in message
news:%238u9S9hoEHA.2784@TK2MSFTNGP14.phx.gbl...
> Hi Matt,
>
> The threading is used in Adapters as there is no reason to use in
> piplelines
> or orchestrations. let me explain the scenario,
>
> HA Scenario:
>
> In our problem scenario we have BizTalk clustered environment. Multiple
> instances of Receive Ports (Adapter) are running on separate machines
> pooling to same source location, to provide High Availability. This
> ensures
> that no request is delayed or dropped. If one instance of receive location
> is down, the other(s) are ready to process. However, a single request
> should
> only be processed once.
>
> So among the Nodes providing HA, a mechanism is developed to ensure that
> only one node is Active at an instance of time and is available to process
> a
> request, the others stay Passive. However, if the Active node is down, one
> of the passive nodes get Active. This we call HA cluster. However, no two
> Nodes should be Active at the same time. If a node got down, rejoins the
> HA
> cluster, it will have to stay passive, as there is already an Active node
> present in the HA cluster.
>
> We have implemented this using .Net Remoting for inter Node communication
> and Server Timers (System.Timers.Timer) providing the threading mechanism
> to
> simultaneously controlling the Active and Passive mechanisms for a HA
> Node.
> We call the Active Node as Primary, and Passive Node as Backup.
>
> A Node that first becomes Primary starting sending remote signals to every
> other Node after Time Interval T, using a Timer Callback method. A Backup
> node periodically (after Time Interval T) checks if it is receiving signal
> from a Primary node by another Timer CallBack method. If a Backup Node
> stops
> receiving Primary signals, it attempts to become Primary based on its
> priority among the other HA clustered Nodes. This results in one of the
> Node
> replacing the previous Primary Node, and becoming New Primary. This new
> Primary again starts sending remote signals to all other HA Nodes at T
> Intervals.
>
> This all is coded into the Adapter logic as a Signal HA Manager class. And
> these Time threads should constantly be running forever, to ensure HA
> results.
>
> However we've noticed that during some cases that these timer threads are
> no
> more become available and from that it is concluded that there might be
> some
> guidelines in maintaining threads in BTS 2004.
>
> Regards,
>
> Irfan Ulhaq
>
>
> "Matt Milner" <matt.milner@m3technologypartners dot com> wrote in message
> news:eEiFdtXoEHA.648@tk2msftngp13.phx.gbl...
> listen
> noticed
> be
>
>