BizTalk Server Orchestration - Synchronization exception using Listen shape

Author

Synchronization exception using Listen shape

Hobietje

2005-06-07, 8:47 pm

I am trying to make a simple orchestration that reads files from 2 file
locations and copies all these files to a third location.

To do this, I created two receive ports for the appropriate locations, put
two activatable receive shapes inside a listen shape, and a send shape and
port underneath the listen shape.

When I run this I get "Object synchronization method was called from an
unsynchronized block of code" in the event log and BizTalk shuts itself down.
Does anyone know how to get around this? Why am I getting this exception?

I tried running the same orchestration with only one receive shape without
the Listen shape, and that works perfectly ...

Marvin Smit

2005-06-08, 7:47 am

Hi,

I've run into this same issue a while back. Although I didn't figure
it out to the depths i would have lioked too.... My solution was to
'remove the 2.0 Beta" stuff of the .Net Framework i had flying around.

You should also be able to "redirect" the assembly binding and force
it to use the 1.1 runtime. (BTSNTSCV.exe.config)

Hope this helps,

Marvin Smit

On Tue, 7 Jun 2005 16:26:02 -0700, "Hobietje"
<Hobietje@discussions.microsoft.com> wrote:

>I am trying to make a simple orchestration that reads files from 2 file
>locations and copies all these files to a third location.
>
>To do this, I created two receive ports for the appropriate locations, put
>two activatable receive shapes inside a listen shape, and a send shape and
>port underneath the listen shape.
>
>When I run this I get "Object synchronization method was called from an
>unsynchronized block of code" in the event log and BizTalk shuts itself down.
> Does anyone know how to get around this? Why am I getting this exception?
>
>I tried running the same orchestration with only one receive shape without
>the Listen shape, and that works perfectly ...

Hobietje

2005-06-08, 8:47 pm

Hi Marvin

I don't think we'd want to uninstall Framework 2.0. I'll have to run that
past the system admins.

I would be interested in trying the mapping BizTalk to Framework 1.1 though.
I had a look at the btsntsc.exe.config file but can't really see anything to
change which version of the Framework BTS uses. Google didn't help me too
much either. Would you mind posting your config file (or the relevant
sections) for me?

Thanks

"Marvin Smit" wrote:

> Hi,
>
> I've run into this same issue a while back. Although I didn't figure
> it out to the depths i would have lioked too.... My solution was to
> 'remove the 2.0 Beta" stuff of the .Net Framework i had flying around.
>
> You should also be able to "redirect" the assembly binding and force
> it to use the 1.1 runtime. (BTSNTSCV.exe.config)
>
> Hope this helps,
>
> Marvin Smit
>
>
> On Tue, 7 Jun 2005 16:26:02 -0700, "Hobietje"
> <Hobietje@discussions.microsoft.com> wrote:
>
>
>

Tomas Restrepo \(MVP\)

2005-06-09, 2:47 am

> I don't think we'd want to uninstall Framework 2.0. I'll have to run that
> past the system admins.
>
> I would be interested in trying the mapping BizTalk to Framework 1.1
> though.
> I had a look at the btsntsc.exe.config file but can't really see anything
> to
> change which version of the Framework BTS uses. Google didn't help me too
> much either. Would you mind posting your config file (or the relevant
> sections) for me?

Try:

<configuration>
<startup>
<supportedRuntime version="v1.1.4322" />
</startup>
....
</configuration>

Notice that you'll need to add this to .config files for *each* .exe from
the biztalk directory.

--
Tomas Restrepo
tomasr@mvps.org
http://www.winterdom.com/

Hobietje

2005-06-09, 2:47 am

Hi Thomas

I added the suggested configuration setting and tried starting the BizTalk
service: no problem. As soon as I get a message into one of my receive
locations though, I get the message below. (I get this message on EVERY
orchestration I have. Not just the Listen-orchestration I am trying to fix
with this newsgroup thread). Google doesnt seem to have any answers other
then a few related to running multiple assembly versions simultaneously,
which we're not doing, so ... got any ideas?

