How are people debugging issues with gearman?
josh803316
an automation testing platform. I fired up the perl modules for
client and worker and installed the C server. I didn't realize until
later that the current perl version and current C version use
different default ports. I found out by looking through this forum. I
was wondering if there was any way to turn up debug on the perl or
client worker.......or even the C server, or if there are plans to
make them more robust in the future. I know the C server has -v
options to turn up the verbosity for connection watching.....but is
there a plan for detailed client/server/worker/queue/wakeup/threading/
load/connection debug options or is this something people have been
doing on their own? Just looking for best practices or suggestions on
debugging techniques.......
*I didn't get any helpful error when either my worker or client
attempted to connect to the server at the wrong port so I thought it
would be a good question to ask.
Yann Kerherve
>
> So I'm a gearman newbie, and I love it so far. I'm going to use it for
> an automation testing platform.
Cool, is that open sourced somewhere? hachi and I were talking about
that the other day to reduce the runtime of a unit test suite.
Yann
Josh803316
--J
Brian Moon
when it can not connect to the gearman server. Perl surely can do the same.
Brian.
--------
http://brian.moonspot.net/
Eric Day
Real documentation for Gearman is on my short list of things todo,
still busy getting some of the core features running first. For now
the mailing list and IRC channel are the best ways to get answers. I
plan on having a collection of real docs (or at least a start) by
OSCON in July. Getting back to your specific question...
The C server can take multiple -v flags. The more you specify,
the more details you see. I usually use -vv when doing most of my
testing. I would also look at the admin commands as well. For example:
> gearmand -vv
Starting up
Initializing libevent for main thread
Method for libevent: epoll
Trying to listen on :::4730
Listening on :::4730 (6)
Trying to listen on 0.0.0.0:4730
Address already in use 0.0.0.0:4730
Creating wakeup pipe
Creating 0 threads
Creating IO thread wakeup pipe
Adding event for listening socket (6)
Adding event for wakeup pipe
Entering main event loop
You can see it bound to port 4730. When I start up a reverse_worker
process, I see:
Accepted connection from ::10a0:e301:0:0%31701584:51298
[ 0] ::10a0:e301:0:0%31701584:51298 Connected
This is how you can verify when a connection happens. Now I check
some status variables by telnet/nc to the job server port:
> nc localhost 4730
status
reverse 0 0 1
.
workers
12 ::10a0:e301:0:0%31701584 - :
11 ::10a0:e301:0:0%31701584 - : reverse
.
I ran the 'status' and 'workers' commands, see other
commands towards the bottom of the protocol document
(http://www.gearman.org/doku.php?id=protocol). There are two
connections: the reverse_worker and the telnet connection I just
made. The server knows about the "reverse" function, and shows no
jobs in queue and one worker connected. If I now run reverse_client,
I see another quick connect/disconnect:
Accepted connection from ::10a0:e301:0:0%31701584:39173
[ 0] ::10a0:e301:0:0%31701584:39173 Connected
[ 0] ::10a0:e301:0:0%31701584:39173 Disconnected
As for the Perl client/worker, I'm not quite as familiar. I can say
though that you probably won't get much from the worker because it's
perfectly ok for a job server to be down, the worker will just keep
trying to reconnect to all the servers in the list. The worker will
never error because of a failed connection. A client should fail if
it cannot connect though.
-Eric
Josh803316
Thanks, that is a great place to start.....I'll use that logging as a way to pass control management info. I'm sure as time goes on, other people will add things as well. I'll try to add some myself to the perl side if I come up with some good solutions.
--J