Orchestrations stuck in active state

Question

Hi,

I'm in the process of mocking up an upgrade from BTS 2004 to 2006 R2.  I've just setup a new box with BTS 2004 SP2 and will perform testing on that before upgrdaing to 2006, to simulate exactly what we'll do with our production boxes.

However, the trouble now is all orchestrations are stuck in 'Active' state.  I've been looking for hours around the net about this but couldn't find anything helpful. I've just executed 1 simple orchestration and this happens.  There are no errors, no logs.  When I try to debug or get the message flow, there's no message tracking or orchestration path traces.

Answer 1

If possible, You can restrat the BizTalk host instance. It might solve your problem.

Regards,
Abhijit

---

Abhijit Mahato Please "Mark as Answer" if Post has Answered the Question

Answer 2

Hi,

Please use HAT to check at what point the orchestration is stuck.  What is the scope of the orchestration?

Regards,

Tariq Majeed

---

Please mark it as answer if it helps

Answer 3

Hi,

Are you calling in .net component inside your orchestration. I faced the same issue where .net component was not serialized and it went into the similar state. Some more details could help.

Regards
Vishnu 

---

Vishnu

Answer 4

Terminate the Orchestraion instance then shoot a dubug by HAT if u r using 2004.

---

Kerrey [Integration Consultant]

Answer 5

Just as a legend:
Box1 = Original test box
Box2 = the box i'm working on

I reinstalled BizTalk Server 2004 in the box (call it box2) after doing a cleanup on both databases and the previous installation.

The orchestrations were working however I was having issues with the MSMQ receive ports because they just wouldn't pick up anything from the remote queue.  No errors though.  The original test box (lets call it box1) does fine.  So I restarted the remote queue and box2 finally fetched from the queue... then the active state orch instance syndrome started popping up again.  All orchestrations get stuck at Active again.

I've restarted everything.  Debugging doesn't help because it just shows nothing on the tracked events.  Box1 has the same artifacts deployed but doesn't have these problems.

Another oddity by the way is that once I terminate any orchestration, it doesn't really get terminated but has its status updated to 'Completed, with discarded messages'.  By this point, debugging nor getting the message flow doesn't show anything either.  I'd have to terminate again to finally end the persistent little life of the instance.

Wasn't able to mention, I'm on Windows 2003 (not R2) which seems to be running on ESX VMware.  I believe the infrastructure team used the same image for both box1 and box2.

I'm back to scratching my head.

Answer 6

1. doeas the MSMQ receive ports talk to queue on another box?
2. are these queses transactional.

if the queue is transactional then issue is with MSMQ and not orchestrations as it is not comitting the message to biztalk you dont find any tracked messages.

---

KiranMP

Answer 7

1) Message Queue is on another box (box3).  Box1 doesn't have problems communicating with MQ but box2 did... until I restarted MQ service in box3. 

2) queues are non-transactional.

The active state syndrome happens regardless how the message goes into box2 (MSMQ, FILE).  receiving via File adapter worked until I restarted MQ in box3.  Now all instances are just stuck in active.  No high CPU usage, lots of free memory still.  I'm testing with just 1 odx at a time.

it gets weird, no?  I'll most probably ask to have the box rebuilt if this goes on, however that isn't a sound solution since this can happen again.

Answer 8

one thing tou can do is to use a receive port with pass through and send to a file location and try to check if biztalk is getting proper message format. example utf-16

---

KiranMP

Answer 9

it's encoded as UTF-8.

Hey, thanks for the responses guys.  Just wanted to say that.

Answer 10

Further adding to the oddities, (box2) suddenly is working.  It is now able to accept messages from both FILE and MSMQ (Remote queue) adapters.  This just happened after a nights rest.  Nobody else is able to log into the box so there's noone to do some magic.

Answer 11

Hi,

Completed with Discarded Messages" is one of the states an orchestration instance may end with. A message that is discarded in this way is called a "zombie" and typically occurs when an extra message is routed after control flow in the executing orchestration has passed the Receive shape with the matching subscription. This can be due to a time-out on a long-running transaction or a time-out of a Delay branch on a Listen shape. It can also occur in a loop that contains a Receive shape that exits before consuming all routed messages.

An orchestration continuing in ACtive state like this means it must have some Atomic scope inside and while it is trying to persist itself at the beginning of the Atomic Scope it is failing to do so because of various reasons like resource contention in SQL server, deadlocks in SQL server, other unknown problems etc and then it continues in Active state.

Normally when this happens you need to check the activities at the SQL Server end. But this is a rare occurrence though.

This is my take on the subject. I welcome suggestions from MVPs to get the best possible answer.

---

Please mark as answer if this helps you. Thanks and warm regards Ambar Ray EAI Architect - Microsoft Technologies