Quartz recurring schedule (polling)

[Brett]

Hi,

I've hooked up quartz to MT, and would like to continually poll an external service every minute.

My consumer performs its actions, then at the end, reschedules itself by submitting a ScheduleMessage to the bus.

My question relates to how I kick off my initial poll operation, without ending up with multiple schedules.

For example:
- start service bus
- send initial poll message
- consume poll message (and poll external service)
- reschedule poll in 60 seconds

However, if in that 60 seconds I close my service bus service, the existing schedule is already configured, when I restart the above process, I will end up with two schedules for the polling operation.

One option is to cancel the existing scheduled message when closing the service bus - however how would you go about keeping a reference to the current TokenId of the scheduled message? I'm not sure this option would work 100% given that if my process crashes, I may not have a chance to clean up my schedules.

Another thought I had was to check if a message type was already scheduled. Is there any way to do that in quartz / MT?

I'm hoping this is a common requirement and I'm missing something easy!

Thanks.

Brett

[Brett]

One further point, the quartz schedules are durable via a SQL server database.

[Chris Patterson]

When you use the recurring scheduling feature of MassTransit 3 (which was merged from a pull request), I believe you can do scheduled events and specify a trigger name and a schedule (using a cron syntax I think).

If you just have a single consumer for the message that runs at one time, it would avoid doing it multiple times. I think this might work for you.

In fact, schedule the message for every minute -- and then have the service run the actual work as an async task, and keep track of the state of that task outside the consumer and just use the message receipt to "check in" on that task to see if it's been run or needs to run again. Of course, you're keeping state around at that point, which could warrant just using a state machine (maybe via Automatonymous) to keep track of what's running.

But this sounds super complex for a simple polling operation, so I'm not sure what the problem with just polling perhaps more often than needed every random time.

Since you're polling, just use the recurring schedule and there you go.

--
You received this message because you are subscribed to the Google Groups "masstransit-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to masstransit-dis...@googlegroups.com.
To post to this group, send email to masstrans...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/masstransit-discuss/d9452a64-3859-4787-8e28-d866d6b1c026%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Chris Patterson]

I can't be absolute, but I believe if you specify a schedule with the same "key" - the schedule is just updated and not duplicated in Quartz.

On Fri, Sep 18, 2015 at 4:09 PM, Brett <br...@wareyes.org> wrote:

Should have mentioned this is on MT 2.10.1. By "recurring schedule", what I really mean is that once the consumer finishes it's actual task, it reschedule's itself.

I feel I'm missing something fundamental here, the core issue is if I create an initial schedule when my service starts, each time I start my service, I end up with a new duplicate schedule.

If I moved up to MT3, and used a true recurring schedule, would I face the same issue?

Thanks.

To view this discussion on the web visit https://groups.google.com/d/msgid/masstransit-discuss/cf58f8c2-6ba0-4018-a449-f79833a9f3dd%40googlegroups.com.

[Brett]

Thanks, might give that a go.

I've implemented a workaround, when my service bootstraps and schedules the polling, I include the process ID in the schedule message. When consuming the scheduled message, I check that the current process ID matches the original ID, if they don't match, I disregard the request.

Thus I never end up with duplicate schedules running through the system.

To unsubscribe from this group and stop receiving emails from it, send an email to masstransit-discuss+unsub...@googlegroups.com.

To post to this group, send email to masstrans...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/masstransit-discuss/d9452a64-3859-4787-8e28-d866d6b1c026%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "masstransit-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to masstransit-discuss+unsub...@googlegroups.com.

To post to this group, send email to masstrans...@googlegroups.com.

[Benjamin Kotvis]

Hi Chris.  I think the cancel of a recurring schedule should just require the original schedule id.  On line 71 of the ScheduleMessageConsumer it adds "Recurring.Trigger." to the quartz triggers. 

var triggerKey = new TriggerKey("Recurring.Trigger." + context.Message.Schedule.ScheduleId, context.Message.Schedule.ScheduleGroup);

When you cancel it isn't obvious that you would need that in the ScheduleId to effectively cancel it.  Seems like we could change the:

bool unscheduledJob = _scheduler.UnscheduleJob(new TriggerKey(context.Message.ScheduleId, context.Message.ScheduleGroup));

to

bool unscheduledJob = _scheduler.UnscheduleJob(new TriggerKey(string.Format("Recurring.Trigger.{0}" ,context.Message.ScheduleId), context.Message.ScheduleGroup));

Then you could use the same ScheduleId that you used to create the recurring schedule.  The work around is adding that to the ScheduleId when you want to cancel.  Great library!  How do I become a contributor?

To unsubscribe from this group and stop receiving emails from it, send an email to masstransit-discuss+unsub...@googlegroups.com.

To post to this group, send email to masstrans...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/masstransit-discuss/d9452a64-3859-4787-8e28-d866d6b1c026%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "masstransit-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to masstransit-discuss+unsub...@googlegroups.com.

To post to this group, send email to masstrans...@googlegroups.com.

[Chris Patterson]

Well, a pull request to straighten this out would be a great start :)

I didn't write the recurring support originally, it was submitted as a pull request. So if there is something awry in the cancel side that should be easily fixed as you expressed above. 

__
Chris Patterson

To unsubscribe from this group and stop receiving emails from it, send an email to masstransit-dis...@googlegroups.com.

To post to this group, send email to masstrans...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/masstransit-discuss/ecb8013d-a10b-4c95-b3c7-9ac362267b2d%40googlegroups.com.

[Benjamin Kotvis]

I will take a stab at Github and a pull request.  I haven't worked with it but I suppose now is as good of a time as any to learn it.  Thanks for the timely reply.