HangfireIO / Hangfire

An easy way to perform background job processing in .NET and .NET Core applications. No Windows Service or separate process required
https://www.hangfire.io
Other
9.32k stars 1.69k forks source link

Using Remote Hangfire Server? #732

Open adamreed90 opened 7 years ago

adamreed90 commented 7 years ago

I would like to host a Hangfire Server remotely, then issue jobs on it. Is this not possible?

KeithBarrows commented 7 years ago

This would be my direction as well. Especially if we could have jobs that are not referenced by the remote server during build! This way, we could add a new job by dropping it in a file directory and not have to recompile the remote job server...

marcoCasamento commented 7 years ago

Perhaps I'm already doing something like this, but I'm roughly writing strings into storage hashes/lists through a method like this: string EnqueueNewJob(ITransaction transaction, string queue, string typeAssemblyQualifiedName, string methodName, string jobParameterTypes, string jobArguments) that returns the jobid it enqueues on the server. Are you thinking to something like that ?

KeithBarrows commented 7 years ago

@marcoCasamento - I don't think I quite get what you are doing. :)

Basically, I have a VS Solution that contains references to the Hangfire Server and such. I then have multiple solutions, 1 for each job, that are built separately. When I want to queue an AdHoc job, I just want to send the job name (as string) plus an ID (string) and send it to the server. The server would then have to instantiate the job object from the string name only, enqueue it and go from there.

If I understand your code, it seems like this might be what you are doing. Would you mind sharing a little bit more?

marcoCasamento commented 7 years ago

sorry I was on the phone and I'm too bad at it. Yes, exactly the point is to be able to enqueue or schedule a job without have to hard reference the assembly that contains the job. I just supply the string I need to the method and the JobServer process the Job.

The bunch of strings that I'm passing to the method above, are needed to be able to enqueue any kind of job, so I need the method that job have to launch, along with the type that contains it, the parameter of the job and so on.

When you refer to the jobname (string) and ID (string) of an AdHoc job what they exactly are ?

KeithBarrows commented 7 years ago

@marcoCasamento - JobName == Assembly name, ID = ID from SQL table to get all parameters for the job itself. If I want to get more in depth, I have a payload model that every job uses that contains: JobId (unique to calling system, not hangfire) UserId (who initiated this job) HangfireJobId (hangfire's job id, get this at time of enqueue in most cases) HangfireParentJobId (for successive jobs in hangfire) Cron (for recurring jobs) JobType (1 of the 4 types of jobs hangfire can handle) JobStatus (some jobs do external processing so this is passed back later) JobClassName (bare class name) JobAssemblyName (full assembly name) MethodName (method on object to enqueue)

I serialize this object to JSON and pass as a string. The server deserializes, creates the concrete class then enqueues passing the JSON into the job. Where I am having some difficulty is creating the concrete class. The difficulty is; all solutions use a small handful of homegrown framework references, yet these references alter over time. I don't want to have to update every job every time the framework changes.

marcoCasamento commented 7 years ago

Ok maybe I got it, more of a maintainability issue then.

One possible idea to mitigate the problem could be to decorate the job method with an attribute that uniquely identify it (something like your JobId), then enqueue the job by supplying that identifier and the JSON serialized array of arguments. That obviously doesn't solve the problem of the parameters though, that are definitely the thing that change more often, but at least let you enqueue a Job without hard reference and shouldn't require you to change anything if the codebase's changes doesn't involve your job method parameters.

so something like that:

[JobName("someStringThatUniquelyIdenityTheJob")]
public string MyJob(string jobArg1, int jobArg2)

Then have something like

JobClient.Enqueue(string jobName, string arguments, string queue="default")

And of course the variations of this that will include Scheduling, Job Continuations and so on.

ofnhkb1 commented 7 years ago

I have encountered such a problem, what can be resolved? @marcoCasamento