I would need to check exactly what you are talking about.I think this is just a message in the future that would close the saga.
On Tue, Feb 24, 2009 at 10:11 AM, Matt Burton <[email protected]> wrote: > > 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 -~----------~----~----~----~------~----~------~--~---
