On Nov 24, 8:38=A0pm, "Paul Somers[MVP]" <p...@[EMAIL PROTECTED]
> wrote:
> You need to do this just before sending the message, if it is direct
then
> from the orchestrtion that is sending the message, you flag it with an
> identifier.
>
> Once you have passed the point of no more receive, change the
identifier,
> then no subscription will apply and a new orch will be spawned or the
> messages will fail because of no subscribers.
>
> "Ryan CrawCour" <ryancrawc...@[EMAIL PROTECTED]
> wrote in message
>
>
news:074df47c-187b-4a52-b13e-25dbc514fb7a@[EMAIL PROTECTED]
> On Nov 21, 7:10 pm, "Paul Somers[MVP]" <p...@[EMAIL PROTECTED]
> wrote:
>
>
>
> > Hi,
>
> > Well try to avoid the zombies in the first place, and handle them. I
ha=
ve
> > used a pipeline that adds meta data to incomming messages, that based
o=
n
> > weather my orch can receive them or not tags the messages, then the
> > subscription for the recei ve is based on the meta data. Different
meta
> > data
> > can be handled differently, and you never loose a message, even via a
> > filter
> > on a send ****t.
>
> > Paul.
>
> > "Ryan CrawCour" <ryancrawc...@[EMAIL PROTECTED]
> wrote in message
>
>
>news:1eade265-5c5c-4fca-81c5-7c436aa79edb@[EMAIL PROTECTED]
>
> > >I have a business process that creates zombies ... yes i know; but
> > > right now we can't redesign the entire business process to avoid
this=
..
>
> > > We have a non-deterministic non-uniform sequential convoy that uses
a
> > > delay shape to stop the orchestration waiting indefinitely for the
2n=
d
> > > and 3rd parts to arrive, but move on and raise a business exception
> > > that we can action by starting another orchestration.
>
> > > This works most of the time fine, but under load and under certain
> > > conditions we have noticed zombies being created.
>
> > > The problem is that we cannot afford to lose ANY messages; so
instead
> > > of just terminating the instance and discarding the message(s) we
nee=
d
> > > to make sure these are resubmitted to the message box and allow the
> > > subscriber to pick them up and make informed decisions about what to
> > > do.
>
> > > With the help of Darren Jefford's code on
> > >http://blogs.msdn.com/darrenj/archive/2004/03/30/104135.aspxihave
> > > been able to get at the Message itself that caused this problem. I
ca=
n
> > > save it (with its context) to disk, I could then delete the context
> > > message and move the .out file(s) to another directory where i can
> > > hook up a File adapter receive location to pick them up. This
solutio=
n
> > > involves a fair amount of disk IO and am worried about performance.
>
> > > Is there another way to do this?
>
> > > Can I get at the message directly and resubmit this with code to the
> > > messagebox?
>
> > > Martjin Hoogendoorn's blog made mention of some code he had to
> > > resubmit messages but the link doesn't work anymore.
>
> > > Has anybody tried this?
>
> > > Does anybody have other suggestions about how to handle this
> > > situation?
>
> > > Thanks
>
> Hi Paul;
>
> Good advice thanks!
> How do you know whether or not your orchestration can receive them?
> How do you know when your orchestration is still running, but passed
> it's receive shape?
>
> In our case I don't think we can do this though and here's why ....
> We're using direct bound ****ts so there is no real way to use a
> pipeline to do this kind of processing; is there?
> The only place I could do this would be on the single onramp, which is
> a ****t bound to an MSMQ; which may help though so I will look into it
> some more.
>
> Cheers
> Ryan
That's a pretty decent suggestion ... I think I shall be implementing
this! Thanks.
|
