search

glucaci / mongodb-quartz-net

MongoDB Job Store for Quartz.NET
MIT License
51 stars 41 forks source link

When using in the MassTransit.QuartzService host, fails to deserialize MassTransit.QuartzIntegration.ScheduledMessageJob object when trigger fires #5

Closed jpasichnyk closed 7 years ago

jpasichnyk commented 7 years ago

Not sure if you use MassTransit with Quartz integration for scheduled/delayed messages, and/or if that is a supported use case for this driver, but there seems to be a problem deserializing their message wrapper object from the mongo persisted quartz job.

Error is failed deserialization since there is no default constructor: https://github.com/MassTransit/MassTransit/blob/master/src/MassTransit.QuartzIntegration/ScheduledMessageJob.cs#L31

Here is their example hosting service: https://github.com/MassTransit/MassTransit/tree/master/src/MassTransit.QuartzService

Is this something to be addressed on your end, or should I bring it up with the MassTransit team?

chrisdrobison commented 7 years ago

The Mongo driver relies on a default constructor being present to instantiate objects. If there isn't one then you need to create a class map so that the driver will know how to create the object. On Fri, Jan 6, 2017 at 5:11 PM Jesse Pasichnyk notifications@github.com wrote:

Not sure if you use MassTransit with Quartz integration for scheduled/delayed messages, and/or if that is a supported use case for this driver, but there seems to be a problem deserializing their message wrapper object from the mongo persisted quartz job.

Error is failed deserialization since there is no default constructor: https://github.com/MassTransit/MassTransit/blob/master/src/MassTransit.QuartzIntegration/ScheduledMessageJob.cs#L31

Here is their example hosting service: https://github.com/MassTransit/MassTransit/tree/master/src/MassTransit.QuartzService

Is this something to be addressed on your end, or should I bring it up with the MassTransit team?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/chrisdrobison/mongodb-quartz-net/issues/5, or mute the thread https://github.com/notifications/unsubscribe-auth/ABu24bUXoDlxiyuu9o1H6pWgDUkKhA4Nks5rPtgpgaJpZM4LdPw0 .

jpasichnyk commented 7 years ago

Ok, I posted https://github.com/MassTransit/MassTransit/issues/756 to MassTransit team to look into the constructor thing, because I'm pretty sure none of their job persistence can be working as is. Will see. :)

jpasichnyk commented 7 years ago

@chrisdrobison If you look at the referenced MassTransit issue I created (https://github.com/MassTransit/MassTransit/issues/756) it looks like they rely on the Quartznet provided https://github.com/quartznet/quartznet/blob/master/src/Quartz/SPI/IJobFactory.cs interface implementation to rehydrate jobs that have been previously serialized for persistent storage.

Would it make sense for MongoDbJobStore to rely on that same interface, to keep it more focused on the storage/retrieval of jobs using MongoDB and not dealing with the actual job data? Seems like this would keep it flexible for uses like MassTransit where a simple deserialization of a custom https://github.com/quartznet/quartznet/blob/master/src/Quartz/IJob.cs doesn't suffice?

chrisdrobison commented 7 years ago

If you could propose something in a pull request, that would be great. This job store follows the built-in job store fairly closely so it should handle these situations pretty well. I use it for scheduled retries without any issue. Do you have a stack trace as to where it fails to deserialize the job? As I recall, jobs themselves aren't store directly, but just the data, which this library binary serializes to avoid having to class map everything. I'll have to look.

jpasichnyk commented 7 years ago

@chrisdrobison it turns out there is no change required, I simply needed to wire up https://github.com/MassTransit/MassTransit/blob/master/src/MassTransit.QuartzIntegration/MassTransitJobFactory.cs as the schedulers JobFactory, and all is good. :)