Dehydrated messages

[hsnakkaya]

Hi,

I had 4 messages in dehydrated state yesterday. When I restarted the
host instance, 2 got processed. 2 were still in dehydrated state. I
restarted the host instances again but restarting the host instances
didn't work for other 2 messages. We still had 2 messages in
dehydrated state yesterday. These messages got processed on its own
today early morning (at 00:00:01).

There was no error or warning at the time messages were stucked.

I wonder why instances remain in dehydrated status , why some
dehydrated messages were not pocessed after restarting host instances
and why they were processed at the beggining of new day? It is very
important for us processing messages to be on time.

Thanks,
Huseyin

[Yossi Dahan [MVP]]

Hi Huseyin

To try and help you we will have to understand better why the messages got
dehydrated in the first place (and what eventually caused them to be
processed), can you provide some more information about your scenario?

--
Yossi Dahan
MVP BizTalk Server
http://www.sabratech.co.uk/blogs/yossidahan

[hsnakkaya]

Everyday more than 3000 messages are processed in our BizTalk
solution. Yesterday 4 of them remained in dehydrated status. There was
no error or warning in application logs so we could not find out the
problem that cause this issue. After restarting host instances 2 of
them were processed by biztalk but other 2 messages still remained as
dehydrated. Restarting host instance again did not work for these 2
messages. Today morning we realized that these two messages were
processed by biztalk without any manual action at the begining of
today at 00:00:01 o'clock.

[Yossi Dahan [MVP]]

I can't think of a reason why restarting the host instances would help to
process dehydrated messages (not more than restarting windows would help
getting some software to work ;-) ).

Do you know why your messages are dehydrated in the first place? I'm
assuming you have a business process involved - do you know at which
point(s) in the service the messages get dehydrated?

Could it be that your server is throttling outbound messages? have you
checked this using the relevant performance counters?

--
Yossi Dahan
MVP BizTalk Server
http://www.sabratech.co.uk/blogs/yossidahan

[hsnakkaya]

Messages were dehydrated in an orchestration which sends messages to a
MQSeries queue. In this Orchestration messages are sent an external
application and get a response. We use two request-response port here.
By first req-res port we send messages to MQSeries and we get a
correlation id. By second req-respond port we send the correlation id
and get response message.

[Yossi Dahan [MVP]]

Assuming this happens frequently enough - could you monitor the state of the
system when the messages are dehydrtaed? is there anything in the event log?
are the send ports started? do you have any active throttling? whats the
state of the queues?

--
Yossi Dahan
MVP BizTalk Server
http://www.sabratech.co.uk/blogs/yossidahan

[Truj]

I have the similar issue. I don't know WHY BizTalk instances are stuck that way???

I had 35 suspended messages and all resumed successfully using WMI script. 33 instances were processed immediately without problem, however, 2 of them are still in Dehydrated state. I don't know which action is required in BizTalk to re-process those messages?

Truj

[Kenan Kilictepe]

You can suspend and then resume those instances.

<Truj> wrote in message news:20081017159...@gmail.com...

[IvanJo]

In article <20081017159...@gmail.com>, Truj says...>

> I have the similar issue. I don't know WHY BizTalk instances are stuck that way???
>
> I had 35 suspended messages and all resumed successfully using WMI script. 33 instances were processed immediately without problem, however, 2 of them are still in Dehydrated state. I don't know which action is required in BizTalk to re-process those messages?
>
>
> Truj

Hi Truj,

when instances are dehydrated that means that they're waiting on their
turn. this usually happens when you try to send message but who should
be receiving is not available. In such case there's a retry policy
(default is retry for 3 times every 5 minutes) so while retrying it's in
dehydrated state.. So it can be normal..

--
Ivan Jocic

blog: http://biztalkia.com/blogs/IvanJo

[tomsoderling]

I also ran into this issue today.
When I double-clicked the message in the Administration Console (to see the Service Details) it didn't give me an error message of any kind.
Once I right-clicked the message and went to Message Flow however, it then gave me detailed error info.
In my case it was a folder permission issue.
BizTalk attempts to resend the message every 5 minutes - I waited a couple and the message was dropped in the folder as expected and the message no longer appeared as Dehydrated.

hsnakkaya wrote:

Dehydrated messages
17-Oct-07

Hi,

Thanks,
Huseyin

Previous Posts In This Thread:

On Wednesday, October 17, 2007 3:28 AM
hsnakkaya wrote:

Dehydrated messages
Hi,

Thanks,
Huseyin

