Scheduling a recurring message in RSB

[Scott]

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?

[Jason Meckley]

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.

[Scott]

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.

[Jason Meckley]

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.

[René M. Andersen]

+1 for Jason Meckleys suggestion. We've also tried using the Rhino ESB as scheduler and you are rigth it feels ackward and as Jason mentions it is error prone if message processing fails. We recently switched to use Quartz .NET as scheduler instead and it works like a charm. It is easy to setup, we use the Rhino ESB bootstrapper to initialize Quartz .NET. Just make sure to read this post before initializing it in the bootstrapper: https://groups.google.com/forum/#!topic/rhino-tools-dev/pEW7Gh7hsRM

Regards

René

[Corey Kaylor]

Agreed that Quartz .NET is a good fit.

--
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/-/1WJ7TIhYUqUJ.

To post to this group, send email to rhino-t...@googlegroups.com.
To unsubscribe from this group, send email to rhino-tools-d...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/rhino-tools-dev?hl=en.

[Scott]

I took a look at Quartz.Net yesterday on Jason's recommendation. It
does look like a good fit. Rene, I was thinking exactly that -
initialize the Quartz.net on startup. Thanks for the link, too. I'll
check it out.

This is starting to look like a good solution for us. Thanks for all
of your ideas.