1) TimeToBeRecieved is actually up until when do I care about a message. RSB currently doesn't support that, but I would love to get a patch.
2) Not supported currently, agreed about need. Patch is welcome :-) On Mon, Feb 23, 2009 at 10:22 PM, Matt Burton <[email protected]> wrote: > > 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 -~----------~----~----~----~------~----~------~--~---