On Wednesday, October 17, 2007 3:56 AM
yossi.dahanREMOV wrote:

Hi HuseyinTo try and help you we will have to understand better why the
Hi Huseyin

To try and help you we will have to understand better why the messages got
dehydrated in the first place (and what eventually caused them to be
processed), can you provide some more information about your scenario?

--

Yossi Dahan
MVP BizTalk Server
http://www.sabratech.co.uk/blogs/yossidahan

"hsnakkaya" wrote:

On Wednesday, October 17, 2007 4:43 AM
hsnakkaya wrote:

Everyday more than 3000 messages are processed in our BizTalksolution.
Everyday more than 3000 messages are processed in our BizTalk
solution. Yesterday 4 of them remained in dehydrated status. There was
no error or warning in application logs so we could not find out the
problem that cause this issue. After restarting host instances 2 of
them were processed by biztalk but other 2 messages still remained as
dehydrated. Restarting host instance again did not work for these 2
messages. Today morning we realized that these two messages were
processed by biztalk without any manual action at the begining of
today at 00:00:01 o'clock.

On Wednesday, October 17, 2007 5:10 AM
yossi.dahanREMOV wrote:

I can't think of a reason why restarting the host instances would help to
I can't think of a reason why restarting the host instances would help to
process dehydrated messages (not more than restarting windows would help
getting some software to work ;-) ).

Do you know why your messages are dehydrated in the first place? I'm
assuming you have a business process involved - do you know at which
point(s) in the service the messages get dehydrated?

Could it be that your server is throttling outbound messages? have you
checked this using the relevant performance counters?

--

Yossi Dahan
MVP BizTalk Server
http://www.sabratech.co.uk/blogs/yossidahan

"hsnakkaya" wrote:

On Wednesday, October 17, 2007 8:25 AM
hsnakkaya wrote:

Messages were dehydrated in an orchestration which sends messages to aMQSeries
Messages were dehydrated in an orchestration which sends messages to a
MQSeries queue. In this Orchestration messages are sent an external
application and get a response. We use two request-response port here.
By first req-res port we send messages to MQSeries and we get a
correlation id. By second req-respond port we send the correlation id
and get response message.

On Wednesday, October 17, 2007 3:25 PM
yossi.dahanREMOV wrote:

Assuming this happens frequently enough - could you monitor the state of the
Assuming this happens frequently enough - could you monitor the state of the
system when the messages are dehydrtaed? is there anything in the event log?
are the send ports started? do you have any active throttling? whats the
state of the queues?

--
Yossi Dahan
MVP BizTalk Server
http://www.sabratech.co.uk/blogs/yossidahan

"hsnakkaya" wrote:

On Friday, October 17, 2008 3:09 PM
Truj wrote:

Dehydrated messages

I have the similar issue. I don't know WHY BizTalk instances are stuck that way???

I had 35 suspended messages and all resumed successfully using WMI script. 33 instances were processed immediately without problem, however, 2 of them are still in Dehydrated state. I don't know which action is required in BizTalk to re-process those messages?

Truj

Submitted via EggHeadCafe - Software Developer Portal of Choice
BizTalk: Writing and using a custom referenced functoid.
http://www.eggheadcafe.com/tutorials/aspnet/f843db77-a775-415e-bd08-71c2b1127e40/biztalk-writing-and-usin.aspx

[prashantgaikwad]

I observed similar scenario, we had 350 dehydrated messages and after restarting host instances all went thru.strangley no errors were found in event log,no throttling obeserved on hosts.
The dehydration point for all orchs was response received from WCF service.

Tom Soderling wrote:

Dehydrated messages
05-Apr-10

I also ran into this issue today.
When I double-clicked the message in the Administration Console (to see the Service Details) it didn't give me an error message of any kind.
Once I right-clicked the message and went to Message Flow however, it then gave me detailed error info.
In my case it was a folder permission issue.
BizTalk attempts to resend the message every 5 minutes - I waited a couple and the message was dropped in the folder as expected and the message no longer appeared as Dehydrated.

Previous Posts In This Thread:

Dehydrated messages
Hi,

Thanks,
Huseyin

"hsnakkaya" wrote:

"hsnakkaya" wrote:

"hsnakkaya" wrote:

Truj

On Monday, April 05, 2010 4:50 PM
Tom Soderling wrote:

Dehydrated messages

