yeah, that's very similar to quartz. granted quartz is much more robust. One word of caution: I wouldn't merge the when (scheduling) with the how (processing). The two work together, but they are not the same thing.
I ran into an issue once with RSB were I had a reoccurring event. i was using DelaySend to manage the next event. problem was if there was an error while processing the message the next occurance was never scheduled. having a scheduler (be it a simple timer or quartz) allowed the system to separate when the event should fire vs how the event should be processed. this created a stable environment and the individual components where very simple to implement. On Tuesday, April 17, 2012 12:27:25 PM UTC-4, Scott wrote: > > Thanks for the reply, Jason. I'll take a look at quartz.net. > > Another option I was discussing with a coworker is to create another > module to plug into RSB on startup. The module would create a Timer, > based on configuration, and when triggered, the Timer would add a > message to the bus to initiate the process. > > What I like about this approach is that it is still completely > contained within RSB as a module rather than having another place to > go to manage these processes. > > I'll do some experimentation to see what works best. > > > > On Apr 13, 2:42 pm, Jason Meckley <[email protected]> wrote: > > I've done this in the past integrating quartz.net and RSB. quartz > contains > > the schedule of when things happens. the jobs would send a message, via > > RSB, to do the actual work. in this case > > quartz has a schedule to fire job X the 1st of every month @ 10 pm. job > X > > sends a message to RSB DoMonthlyTallyMessage. then RSB consumes the > message. > > > > > > > > > > > > > > > > On Friday, April 13, 2012 3:34:39 PM UTC-4, Scott wrote: > > > > > I am kicking around the idea of how to have a recurring message be > > > placed on the service bus at a scheduled interval. For instance, we > > > have a process that runs at 1am on the first of every month. The > > > current process runs as a scheduled task and does not use RSB. We > > > have plans to completely rewrite this process to perform most of the > > > work with messages in RSB. For a number of reasons, I like the idea > > > of having the message be automatically placed on the bus to kick off > > > this process. > > > > > I have thought about having the consumer which consumes the message > > > publish a new message for the next scheduled execution(DelaySend). > > > That seems fragile in that any sort of error would cause the next > > > message to not be sent. And, how do you get the first message on the > > > bus? It could be done, but feels wrong, too. > > > > > We could have code that executes in a scheduled task which uses a > > > OneWayBus to put the message in the queue at the scheduled time. I > > > would like to get away from scheduled tasks for this, so I don't care > > > for this option, either. > > > > > What are your suggestions to handle a situation like this? -- You received this message because you are subscribed to the Google Groups "Rhino Tools Dev" group. To view this discussion on the web visit https://groups.google.com/d/msg/rhino-tools-dev/-/STEx3IWB9RMJ. 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.
