Add method for retrieving status of a running task #15

Open
wants to merge 1 commit into
from

Projects

None yet

2 participants

@matslindh

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).

@matslindh matslindh Added convenience function for retrieving the status of a task by jus…
…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.
983e97c
@eskil eskil commented on the diff Mar 15, 2012
gearman/client.py
@@ -122,6 +122,17 @@ def continue_while_jobs_incomplete(any_activity):
return job_requests
+ def get_job_status_handle(self, handle, poll_timeout=None):
+ """Fetch the job status from a specific handle, if the Client only has one server added"""
+ assert type(len(self.connection_list) == 1), "Querying for job status by handle can only be performed with only one added server."
+
+ # create a job to perform the status fetch
+ job = gearman.job.GearmanJob(self.connection_list[0], handle, None, None, None)
+ job_request = gearman.job.GearmanJobRequest(job)
+ job_request.state = 'CREATED'
+
+ return self.get_job_status(job_request, poll_timeout)
@eskil
eskil Mar 15, 2012

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 ?

@matslindh
matslindh Mar 15, 2012

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.

@eskil

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 None, and if not, poll just that 1 connection.

Also, instead of directly instantiating GearmanJobRequest, please use self.job_request_class. That will be useful for those of us who mock all that stuff for unit-testing.

(Incidentally, the hostname is in the handle, but that won't necessarily match the client side hostname, so that can't be used.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment