Amphp gets stuck in and infinite loop doing nothing if firewall delays port access
c33s opened this issue · comments
@kelunik told me to open a ticket here.
Please open an issue at https://github.com/amphp/parallel for the infinite loop and https://github.com/amphp/process for the ports if you want.
its quite a while but as the problem with box was easy solvable by using the --no-parallel option i simply forgot until i hit the problem again with fink.
i am not sure where to write which info, it feels i would post the same text in parallel and process as i haven't used amphp directly but only tools which use it, i don't know the internals.
if i run fink it simply gets stuck forever on a windows system with a firewall.
php fink.phar https://getcomposer.org
if my firewall is in learning mode, it ask me to allow ampXXXX.tmp a local connection.
after allowing it, the connection monitor show the following:
this 3 php and amp processes stay there forever in an infinite loop and are doing nothing (no more as the initial 22 bytes are sent or received).
if i run the firewall in allow all mode (which sadly makes no sense at all), it works without a problem.
so it looks like amphp has a problem if the port is not instantly accessible but delayed by a firewall learning mode dialog.
as the amp process names are randomly generated it is not possible to precreate the firewall rules.
having some kind of check if ports can be accessed and if not some kind of fallback could be a solution. a slow synchronous processing is still faster as a infinite do nothing processing :)
edit: non-dynamic ports can also help (only in combination with non random process names)
I've fixed this by writing to a deterministic destination based on the content hash of the wrapper process. Could you test it by requiring dev-master as 1.1.1 and building a fresh fink PHAR?
using a fink.phar with process dev-master works.
- put firewall wizard mode
- run fink
- setup firewall rule via wizard
- cancel fink (it still gets stuck)
- re-run fink
done.
@trowski the process gets stuck idle. yes it looks like the code you referred doesn't get triggered.
having a timeout with an error message would at least help for a faster debug but even better would be a synchronous fallback showing only a warning that this call is not async.
@trowski i think i have to revise my last comment. as i am using the lib with fink or box and not standalone have noticed different behaviors.
with fink results in an error:
------------------------------------------------------
Concurrency: 0, Queue size: 0, Failures: 1/1 (100.00%)
Up 15.1 sec, 0.10 r/sec, 0.00 ms/r
so it looks like we have an 15sec timeout, an exception which is caught by the app and a failure after the app finished.
maybe i thought it was stuck again after 5sec.
the never ending loop i had with an old version with box.
@trowski tested it again with the current fink version in source form (so processwrapper64.exe is called directly.
now the process is stuck again. it looks like the problem lies in the delayed port access. processWrapper64 is started, firewall wizard pops up, it takes some time to allow it and afterwards fink is stuck. nothing happens, no more output. processWrapper64 is open, 0% cpu, 3 connections open.