GEARMAN_COMMAND_SUBMIT_JOB_EPOCH not work

Bug #1352411 reported by chjgcn on 2014-08-04
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Gearman
Undecided
Unassigned
php-gearman (Arch Linux)
Unknown
Unknown

Bug Description

When client side do a GEARMAN_COMMAND_SUBMIT_JOB_EPOCH command, the server side will communicate with worker side many many times, and make the cpu usage raise up to 100%, until all these jobs submitted with command GEARMAN_COMMAND_SUBMIT_JOB_EPOCH are completed. These days I read the code, and made some modifications, and split job_list of function into three list: job_list, job_bg_list, job_epoch_list, and add alarm for the nearest time of these jobs shall be run in the future.
The patch file I submit here contain these modifications, also those modifications in
    https://bugs.launchpad.net/gearmand/+bug/1338861
to support SSL well. It is not convenient for me to clear those modifications in that link.
After patching, I can use these commands
    GEARMAN_COMMAND_SUBMIT_JOB_EPOCH
    GEARMAN_COMMAND_SUBMIT_JOB_HIGH_EPOCH
    GEARMAN_COMMAND_SUBMIT_JOB_LOW_EPOCH
to submit jobs to run in the future, and it works perfectly.

chjgcn (chjgcn) wrote :
chjgcn (chjgcn) wrote :

Yesterday I forgot to add support of EPOCH jobs for protocol "HTTP", Today I add it and fix a small bug.
Then I do some test using protocal "HTTP" and "Gear", and it work fine for me.

chjgcn (chjgcn) wrote :

This patch adds client APIs "doEpoch", "doHighEpoch" and "doLowEpoch", fixes some small bugs, and changes the behavior of protocol "HTTP".
Before patching, if there are two or more responses to the client, the ones after the first one will have no header. And if there are two or more "WORK_DATA"s and two or more "WORK_COMPLETE"s from worker to server, the contents of "WORK_DATA"s of different jobs may join together. So I change the behavior of protocol "HTTP", do not try to join contents of "WORK_DATA"s together, and make sure that every request of "WORK_DATA" or "WORK_COMPLETE" from workers produces separate response to clients. I do not know this change is right or wrong, but in my tests, this change has made the response from server to client simpler and clearer than before.

chjgcn (chjgcn) wrote :

In the patch file above, I changed the behavior of protocol 'HTTP'. After my work on
    https://answers.launchpad.net/gearmand/+question/252097
, I rethink my change to protocol 'HTTP', then I restore the main design for it, fix bugs and make it more powerfull.
After patching, there will be only one response from server to client.
For background or planed job, when the job is created, a response of 'JOB_CREATED' without data will be sent to client.
For foreground job, when the job is created, there is no response of 'JOB_CREATED' sent to client; when the worker sends data back to server, the data will be stored separately by job handle; when the job is completed, the former stored data and the current returned data will be joined together, and a response of 'WORK_COMPLETE' with these data will be sent to client.
This patch improve protocol 'HTTP', and fix bugs which will occur in the situation that the jobs are sent from client one after one quickly, and the situation that the data from worker is too big.

chjgcn (chjgcn) wrote :

The newer patch file is in
    https://bugs.launchpad.net/gearmand/+bug/1348865/comments/6
I forgot to add <cstring> header file into
    libgearman/interface/universal.hpp

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.