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 -~----------~----~----~----~------~----~------~--~---
