Ayende @ Rahien

Refunds available at head office

Rhino Service Bus: Managing Timeouts

I was first introduced to the notion of time as an explicit concept in Udi’s writing. The notion of being able to send a message in the future was, like most of the things that Udi talks about, simple in terms of implementation, but profound in conceptual terms.

Rhino Service Bus supports this explicitly by specifying a time in which a message will be received. The implementation for that is quite interesting, I think.

Again, we are making use of a subqueue to minimize the additional requirements that RSB has. So when we send a message to the RSB with a delay in it, we move it to the timeout subquque are record that fact internally. We have a timer going off every second that check for expiry of the messages and dispatch them when their time arrives. If the system crash at any point, all the timeouts are stored in the subqueue, and on startup, we are going to read the timeout messages and reconstruct our internal representation of them.

The API is quite simple:

   1: bus.DelaySend(bus.Endpoint, 
   2:     DateTime.Now.AddMilliseconds(250), 
   3:     msg);

We might need to make some changes to support extremely large queues and extremely long duration for delayed messages, but for now, it is doing quite well.

Comments

Rafal
01/14/2009 01:25 PM by
Rafal

Ayende, can you elaborate a bit more about this feature?

  • performance. Will it degrade if large number of future messages is queued?

  • what is the timer accuracy? 1 second?

  • what about long durations - days ... months? Is it a problem?

  • could this feature be used to implement a retry strategy for failed messages (failing messages will be rescheduled for later retry)?

Rafal

Ayende Rahien
01/14/2009 02:21 PM by
Ayende Rahien

We currently keep about 64 bytes in memory for each future message. This means that for a million future messages, we are going to consume about 60 MB.

That is what I referred to as potential limitation. Although I don't really consider that as a true limitation because I don't really expect to have that many future messages on a single endpoint.

Timer accuracy is one second, yes. If you can think of anything that would make require lower granularity, I would like to hear about it.

Duration of days / months should not be a problem, although I admit that I don't have an integration test that waits for 3 days :-)

Yes, it could be implemented as retry strategy, although RSB already contains a retry strategy for messages by rolling back the transaction and retrying immediately.

Neil Barnwell
01/18/2009 04:45 PM by
Neil Barnwell

Sounds good. What made you chose a 1-second polling timer over the concept of calculating the delay and having an event fired at that time, though?

Comments have been closed on this topic.