exit() hangs when called after getSocket(ZMQ::SOCKET_PULL) but NOT after getSocket(ZMQ::SOCKET_PUSH)

[zhiyong-ft]

When I was trying to debug some PHP script that doesn't terminate as expected, I tracked down the problem to be something related ReactPHP and ZMQ. When exit() is called after getSocket(ZMQ::SOCKET_PULL), PHP script will hang. A minimum test code is included below:

use React\ZMQ\Context;

require dirname(__DIR__).'/vendor/autoload.php';

$testLoop = React\EventLoop\Loop::get();
$testContext = new Context($testLoop);

$testPusher = $testContext->getSocket(ZMQ::SOCKET_PUSH);
$testPusher->bind('tcp://127.0.0.1:5555');

//exit("exited after ZMQ:SOCKET_PUSH / before ZMQ::SOCKET_PULL\r\n");

$testPuller = $testContext->getSocket(ZMQ::SOCKET_PULL);

exit("tried to exit after ZMQ::SOCKET_PULL\r\n");

$testPuller->bind('tcp://127.0.0.1:5557');

Running the script above yields the following output in terminal:

php app/zmq-exit-test.php
tried to exit after ZMQ::SOCKET_PULL
^C // script continues to run till Ctrl + C is pressed on keyboard

The above code is tested on Ubuntu 20.04 with PHP7.4,React/ZMQ 0.4.0 (2018-05-18)

[SimonFrings]

Hey @zhiyong-ft, thanks for bringing this up 👍

Not an ZMQ expert here, but I think if you want to pull something you have to wait for the incoming data until they arrive (same goes for readable streams). This is why it seems like the script hangs, when it is actually just waiting for data.

However, this is not the case for a push operation. Once the data you wish to send out is pushed, the operation is considered complete.

FYI: I think this kind of ticket is better suited for a discussion in our "Q&A" section, this is why I converted the original issue into a discussion. We recommend opening bug tickets only when you can provide evidence of something being broken, just as a friendly reminder for future tickets :)

Hope this helps :)

[zhiyong-ft]

@SimonFrings Thanks for your reply. I don't know enough about PHP/ZMQ to agree/disagree with your explanation about why script hangs. But the fact that script doesn't terminate after exit() is called is a bit alarming. When exception happens, we may rely on calling exit() to terminate a script then restart it by other tools like supervisor or similar. Imagine what happens when long running scripts don't auto-restart.

[clue]

@zhiyong-ft It looks like you may want to use Loop::run() or Loop::stop() if you don't want to rely on loop autorun in this case. I'm not sure what problem you're seeing exactly and what your expected output would be in this case, but ReactPHP gives you full control over these low-level details if needed for more advanced use cases.

[zhiyong-ft]

@clue thanks for your reply. The problem we had originated from how to handle MySQL exceptions when running Ratchet Websocket server. We want ratchet scripts to terminate so they can be restarted if external MySQL server restarts. We put an exit() in the global exception handler, something like the following:

public function exceptionHandler(\Throwable $e)
{
    if(Config::get('APP_DEBUG')) {
        echo (date("Y-m-d H:i:s").", uncaught exception: ".$e->getMessage().PHP_EOL."");
    } else {
        \Sentry\captureException($e);
    }

    // Don't use exit()
    // exit() will hang when called after getSocket(ZMQ::SOCKET_PULL)
    exec('kill ' . getmypid());
}

What we found by killing external MySQL server is, despite exceptionHandler being called, those ratchet scripts kept running from Supervisor's perspective. In the end, we used:

exec('kill ' . getmypid());

instead of exit() as a workaround. So far that seems working.

[clue]

@zhiyong-ft Did you get a chance to take a look at the link I shared earlier? The documentation specifically mentions using Loop::stop() when using a global exception handler. This appears to be precisely the kind of problem you’re seeing. Along these lines, it is probably unnecessary to forcefully kill processes, let alone to execute any external programs.

[zhiyong-ft]

@clue I didn't know about the need to use Loop:stop() in exception handler at the time, but I did review it after your post. Unfortunately the global exception handler in our code was shared by both React based and non-React based classes, so we will stick with exec('kill ' . getmypid()) for the time being. Otherwise we will have to refactor a lot of code.

On a side note, I am just curious how to prevent exit() from terminating the running script. According stackoverflow, this doesn't seem like an easy job to do.