Conversation Timers, Alive or Dead?

What is actually happening when a conversation timer is being used in terms of the dialog_timer column in sys.conversationendpoints? For example, I was using the following query to tell me which conversation timers are currently running:

SELECT * FROM sys.conversation_endpoints

WHERE dialog_timer > '1900-01-01 00:00:00.000'

However, I have noticed that periodically the dialog_timer value goes back to '1900-01-01 00:00:00.000' and the query fails, starting up another timer. Then, the original timer magically appears again, working just fine. So, I changed to this query:

SELECT * FROM sys.conversation_endpoints

WHERE far_service

IN

(

'TimerService1',

'TimerService2',

'TimerService3',

)

But this seems like the long way around and doesn't really indicate that the timer is running or not, just that its present in the sys.conversationendpoints catalog view. What is the proper way to see if timers are running? If one dies for some reason, I need to restart it.

What is going on with this? The timers keep getting set back to

'1900-01-01 00:00:00.000' and the jobs don't get executed. What does this mean? How to correct it - its seems that the conversation_handle is still there and fine, but the timer isn't working.

|||

The dialog_timer is set whenever the BEGIN CONVERSATION TIMER is executed. It's value is the time (UTC) at which the timer should 'fire' (send the Timer message). The dialog_timer is reset back to '1900-01-01 00:00:00.000' whenever the timer message is enqueued into the service queue. If you see the dialog_timer value reset, it means the timer has fired and a timer message is waiting in the service queue.

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 Timer problem : Timeout not effective

Hi,

I am using conversation Timer for delaying a message for a few seconds but I can see the message immediately in the queue.

Here is the code i am using. This is a part of a stored procedure I have used.

BEGIN CONVERSATION TIMER ( @.h ) TIMEOUT = @.DelayBySeconds;

SEND ON CONVERSATION @.h

MESSAGE TYPE [sendmsg]

(@.msg);

I am executing this stored procedure with following statements.

exec set_ssb_msg 'test3', 25;

exec set_ssb_msg 'test1', 1;

select * from q1

I was hoping to see just the 'Test1' and see test3 after 25 seconds. But I could see both the messages in a queue as soon as i run the stored proc.

If I execute a receive command on the queue, I am receiving 'test3' first and then 'test1'. This is exactly opposit of what i expected.

Can you please let me know if I am doing anything wrong or missing a step.

Any help is greatly appreciated.

Thanks,

Don.

Conversation timers have no relation whatsoever to sent messages, they affect the local endpoints only. You should expect a DialogTimer message in your sender's queue to show up after 25 and/or 1 seconds. The messages sent are unaffacted by timers. Also, although is not clear in your example, it seems that you're begining a new conversation for each message sent. The message order is only guaranteed within a conversation, and as such your expectations of a certain order on the target queue are not justified.