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
-~----------~----~----~----~------~----~------~--~---
