> Yeah, we probably need both. > The problem is deciding where to implement this.
QueueManager configuration DSL? Or even a parameter object passed into the ctor that has Endpoint, Path, MaxNumberOfMessagesToRetain, TimeToRetainMessages as properties - something along those lines? > That would still work, actually. > If your service isn't there, the message will be queued at the source until [snip] > So you still get the same (very important) quality. SOLD :) Thinking about a service bus implementation on top of this you could make really a lightweight framework - a lot of the complexity in RSB goes away. (not that there was that much to begin with in comparison to NSB / MT :) Is it really as simple as an ITransport implementation? I guess I'm geared towards small, lightweight, single purpose tools these days (Autofac, AutoMapper, etc...) - a really simple framework built directly on top of RQ seems like a winner to me. (of course using ServiceLocator for IoC so I can use Autofac ;) Just my thoughts... On Thu, Apr 2, 2009 at 9:35 AM, Ayende Rahien <[email protected]> wrote: > inline > > On Thu, Apr 2, 2009 at 12:24 PM, Matt Burton <[email protected]> wrote: >> >> > Purge isn't implemented yet :-) >> > Ideally, I want to maintain the most recent X number of messages. >> >> Or messages newer than a configured date - would be nice to have both >> options (configurable w/sensible defaults) to satisfy the needs of any >> environment. > > Yeah, we probably need both. > The problem is deciding where to implement this. > >> >> > Rhino Queues is currently setup to run as embedded, so it would run as >> > part >> > of your application process. >> >> My main concern here is something which I take for granted in an >> MSMQ-based solution - if my service isn't there the caller can still >> write to the queue and my service will get the message when it comes >> back up. I guess there really isn't anything about RQ that prohibits a >> dedicated process, you're just saying that right now it's geared >> towards in-proc? > > That would still work, actually. > If your service isn't there, the message will be queued at the source until > it comes up, with about 3 days for it to show up until we totally give up on > it. > So you still get the same (very important) quality. > Here is the schedule for failure on a message send: > > Retries > > Date > > 0 > > 4/2/2009 0:00:00 > > 1 > > 4/2/2009 0:00:01 > > 2 > > 4/2/2009 0:00:05 > > 3 > > 4/2/2009 0:00:14 > > 4 > > 4/2/2009 0:00:30 > > 5 > > 4/2/2009 0:00:55 > > 6 > > 4/2/2009 0:01:31 > > 7 > > 4/2/2009 0:02:20 > > 8 > > 4/2/2009 0:03:24 > > 9 > > 4/2/2009 0:04:45 > > 10 > > 4/2/2009 0:06:25 > > 11 > > 4/2/2009 0:08:26 > > 12 > > 4/2/2009 0:10:50 > > 13 > > 4/2/2009 0:13:39 > > 14 > > 4/2/2009 0:16:55 > > 15 > > 4/2/2009 0:20:40 > > 16 > > 4/2/2009 0:24:56 > > 17 > > 4/2/2009 0:29:45 > > 18 > > 4/2/2009 0:35:09 > > 19 > > 4/2/2009 0:41:10 > > 20 > > 4/2/2009 0:47:50 > > 21 > > 4/2/2009 0:55:11 > > 22 > > 4/2/2009 1:03:15 > > 23 > > 4/2/2009 1:12:04 > > 24 > > 4/2/2009 1:21:40 > > 25 > > 4/2/2009 1:32:05 > > 26 > > 4/2/2009 1:43:21 > > 27 > > 4/2/2009 1:55:30 > > 28 > > 4/2/2009 2:08:34 > > 29 > > 4/2/2009 2:22:35 > > 30 > > 4/2/2009 2:37:35 > > 31 > > 4/2/2009 2:53:36 > > 32 > > 4/2/2009 3:10:40 > > 33 > > 4/2/2009 3:28:49 > > 34 > > 4/2/2009 3:48:05 > > 35 > > 4/2/2009 4:08:30 > > 36 > > 4/2/2009 4:30:06 > > 37 > > 4/2/2009 4:52:55 > > 38 > > 4/2/2009 5:16:59 > > 39 > > 4/2/2009 5:42:20 > > 40 > > 4/2/2009 6:09:00 > > 41 > > 4/2/2009 6:37:01 > > 42 > > 4/2/2009 7:06:25 > > 43 > > 4/2/2009 7:37:14 > > 44 > > 4/2/2009 8:09:30 > > 45 > > 4/2/2009 8:43:15 > > 46 > > 4/2/2009 9:18:31 > > 47 > > 4/2/2009 9:55:20 > > 48 > > 4/2/2009 10:33:44 > > 49 > > 4/2/2009 11:13:45 > > 50 > > 4/2/2009 11:55:25 > > 51 > > 4/2/2009 12:38:46 > > 52 > > 4/2/2009 13:23:50 > > 53 > > 4/2/2009 14:10:39 > > 54 > > 4/2/2009 14:59:15 > > 55 > > 4/2/2009 15:49:40 > > 56 > > 4/2/2009 16:41:56 > > 57 > > 4/2/2009 17:36:05 > > 58 > > 4/2/2009 18:32:09 > > 59 > > 4/2/2009 19:30:10 > > 60 > > 4/2/2009 20:30:10 > > 61 > > 4/2/2009 21:32:11 > > 62 > > 4/2/2009 22:36:15 > > 63 > > 4/2/2009 23:42:24 > > 64 > > 4/3/2009 0:50:40 > > 65 > > 4/3/2009 2:01:05 > > 66 > > 4/3/2009 3:13:41 > > 67 > > 4/3/2009 4:28:30 > > 68 > > 4/3/2009 5:45:34 > > 69 > > 4/3/2009 7:04:55 > > 70 > > 4/3/2009 8:26:35 > > 71 > > 4/3/2009 9:50:36 > > 72 > > 4/3/2009 11:17:00 > > 73 > > 4/3/2009 12:45:49 > > 74 > > 4/3/2009 14:17:05 > > 75 > > 4/3/2009 15:50:50 > > 76 > > 4/3/2009 17:27:06 > > 77 > > 4/3/2009 19:05:55 > > 78 > > 4/3/2009 20:47:19 > > 79 > > 4/3/2009 22:31:20 > > 80 > > 4/4/2009 0:18:00 > > 81 > > 4/4/2009 2:07:21 > > 82 > > 4/4/2009 3:59:25 > > 83 > > 4/4/2009 5:54:14 > > 84 > > 4/4/2009 7:51:50 > > 85 > > 4/4/2009 9:52:15 > > 86 > > 4/4/2009 11:55:31 > > 87 > > 4/4/2009 14:01:40 > > 88 > > 4/4/2009 16:10:44 > > 89 > > 4/4/2009 18:22:45 > > 90 > > 4/4/2009 20:37:45 > > 91 > > 4/4/2009 22:55:46 > > 92 > > 4/5/2009 1:16:50 > > 93 > > 4/5/2009 3:40:59 > > 94 > > 4/5/2009 6:08:15 > > 95 > > 4/5/2009 8:38:40 > > 96 > > 4/5/2009 11:12:16 > > 97 > > 4/5/2009 13:49:05 > > 98 > > 4/5/2009 16:29:09 > > 99 > > 4/5/2009 19:12:30 > > 100 > > 4/5/2009 21:59:10 > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Rhino Tools Dev" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/rhino-tools-dev?hl=en -~----------~----~----~----~------~----~------~--~---
