Hi.
Looking at a trying to work/walk through a problem.
I have a gearman daemon/server app running on a master machine. The master gearman process places the jobs on the queue as a background process, ie it doesn't wait for a return from the worker/child app.
I also have 10-20 client machines, that are workers/children of the master gearman process.
All of the machines are connected, via ssh (bidirectional).
The local/client machines/apps can easily recieve the jobs from the master process.
However, I'm considering an issue where I want the client processes to be able to return their results back to the master when the client apps have completed their work.
So, as far as I can tell, I've got a couple of potential approaches:
--I can have the client push the returned data back to the master system, via ssh, where I invoke a remote process running on the master system
--I could implement a webservice kind of approach and pass the returned packets back via the service
-I was wondering if it wwould be possible to have each client app also act as a gearman master app, with all the client apps running on the same localhost/port, and then using the ssh forwarding process, have all the clients be received by an app running as a worker on the masterside.
The masterside would have to have the ssh tunneling/forwarding setup to "listen" to the same port on all of the client systems... (Is this even possible, without conflicts??) I ran a short test with two different clients and a 3rd master app to listen/process the work/jobs, and got a port conflict error, but it could have been due to something not being configured correctly.
Thoughts/comments??
Thanks
On Mon, Oct 7, 2013 at 3:28 PM, bruce badouglas@gmail.com wrote:
Hi.
Looking at a trying to work/walk through a problem.
I have a gearman daemon/server app running on a master machine. The master gearman process places the jobs on the queue as a background process, ie it doesn't wait for a return from the worker/child app.
I also have 10-20 client machines, that are workers/children of the master gearman process.
All of the machines are connected, via ssh (bidirectional).
The local/client machines/apps can easily recieve the jobs from the master process.
However, I'm considering an issue where I want the client processes to be able to return their results back to the master when the client apps have completed their work.
So, as far as I can tell, I've got a couple of potential approaches:
--I can have the client push the returned data back to the master system, via ssh, where I invoke a remote process running on the masterr system
--I could implement a webservice kind of approach and pass the returned packets back via the service
-I was wondering if it wwould be possible to have each client app also act as a gearman master app, with all the client apps running on the same localhost/port, and then using the ssh forwarding process, have all the clients be received by an app running as a worker on the masterside.
The masterside would have to have the ssh tunneling/forwarding setup to "listen" to the same port on all of the client systems... (Is this even possible, without conflicts??) I ran a short test with two different clients and a 3rd master app to listen/process the work/jobs, and got a port conflict error, but it could have been due to something not being configured correctly.
Thoughts/comments??
Thanks
On 7 October 2013 16:45, bruce badouglas@gmail.com wrote:
--I can have the client push the returned data back to the master system, via ssh, where I invoke a remote process running on the master system
Hi: Why not just to create a simple bash, or similar, script on each client and then exec from the master? (something like nagios' nrpe) Just a ssh client "my_lovely_script.sh" and then parse/process the output and see if the job is finished. It's not automatic, but the delay shouldn't be that bad...
Regards