﻿<?xml version="1.0" encoding="utf-8"?><rss version="2.0"><channel><title>Ayende @ Rahien</title><link>http://ayende.com</link><description>Ayende @ Rahien</description><copyright>Copyright (C) Ayende Rahien  2004 - 2021 (c) 2026</copyright><ttl>60</ttl><item><title>Ayende Rahien commented on Rhino Service Bus: Managing Timeouts</title><description>Complexity vs. simplicity
</description><link>http://ayende.com/3802/rhino-service-bus-managing-timeouts#comment4</link><guid>http://ayende.com/3802/rhino-service-bus-managing-timeouts#comment4</guid><pubDate>Sun, 18 Jan 2009 17:58:09 GMT</pubDate></item><item><title>Neil Barnwell commented on Rhino Service Bus: Managing Timeouts</title><description>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?
</description><link>http://ayende.com/3802/rhino-service-bus-managing-timeouts#comment3</link><guid>http://ayende.com/3802/rhino-service-bus-managing-timeouts#comment3</guid><pubDate>Sun, 18 Jan 2009 16:45:53 GMT</pubDate></item><item><title>Ayende Rahien commented on Rhino Service Bus: Managing Timeouts</title><description>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.
</description><link>http://ayende.com/3802/rhino-service-bus-managing-timeouts#comment2</link><guid>http://ayende.com/3802/rhino-service-bus-managing-timeouts#comment2</guid><pubDate>Wed, 14 Jan 2009 14:21:54 GMT</pubDate></item><item><title>Rafal commented on Rhino Service Bus: Managing Timeouts</title><description>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
</description><link>http://ayende.com/3802/rhino-service-bus-managing-timeouts#comment1</link><guid>http://ayende.com/3802/rhino-service-bus-managing-timeouts#comment1</guid><pubDate>Wed, 14 Jan 2009 13:25:23 GMT</pubDate></item></channel></rss>