Saga timeout are handled by sending a message to yourself in the future, unless I don't understand what you mean about the NSB feature. For message interceptor, nice idea patch :-)
On Tue, Feb 24, 2009 at 12:22 AM, Matt Burton <[email protected]> wrote: > > 1) Ah - okay - thanks for clarifying. > 2) Yeah - think that would help for sure. > > Now how did I know you were going to ask for a patch? :) > > I'll see what I can do - will have some time possibly later in the week. > > Also - you mentioned that RSB supports the notion of saga timeouts > just like NSB - I'm not seeing where that is - how does that work? > > Lastly - idea for message modules, what about supporting the notion of > interceptors or "policies" (in PIAB-speak) where I have an explicit > interface like: > > IMessageInterceptor<T>: > BeforeConsume(T message) > AfterConsume(T message) > OnError(T message, Exception e) > > Something along those lines - targeted interceptors (i.e. for a given > message type, not all messages) loaded in the container and forms a > kind of pipeline for processing the messages - before, before, > consume, after, after, sort of thing... I know you can do this with > message modules today but this makes it a bit more accessible, IMO. > Just a thought... > > Thanks, > Matt > > On Mon, Feb 23, 2009 at 9:04 PM, Ayende Rahien <[email protected]> wrote: > > 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 -~----------~----~----~----~------~----~------~--~---
