Add method for retrieving status of a running task #15
Conversation
…t submitting the task handle. To be able to query the correct server for the status, this requires the client to only have one added server.
| job_request = gearman.job.GearmanJobRequest(job) | ||
| job_request.state = 'CREATED' | ||
|
|
||
| return self.get_job_status(job_request, poll_timeout) |
There was a problem hiding this comment.
This seems a bit like a hack. It looks like you've gotten the handle from GearmanJobRequest.handle and want to check on the status, but for some reason you don't have the GearmanJobRequest anymore.
My main objection here is the 1 connection limitation. I think you should try and rewrite this to poll all the connections, but maybe it'd be better if you kept track of the GearmanJobRequest objects, unless you have some external requirement to not store python objects, but only handles ?
There was a problem hiding this comment.
In it's current form it's a bit of a hack, yes. :-) I'm not too fond of storing the complete GermanJobRequest in a DB - there will be use cases where you want to simply poll a server (or a collection of servers) for the state of a job (from the CLI, for example) and don't have access to the complete GearmanJobRequest object.
Since an handle isn't unique to a host in Gearman (as duplicate local host names will generate the same handles across servers), I decided to use the server address provided to the client itself to inidicate which Gearman server to query for the status of the task. The idea (if I remember correctly) was to allow a client user to query the status of a task by creating a client with the gearman server to query, and then request the status of a handle from that server.
Polling all the connections are a possibility, but might return the wrong task if you have several servers with the same local host name - so either we're talking about a documentation issue (by polling all the connections) or a code issue (by only allowing the user of the library to set which server to poll). The last case solves the issue where you could store the (server, handle) pair in a DB and then request the job status at some point in time. I'm open for both, as long as the limitations are clear for the user.
|
I think requiring servers to have unique names is reasonable. More reasonable that limiting this to 1 connection. If you rewrite it to poll all servers and rely on them having unique hostnames, I'm ok with that just documenting that little detail. Another option is to take the connection as a argument, and poll all if it's Also, instead of directly instantiating (Incidentally, the hostname is in the handle, but that won't necessarily match the client side hostname, so that can't be used.) |
Added convenience function for retrieving the status of a task by just submitting the task handle.
To be able to query the correct server for the status, this requires the client to only have one added server.
Feel free to clean up the patch (I'm not happy about having to set CREATED as status, etc. It works, but there's probably better ways of achieving this).