I have an orchestration that uses a parallel shape to split execution into t
wo parallel threads of execution which I shall call A & B.

On each thread there is a loop and a listen shape that receives requests.

B receives only one-way messages whilst A receives request-response messages
.

One scenario is that B receives a sequence of messages and updates a shared 
resource. Then A receives a request and immediately passes back a response. 
This scenario works just fine.

The failing scenario is when A receives a request but then has to wait for a
 message from B before it can respond to its caller. For this to work I have
  a shared port type with a direct send port from B and a direct receive por
t to A. When B has the data
that A needs it sends it out to the direct port. A is waiting for this messa
ge on its direct receive port. When it gets the message from B it forms the 
response to its caller and sends this.

What happens is that A waits on the direct receive port and B never consumes
 the message that would allow it to satisfy A. That is, the message that wou
ld satisfy A is picked placed into the message box in the "Delivered, not co
nsumed" state but the B thr
ead never wakes up from its listen shape. Its as if B is blocked because A i
s waiting.

There aren't any atomic or synchronization scopes round the pertinent listen
 shapes so I'm confused!

Anybody any ideas?

David Regan

[ Post a follow-up to this message ]

Why is there a listen block in each of the threads? Is it not sufficient to
have receives in both the threads?
What does each of the listen tasks do in a A or B other than the receive
you mentioned below?
The reason why you could be seeing "Delivered, not consumed state" is that
the message was deliverd to the instance, however the instance had no
blocking receive to route this message to. You can look at the trace in the
orchestration debugger in HAT to see the last executed activities in the
parallel tasks.

--------------------[vbcol=seagreen] 
<DavidRegan@discussions.microsoft.com>[vbcol=seagreen] 
into two parallel threads of execution which I shall call A & B.[vbcol=seagreen] 
messages.[vbcol=seagreen] 
shared resource. Then A receives a request and immediately passes back a
response. This scenario works just fine.[vbcol=seagreen] 
for a message from B before it can respond to its caller. For this to work
I have  a shared port type with a direct send port from B and a direct
receive port to A. When B has the data that A needs it sends it out to the
direct port. A is waiting for this message on its direct receive port. When
it gets the message from B it forms the response to its caller and sends
this.[vbcol=seagreen] 
consumes the message that would allow it to satisfy A. That is, the message
that would satisfy A is picked placed into the message box in the
"Delivered, not consumed" state but the B thread never wakes up from its
listen shape. Its as if B is blocked because A is waiting.[vbcol=seagreen] 
listen shapes so I'm confused![vbcol=seagreen] 

This posting is provided "AS IS" with no warranties, and confers no rights.

EBusiness Server Team

[ Post a follow-up to this message ]