Re: Strange behaviour in pipeline

From: DL (dan_at_dont.spam.me.com)
Date: 08/18/04


Date: Wed, 18 Aug 2004 14:15:30 -0400

One quick thought - does your "incorrect" file's name match the filter
criteria for the port? e.g. not sending a .txt file to a port looking for
*.xml?

DL

"Karagu" <Karagu@discussions.microsoft.com> wrote in message
news:81952875-7815-4C29-BB7C-8002F307D1BD@microsoft.com...
> Hi!
> I'm having a real hard time trying to understand the following behaviour:
> I have succesfully deployed the "HelloWorld" sample wich comes with the
SDK,
> and that basically just takes an incomming file from a receive location,
maps
> the content in that file into a new one, and puts the new file in an
> Out-catalog. I can drop the test file provided within the sample
> ("SamplePOInput.xml"), and out comes the out-file. So far so good...
> However, a strange thing happens (at least if you ask me) when I drop
> another file, wich is incorrect according to the expected content in the
> incomming file: the incorrect file that I drop in the receive location
> remains in that receive location instead of "dissapearing" into Biztalk,
and
> there are no entries what so ever in the event log about that incorrect
file.
> You could get the impression that nothing happens with the file, but if I
> look in HAT -> Operations -> Service Instances, I can see that two new
> instances of type "Pipeline" and with status "Active" are created each
> minute, until I manually delete the file from the receive location. These
> instances have exit code "-1061153238", wich I have found absolutly no
> information about...
> I'd appreciate if anyone could explain this behaviour to me, because what
I
> expected was simply the incorrect file "dissapearing" as usually, and an
> error being loged in the application log containing something like
"invalid
> content" or something like that.
> Regards
>



Relevant Pages

  • Re: Possible bug in .Net 2.0 udp sockets?
    ... which one is actually incorrect? ... the data in the datagram corrupted, resulting in the wrong ID in the ... Or is EndReceiveFrom returning the wrong port? ... The incoming data was correct -- the port numbers were wrong. ...
    (microsoft.public.dotnet.framework)
  • Re: Problem installing port
    ... The port is broken because the pkg-plist is incorrect. ... the port will remain marked broken. ... Paul Schmehl ... overriding an "already registered" package. ...
    (freebsd-questions)
  • Re: Portsnap support on CURRENT
    ... These messages are incorrect ... the "port has" version identified by portversion is older than ... setenv INDEXFILE INDEX-6 ...
    (freebsd-current)
  • Re: Portsnap support on CURRENT
    ... portversion (from the portupgrade port) to list which of my packages are ... These messages are incorrect (i.e., ...
    (freebsd-current)
  • RE: Error on DC:The Target Principal Name is incorrect
    ... Sometimes the APPLIES TO section reports wrong SP level. ... check your event log and you have the matching event, ... Error Message "Target Principal Name is Incorrect" When Manually Replicating ... > All remote office DC's report same 'target principal name is incorrect' on ...
    (microsoft.public.win2000.active_directory)