Scheduling messages in a distributed environment

[Wallonman]

Hello,

I'm talking about the Scheduling API implemented in a MassTransit bus hosted in a distributed environment.

By "distributed environment" I mean a MassTransit bus deployed on more than one server, the endpoint consumers are therefore in competition to consume messages, they're also redundant : when one node fails, others continue doing their job.

When I schedule a message in a distributed environnement I want the "trigger" message to be sent "once".

The approach I use is the following :

• the trigger message will be pushed in the queue more that once : each node will schedule the trigger
• the consumers consume the trigger message, BUT only one consume must perform the job. To get that "singleton" working, I need a mutex shared between the nodes, for instance I like to work with Redis, and I use the Redlock pattern.

There are some caveats, like how to handle the case when the consumer that gets the mutex fails....

Is there anyone that uses another pattern to solve such requirement ?

Is there a kind of "distributed quartz.net" ?

Thank you,

Eric

[Chris Patterson]

MassTransit uses Quartz.NET for scheduling, allowing messages (events) to be scheduled. It's basically what you are described, distributed Quartz.NET.

--
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/818bb61b-e180-4038-875b-fbf0f547418b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Eric Piraux]

Yes indeed, but the question is what happens when there are two instances of MassTransit.QuartzIntegration that are running on two hosts ?

The probable answer is that the two instances will publish a message, triggering therefore two consumers.

What if the consumers must perform some actions that are supposed to be unique (ex: publishing the planning of the day in the morning)

Having two schedulers active is a gain in terms of availability, but is a pain because two triggers are published.

So the question is "how to avoid that double triggering" ?

Action can be taken at the consumer side, when triggered, each consumer will inform with a mutex its "colleagues" that it's going to do the job, the one that get the mutex do the job, others returns.

Action can (could) be taken at the quartz side - but I'm not quite sure - maybe using the ADOJobstore ? The idea is that several schedulers running on different hosts can share information to garantee the trigger to be uniquely triggered.

Any experience with that jobstore ?

To view this discussion on the web visit https://groups.google.com/d/msgid/masstransit-discuss/CAHX4WYfaRCmmUgV4xCSr6yjCfBqd3pfSc7ZXvTHweHbyxRGoRg%40mail.gmail.com.

[Chris Patterson]

I'm sorry, but you're thinking too hard.

Quartz.NET supports clustering, and you can have multiple instances of the service running pointed to the same Quartz.NET database. Configured properly, they will share the execution of scheduled jobs and you won't have any issues with duplicate messages being sent.

To view this discussion on the web visit https://groups.google.com/d/msgid/masstransit-discuss/CALao87F-h6-Se3N_-ofmcL3XhLg296GkGzY-tD79UqAY%3DLc37w%40mail.gmail.com.

[Eric Piraux]

Excellent! that's exactly what I wanted to get sure. Thank you.

To view this discussion on the web visit https://groups.google.com/d/msgid/masstransit-discuss/CAHX4WYcHc_wECfyrkaBOZ0M6fpSV4G7dqG%3DcxSqrZxaLLh_hTA%40mail.gmail.com.