09-30-04 01:02 AM
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
>
>
[ Post a follow-up to this message ]
| 
