RSB - subscriptions and timeouts

[Matt Burton]

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

[Ayende Rahien]

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

[Matt Burton]

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

[Ayende Rahien]

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

[Matt Burton]

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

[Ayende Rahien]

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 :-)

[Matt Burton]

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

[Ayende Rahien]

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 :-)

[Matt Burton]

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?

[Ayende Rahien]

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.

[Rachid Lamtabbet]

Any updates on the TimeToBeRecieved support on RSB?

[Rachid Lamtabbet]

Any updates on the support of the TimeToBeRecieved on RSB?

Thanks

On Tuesday, February 24, 2009 12:04:14 AM UTC-5, Ayende Rahien wrote: