Any updates on the TimeToBeRecieved support on RSB? On Tuesday, February 24, 2009 12:04:14 AM UTC-5, Ayende Rahien 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] > <javascript:>> 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] >> <javascript:>> 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] >> <javascript:>> 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] >> <javascript:>> 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] >> <javascript:>> >> >> > 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 unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/rhino-tools-dev. For more options, visit https://groups.google.com/d/optout.
