Uncaught exception 'Zend\XmlRpc\Client\Exception\FaultException' with message 'BAD_NAME: workers:worker_1' when using stop/start from Process object

[mostonek]

// returns Process object
$process = $supervisor->getProcess('workers:worker_1');
$process->stop();

generates this:

PHP Fatal error: Uncaught exception 'Zend\XmlRpc\Client\Exception\FaultException' with message 'BAD_NAME: workers:worker_1' in /home/moston/web/indigophp/vendor/zendframework/zend-xmlrpc/Zend/XmlRpc/Client.php:323
Stack trace:
#0 /home/moston/web/indigophp/vendor/indigophp/supervisor/src/Connector/ZendConnector.php(83): Zend\XmlRpc\Client->call('supervisor.getP...', Array)
#1 /home/moston/web/indigophp/vendor/indigophp/supervisor/src/Process.php(63): Indigo\Supervisor\Connector\ZendConnector->call('supervisor', 'getProcessInfo', Array)
#2 /home/moston/web/indigophp/vendor/indigophp/supervisor/src/Supervisor.php(173): Indigo\Supervisor\Process->construct('workers:worker...', Object(Indigo\Supervisor\Connector\ZendConnector))
#3 /home/moston/web/indigophp/test.php(19): Indigo\Supervisor\Supervisor->getProcess('workers:worker...')
#4 {main}

Next exception 'Indigo\Supervisor\Exception\SupervisorException' with message 'BAD_NAME: workers:worker_1' in /home/moston/web/indigophp/vendor/indigophp/supervisor/src/Connector/ZendCon in /home/moston/web/indigophp/vendor/indigophp/supervisor/src/Connector/ZendConnector.php on line 85

[sagikazarmark]

DId you try any other connector? In my experience Zend XML-RPC is quite buggy.

[mostonek]

Problem also exist with other connectors such as fXmlRpc\Client.

[sagikazarmark]

Hm. And are you sure you have a workers group and a process worker_1 in it?

[mostonek]

Yup, I'm sure of it - otherwise I wouldn't get it in object. I can get info about it but any other action like stop/start won't work.

[sagikazarmark]

Ok, just checked. I will try to look into this in the next fews days, I will keep you posted.

Just for curiousity: which is your preferred connector?

I am asking because I am going to release an adapter pacakge for http client libraries with custom parser/serializer logic which will probably replace the current fXmlRpc connector and eventually Zend connector as well.

[mostonek]

I'm more attached to Zend Connector right now.

[sagikazarmark]

Thanks. Zend connector is there because it uses both Zend HTTP and XML-RPC component. As soon as the adapter package will be able to use Zend HTTP as a client adapter and Zend XML-RPC as parser (so can use the two decoupled from each other) the direct Zend connector will probably be gone, but that is at least from 2-3 releases from now (also not sure about completely removing it).

However always make sure that a popped error appears with other connectors as well, because Zend XML-RPC has some incompatibility issues (like client side variable compatibility check which is clearly a server side task). Also Zend parser is MUCH MORE slower than the ones provided by fXmlRpc. The more you know...

[mostonek]

Good to know - thanks for info :)

[sagikazarmark]

@mostonek Did you solve this? If not, can you please share your configuration with me? (Make sure that any credentials are removed)

[sagikazarmark]

BTW start/stop/etc responsibility has been removed from the Process object in the latest development branch. It became a value object. You can pass a Process object to a Supervisor instance startProcess method.

I suggest you checking the new version as the old code base was a bit ugly. It is much more clearer now.

[mostonek]

@sagikazarmark no, I had to come around that problem by making that call from Supervisor obj, not from Proccess obj.

my conf go something like that

$client = new Zend\XmlRpc\Client(SUPERVISOR_HOST);
$connector = new Indigo\Supervisor\Connector\ZendConnector($client);
$connector->setCredentials(SUPERVISOR_USER, SUPERVISOR_PASS);
$this->supervisor = new Supervisor($connector);

and this wont work:

$process = $this->supervisor->getProcess('workers:worker_1');
$process->stop();

and I had to do it like that in order to make it run properly:

$this->supervisor->stopProcess('workers:worker_1', $wait)

I will check new code later when I come back to refactor of my written class :)

[sagikazarmark]

Actually I was curious about your supervisor config. :)

I couldn't reproduce this so far, so I thought exactly the same environment could help. Also, can you please give me your supervisor version? This package is compatible with >3.0, but even with 3.0 I encounter issues which occur because of the differences between the docs and the API itself.

[mostonek]

Sorry, little misunderstanding ;)

this is supervisor conf:

[unix_http_server]
file=/var/run/supervisor.sock ; (the path to the socket file)
chmod = 0777
chown= nobody:nogroup
username = XXXXXXX
password = XXXXXXX

[inet_http_server]
port = *:9001
username = XXXXXXX
password = XXXXXXX

[program:scheduler]
command=php -q /XXXXXXXXXXX/scheduler.php
numprocs=1
numprocs_start=1
process_name=scheduler_%(process_num)s
autostart=false
autorestart=true
stopasgroup=true
killasgroup=true
environment=SCHEDULER_NUMBER=%(process_num)s

[program:worker]
command=php -q /XXXXXXXXXX/worker.php
numprocs=3
numprocs_start=1
process_name=worker_%(process_num)s
autostart=false
autorestart=true
stopasgroup=true
killasgroup=true
environment=WORKER_NUMBER=%(process_num)s,QUEUE_NUMBER=1

[eventlistener:crashmail]
command=crashmail -a -m XXXXXX@XXXXXX.XX
events=PROCESS_STATE_EXITED
environment=SUPERVISOR_USERNAME=user,SUPERVISOR_PASSWORD=123

[sagikazarmark]

I am not sure that it is possible to start processes like whis. According to this issue it is not obvious for me. I will look into it.

Also, your supervisor version, please.

[mostonek]

3.1.3

[sagikazarmark]

@mostonek I asked about this feature in the referenced issue and @mnaberez answered it. It seems to work fine with his configuration.

Based on your configuration you have to start/stop worker:worker_1 and not workers:.... By default the group name is the same as the name in the section header. You also have to keep in mind that the numbering starts from 0 and not 1. So in your case you should have worker_0, worker_1, worker_2. You can control this with the numprocs_start property.

Could you please try this out? Even with the old implementation of the client library (version < 3.0.0), it should work.

[sagikazarmark]

I am closing this issue for now. If the issue still exists, please open it at https://github.com/supervisorphp/supervisor