I guess I should expect the patch response by now. :) For the saga timeout feature, the way that NSB does it is you call the RequestTimeout method on the base Saga class with a time to completion - say my saga can take no more than 30 seconds to complete. The timeout manager then participates at that point, monitoring messages flowing through the system and I'm not quite sure what happens when the time is surpassed - haven't dug fully into it. Maybe this is a terminology issue - when I think "timeout" I think of an operation timing out, you had 10 seconds to do this thing and it took you 15, therefore my call to you timed out, etc... You post on timeouts in RSB talked about the delay send feature - are you using timeout to talk about future activity, then?
On Tue, Feb 24, 2009 at 6:47 AM, Ayende Rahien <[email protected]> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
