Conversation Timer versus LIFETIME

I need to follow up on a message and check on its status. I am planning on using Conversation Timers (self addressed). I've tried it and they do work well. I am wondering if the LIFETIME parameter can be used for the same purpose. If the dialog has not been closed and the LIFETIME expires, will a message be queued into the service's queue? It does not seem that this is the case, but it is worth checking, as it could be a much desired feature.

Thanks,

Eugen F wrote:

If the dialog has not been closed and the LIFETIME expires, will a message be queued into the service's queue?

If the dialog reaches its lifetime before is closed then it will be automatically errored. An errror message will be enqueued into both initiator and target service's queues. Once the dialog has errored, no further messages can be sent on the dialog.

HTH,
~ Remus

|||

Thanks,

is there documentation that describes all the queue columns and how to interpret them?

|||The online documentation seem to be OK, but not quite comprehensive.|||

If there are specific sections of the documentation that need more explanation, please submit feedback to our support website:

http://connect.microsoft.com/site/sitehome.aspx?SiteID=68

Thanks,

Rushi

Conversation lifetime after close

Given that the conversation states are as follows: (Thanks Rushi!)

Event Initiator Endpoint state Target Endpoint state

---

BEGIN DIALOG SO --
from Initiator
to Target

SEND message(s) CO --
from Initiator
to Target

Target receives a fragment CO SI
of the first message sent
or receives out of order
message

Target received entire CO CO
first message

END conversation at CO DO
target

Initiator receives EndDialog DI DO
message from target

Target receives ACK for the DI CD
EndDialog message sent

END conversation at CD CD
Initiator

When does the 30 minute timer start for clearing the conversation from the sys.conversation_handles table? Is it the same for both sides (initiator and Target) ie, the end conversation at the Initiator. I guess it must be just in case a resend is necessary.

Gary

Looks like the fire-and-forget problem. Please look at this thread:

http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=758562&SiteID=1

|||

Thanks for the article Rushi,and special thanks for Roger's help. I found out that I did not have a route defined back to the initiator. Things are much better today.

Thanks a heap for the help!

Gary

Conversation LIFETIME

I have a conversation that I want to know has not ended so I am using LIFETIME.

When the conversation times out I then have three records in the queue.

1. The original conversation record that has not been received.

2. Error message to the initiator.

3. Error message to the target.

Both message bodies on the error records say that it was a lifetime error.

If I end the conversation on the initiator side after it is sent, I still get the target error record but the message_body field is null.

So say I don't end the conversation on the initator side. My next receive on the target side will pull the original record. Then it will pull the initator record and then it will pull the target record. Nothing on that record says that it had timed out.

What is the best practice for handling lifetime errors?

In the case when you end the conversation from the initiator side you are no seeing an Error message, but an EndDialog message (different message_type_name, no message_body). Because the conversation is ended, it will no longer expire.

To better understand the Service Broker semantics, I recommend you experiment with two separate services on two separate queues. The Broker is a communication mechanism between services, not a primitive for implementing a queue. If you are looking to create a queue, you'll be better of with a user table and proper enqueue/dequeue stored procs.

Can you explain what is application you're trying to build using Broker? We can help you better if we understand what is your goal.

Thanks,
~ Remus

sqlsql