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. On Apr 18, 12:45 pm, Corey Kaylor <[email protected]> wrote: > Agreed that Quartz .NET is a good fit. > > On Wed, Apr 18, 2012 at 12:44 PM, René M. Andersen < > > > > > > > > [email protected]> wrote: > > +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é > > > On Friday, 13 April 2012 21:34:39 UTC+2, 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? > > > On Friday, 13 April 2012 21:34:39 UTC+2, 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? > > > On Friday, 13 April 2012 21:34:39 UTC+2, 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/-/1WJ7TIhYUqUJ. > > > 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. -- 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.
