Alright - understood. Doing some searches turned up the TimeToBeReceivedAttribute in NSB and I dug into what that was - I'm relatively new to MSMQ so didn't know that it provides that facility, i.e. the TimeToBeReceived property of a System.Messaging.Message object. That looks like a good fit for what I'm thinking of here - would you consider having that in RSB? Or is it not there for a reason?
Also, the notion of message headers - what are your feelings on that? When working with WCF I became accustomed to passing user context in the message headers and handling that at the infrastructure level so as not to burden the developers with shuffling around that context manually. What is the story in RSB around that sort of functionality? I'll have many scenarios where the identity of the user that sent the command will be important, for instance auditing and on-behalf-of scenarios (CSR does something on behalf of the user...) What are your recommendations there? Base message type that has context properties? Thanks, Matt On Mon, Feb 23, 2009 at 6:23 PM, Ayende Rahien <[email protected]> wrote: > 2) You don't. > To be more exact, you don't have a way of aborting an operation mid way. > That has the option of destabilizing the entire system. > What you can do is write a message module that will tell you if this message > was processing took too long. > RSB supports the same timeout notions for sagas that NSB does > > On Mon, Feb 23, 2009 at 6:02 PM, Matt Burton <[email protected]> wrote: >> >> 1) Good deal - will do. >> 2) Maybe the wording is incorrect - how about, "how do I enforce >> message processing time SLAs using RSB?" The concrete example is that >> I'm turning off access rights for a user - that message / saga must be >> processed within 5 seconds. NSB has the notion of timeouts for sagas, >> but I'm wondering if there's a way to extend that concept to the >> individual message level as well, or if that is even advisable. >> >> Thanks, >> matt >> >> On Mon, Feb 23, 2009 at 1:58 PM, Ayende Rahien <[email protected]> wrote: >> > 1) take a look at the load balancer. It will distribute the subscription >> > messages to all workers. >> > 2) I don't see the association between timeouts and your scenario >> > >> > On Mon, Feb 23, 2009 at 4:05 PM, Matt Burton <[email protected]> >> > wrote: >> >> >> >> Couple of questions: >> >> >> >> 1) Subscriptions - the simplicity of storing them in the subqueue is >> >> excellent - love it. What happens, however, when I have a scenario >> >> where I'm load balancing multiple servers which are all publishers? Do >> >> I have multiple servers looking at the same queue? >> >> >> >> 2) Timeouts - I read the post on handling timeouts in terms of sending >> >> a message in the future and that time elapsing, but how does one >> >> handle a scenario such as "if this message isn't processed in 2 >> >> seconds someone needs to know about it" - I'm thinking of a situation >> >> like a user engaged in fraudulent activity needs to be shut down >> >> immediately - disable access to his accounts, etc... I recognize that >> >> there is an inherent race condition here where the user might be able >> >> to execute more operations before the disable event gets propagated >> >> around the system, but I'm thinking that the notion of a timeout would >> >> be handy here - page an ops guy or flag transactions from this point >> >> onward by this user as invalid, etc... >> >> >> >> Thanks, >> >> Matt >> >> >> >> >> > >> > >> > > >> > >> >> > > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
