Rafal,You can store deferred messages elsewhere, you need to change TimeoutAction, that is all.
One of the points about RSB is that it is opinionated and ready to go. I am much more concerned with hitting the ground running with a new project than adapting to an existing one. The extension points are there, but you have to use them On Thu, Jun 4, 2009 at 10:05 AM, rg <[email protected]> wrote: > > Thanks, I understand these reasons. However, masstransit guys have > done it, they store deferred messages in sql database :) > BTW, my RSB-related posts can seem strange because each time I'm > asking about a feature that either isn't implemented in the framework > or is implemented but I want it to do something it can't... It's not > nitpicking, I'm just trying to replace existing functions with RSB > and RSB doesn't want to do what the old code did. Hope you find my > suggestions at least partially useful. > > Best regards > Rafal > > > > On Jun 4, 2:23 pm, Ayende Rahien <[email protected]> wrote: > > In general, the approach we take is that we don't want to mix & match.If > we > > use MSMQ, we just use that. > > If we use RQ, we just use that. > > We don't want someone to be confused about what they are doing. > > > > On Wed, May 13, 2009 at 11:13 AM, rg <[email protected]> wrote: > > > > > Corey, I also think Rhino Queues could be used for storing 'future' > > > messages, both for 'DelaySend' feature and for the retrying mechanism > > > I described above. It would be necessary to add 'deliveryDate' column > > > to RQ table in Esent db and index that column so the system could > > > quickly find messages by their delivery date. As RQ is a part of RSB > > > it could be the default mechanism for storing scheduled messages, no > > > matter if you use MSMQ transport or not. > > > Does it make sense? I'd like also to get your (and other RSB users) > > > opinion about my requirements - I think these are quite common > > > situations and having these features would make our systems more > > > maintenance-free. > > > > > best regards > > > R > > > > > On May 13, 4:45 pm, Corey Kaylor <[email protected]> wrote: > > > > does RSB process other messages while dealing with a failed one, or > > > > is the queue blocked until the failing message is removed > > > > > > Depends on the number of threads that are processing messages, but > yes it > > > > would be blocked currently if all threads are dealing with failing > > > messages. > > > > > > how long does RSB try to handle the message? Minutes? Hours? Days? > > > > > > Until the failure count equals the number of retries, if failed the > > > message > > > > will be moved to the error sub-queue > > > > > > is there a tool to quickly move failed messages from errors subqueue > > > > back to input queue? > > > > > > No, not currently. > > > > > > I believe your needs are partially handled if using the rhino queues. > > > > Failing to send a message to an endpoint will perform a time > incrementing > > > > retry as you described, but unfortunately once it is received and the > > > > consumer fails on its end your needs won't be handled with the > current > > > state > > > > of things. > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
