Ayende @ Rahien

Hi!
My name is Ayende Rahien
Founder of Hibernating Rhinos LTD and RavenDB.
You can reach me by phone or email:

ayende@ayende.com

+972 52-548-6969

, @ Q c

Posts: 5,949 | Comments: 44,548

filter by tags archive

Rhino Service BusManaging 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.

More posts in "Rhino Service Bus" series:

  1. (08 Aug 2009) DHT Saga Sate Persisters Options
  2. (21 Jan 2009) Concurrency Violations are Business Logic
  3. (19 Jan 2009) Concurrency in a distributed world
  4. (16 Jan 2009) Saga and State
  5. (15 Jan 2009) Field Level Security
  6. (14 Jan 2009) Understanding a Distributed System
  7. (14 Jan 2009) The Starbucks example
  8. (14 Jan 2009) Locality and Independence
  9. (14 Jan 2009) Managing Timeouts

Comments

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

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

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?

Comment preview

Comments have been closed on this topic.

FUTURE POSTS

No future posts left, oh my!

RECENT SERIES

  1. The RavenDB Comic Strip (3):
    28 May 2015 - Part III – High availability & sleeping soundly
  2. Special Offer (2):
    27 May 2015 - 29% discount for all our products
  3. RavenDB Sharding (3):
    22 May 2015 - Adding a new shard to an existing cluster, splitting the shard
  4. Challenge (45):
    28 Apr 2015 - What is the meaning of this change?
  5. Interview question (2):
    30 Mar 2015 - fix the index
View all series

RECENT COMMENTS

Syndication

Main feed Feed Stats
Comments feed   Comments Feed Stats