Similar error messages I found on google return an assembly or orchestration
in the "Failed while creating a MYASSEMBLY service." text, but mine doesnt???
Why???

Thanks

Event Type: Error
Event Source: XLANG/s
Event Category: None
Event ID: 10001
Date: 9/06/2005
Time: 2:38:10 PM
User: N/A
Computer: SYDAPPSDEV
Description:
Failed while creating a service.

Exception type: ServiceCreationException
Source:
Target Site:
Help Link:
Additional error information:

Exception of type MalformedEnlistmentException was thrown.

Exception type: MalformedEnlistmentException
Source: Microsoft.XLANGs.BizTalk.Engine
Target Site: Microsoft.BizTalk.XLANGs.BTXEngine.BTXServiceStaticState
_deserializeStaticState(System.Guid)
Help Link:
Additional error information:

For more information, see Help and Support Center at
http://go.microsoft.com/fwlink/events.asp.

Tomas Restrepo \(MVP\)

2005-06-09, 7:48 am

>
> I added the suggested configuration setting and tried starting the BizTalk
> service: no problem. As soon as I get a message into one of my receive
> locations though, I get the message below. (I get this message on EVERY
> orchestration I have. Not just the Listen-orchestration I am trying to
> fix
> with this newsgroup thread). Google doesnt seem to have any answers other
> then a few related to running multiple assembly versions simultaneously,
> which we're not doing, so ... got any ideas?
>
> Similar error messages I found on google return an assembly or
> orchestration
> in the "Failed while creating a MYASSEMBLY service." text, but mine
> doesnt???
> Why???

I'm guessing here, but it might be that there are existing suspended
services that are getting resumed on start? those might be "corrupted" from
the previous loading of .NET 2.0 on the bts service when they were
originally processed. I'd try using hat to terminate them and see if it
helps.

if not, make sure also that your bts libraries themselves didn't end up,
somehow, linked to the v2.0 version of the .NET framework (unlikely)

--
Tomas Restrepo
tomasr@mvps.org
http://www.winterdom.com/

Hobietje

2005-06-21, 8:48 pm

Hi Thomas

I finally had a change to have another look at this, and it turns out that
these 'suspended instances' probably have been bothering me from the start.

I created my orchestration just like I did before with the listen shape with
multiple receives. I made sure to terminate all suspended instances using
HAT before I deployed. When I started my orchestrations, I made sure to say
NO to the 'resume suspended instances' question. I also restarted the BTS
Service after every single deployment. And it is working just fine now ... I
used to say Yes to the 'resume suspended instances' most of the time before.
I wasn't that strict on restarting the BTS service all the time either ...

Thanks for your help and time on this!

Cheers

Andy

"Tomas Restrepo (MVP)" wrote:

>
> I'm guessing here, but it might be that there are existing suspended
> services that are getting resumed on start? those might be "corrupted" from
> the previous loading of .NET 2.0 on the bts service when they were
> originally processed. I'd try using hat to terminate them and see if it
> helps.
>
> if not, make sure also that your bts libraries themselves didn't end up,
> somehow, linked to the v2.0 version of the .NET framework (unlikely)
>
>
> --
> Tomas Restrepo
> tomasr@mvps.org
> http://www.winterdom.com/
>
>
>

Tomas Restrepo \(MVP\)

2005-06-22, 2:48 am

> I finally had a change to have another look at this, and it turns out that
> these 'suspended instances' probably have been bothering me from the
> start.
>
> I created my orchestration just like I did before with the listen shape
> with
> multiple receives. I made sure to terminate all suspended instances using
> HAT before I deployed. When I started my orchestrations, I made sure to
> say
> NO to the 'resume suspended instances' question. I also restarted the BTS
> Service after every single deployment. And it is working just fine now
> ... I
> used to say Yes to the 'resume suspended instances' most of the time
> before.
> I wasn't that strict on restarting the BTS service all the time either ...

Cool, nice to know you were able to fix it!

--
Tomas Restrepo
tomasr@mvps.org
http://www.winterdom.com/