Scheduled tasks limitations (or how tasks persistence is implemented)?

Question

I've started to read Hangfire documentation, and found nothing about task limitations.

As declared, tasks (or jobs) are stored somewhere.

Since they are just delegates, the only thing could be stored, as far as I understand, is a delegate "body" (IL?). But there could be closures, that provides some context for the task, e.g., some external services, that can require to load extra assemblies to run their code, etc.

How Hangfire deals with this?
Can task contain any instructions in its body, or there are any limitations?

Hooke

Answer 1

When you create a job it calls Job.FromExpression, if you pass it anything other than a method call expression it throws an exception. So the only thing you can pass in to BackgroundJob.Enqueue is a single line where that line calls a function.

It then serializes they type of the object and all passed in parameters in to JSON using JobHelper.ToJson. When you pass in a instance of a class the instance is not serialized, only the type is, if the execution crosses process boundaries it will loose internal state.

You may want to read up on the blog article on the old hangfire blog site "Are your methods ready to run in background?"

Phelips

Thanks for the answer and referenced article! I think, I've got my explanation, and the conclusion is that job/task methods are very limited by their content. One needs to pass all state, required to execute job. If one needs some dynamic state, he has to retrieve it from state, that was serialized on job scheduling (e.g., pass record identifier in database or file name/path). I'm disappointed a little - these are very important things, that must be placed on top of Hangfire home page. – Hooke

Answer 2

It seems the mechanism is based on Expression for scheduling operations and the library is intended for "internal" (in process) execution mainly in ASP.Net websites.

Meaning, all the assemblies needed for execution of a scheduled operation should be already loaded into the web applications memory space, because they were needed to schedule the job (the application wouldn't have compiled if it was missing a Type from an assembly that was not referenced).

Hope it makes things a little bit clearer!

Domeniga

"the application wouldn't have compiled if it was missing a Type from an assembly that was not referenced" - I meant dynamic assembly loading, e.g. some plugin-based scenario, when exact plugin assemblies are unknown at compile-time. – Hooke