I also ran into this issue today.
When I double-clicked the message in the Administration Console (to see the Service Details) it didn't give me an error message of any kind.
Once I right-clicked the message and went to Message Flow however, it then gave me detailed error info.
In my case it was a folder permission issue.
BizTalk attempts to resend the message every 5 minutes - I waited a couple and the message was dropped in the folder as expected and the message no longer appeared as Dehydrated.

Submitted via EggHeadCafe - Software Developer Portal of Choice

Task Parallelism in C# 4.0 with System.Threading.Tasks
http://www.eggheadcafe.com/tutorials/aspnet/21013a52-fe11-4af8-bf8b-50cfd1a51577/task-parallelism-in-c-4.aspx

[Jawahar Kandasamy]

Did you solve this issue? I have the same issue. Once my running instances count go up (20% of the normal volume), the message processing rate goes down drastically. Once i restart the Host Instance, the rest (80+ %) get processed smoothly. I could not figure out what is causing this. Any help will be much appreciated.
I am using BizTalk2006.

Thanks in advance.

>>>> process dehydrated messages (not more than restarting windows would help
>>>> getting some software to work ;-) ).
>>>>
>>>> Do you know why your messages are dehydrated in the first place? I'm
>>>> assuming you have a business process involved - do you know at which
>>>> point(s) in the service the messages get dehydrated?
>>>>
>>>> Could it be that your server is throttling outbound messages? have you
>>>> checked this using the relevant performance counters?
>>>>
>>>> --
>>>> Yossi Dahan
>>>> MVP BizTalk Server
>>>> http://www.sabratech.co.uk/blogs/yossidahan
>>>>
>>>>
>>>> "hsnakkaya" wrote:

>>>>> On Wednesday, October 17, 2007 8:25 AM hsnakkaya wrote:

>>>>> Messages were dehydrated in an orchestration which sends messages to a
>>>>> MQSeries queue. In this Orchestration messages are sent an external
>>>>> application and get a response. We use two request-response port here.
>>>>> By first req-res port we send messages to MQSeries and we get a
>>>>> correlation id. By second req-respond port we send the correlation id
>>>>> and get response message.

>>>>>> On Wednesday, October 17, 2007 3:25 PM yossi.dahanREMOV wrote:

>>>>>> Assuming this happens frequently enough - could you monitor the state of the

>>>>>> system when the messages are dehydrtaed? is there anything in the event log?
>>>>>> are the send ports started? do you have any active throttling? whats the
>>>>>> state of the queues?
>>>>>>
>>>>>> --
>>>>>> Yossi Dahan
>>>>>> MVP BizTalk Server
>>>>>> http://www.sabratech.co.uk/blogs/yossidahan
>>>>>>
>>>>>>
>>>>>> "hsnakkaya" wrote:

>>>>>>> On Friday, October 17, 2008 3:09 PM Truj wrote:

>>>>>>> I have the similar issue. I don't know WHY BizTalk instances are stuck that way???
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> I had 35 suspended messages and all resumed successfully using WMI script. 33 instances were processed immediately without problem, however, 2 of them are still in Dehydrated state. I don't know which action is required in BizTalk to re-process those messages?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Truj

>>>>>>>> On Monday, April 05, 2010 4:50 PM Tom Soderling wrote:

>>>>>>>> I also ran into this issue today.
>>>>>>>>
>>>>>>>> When I double-clicked the message in the Administration Console (to see the Service Details) it didn't give me an error message of any kind.
>>>>>>>>
>>>>>>>> Once I right-clicked the message and went to Message Flow however, it then gave me detailed error info.
>>>>>>>>
>>>>>>>> In my case it was a folder permission issue.
>>>>>>>>
>>>>>>>> BizTalk attempts to resend the message every 5 minutes - I waited a couple and the message was dropped in the folder as expected and the message no longer appeared as Dehydrated.

>>>>>>>>> On Tuesday, June 08, 2010 12:40 PM Prashant Gaikwad wrote:

>>>>>>>>> I observed similar scenario, we had 350 dehydrated messages and after restarting host instances all went thru.strangley no errors were found in event log,no throttling obeserved on hosts.
>>>>>>>>>
>>>>>>>>> The dehydration point for all orchs was response received from WCF service.

>>>>>>>>> Submitted via EggHeadCafe - Software Developer Portal of Choice

>>>>>>>>> A Comparison of Managed Compression Algorithms
>>>>>>>>> http://www.eggheadcafe.com/tutorials/aspnet/71485ecc-2d2d-435a-9c35-3d12b279f9ae/a-comparison-of-managed-compression-algorithms.aspx