[
https://issues.apache.org/jira/browse/PROTON-2121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17041785#comment-17041785
]
Jiri Daněk edited comment on PROTON-2121 at 2/21/20 12:05 PM:
--------------------------------------------------------------
Issue is currently still present on master.
{noformat}
27: test_connection_close_all
(blocking_connection_fd_leak_test.BlockingConnectionFDLeakTests) ... 27: FAIL
27: test_connection_close_all__do_not_check_test_broker
(blocking_connection_fd_leak_test.BlockingConnectionFDLeakTests) ... ok
27: test_connection_receiver_close_all
(blocking_connection_fd_leak_test.BlockingConnectionFDLeakTests) ... 27: FAIL
27: test_connection_sender_close_all
(blocking_connection_fd_leak_test.BlockingConnectionFDLeakTests) ... 27: FAIL
27: test_just_start_stop_test_broker
(blocking_connection_fd_leak_test.BlockingConnectionFDLeakTests) ... 27: FAIL
{noformat}
On 0.27.0, I also saw that opening a sender does not leak. Regarding opening a
receiver, although no socket file descriptors are leaked when receiver is
opened and closed, there are pipe file descriptors which do seem to be leaking
when running the test with out-of-process broker. Plus there is a leaking
socket fd from the mock broker used in the test, when it is run that way.
{noformat}
FAIL: test_connection_receiver_close_all(self):
----------------------------------------------------------------------
total 0
lr-x------ 1 jdanek users 64 Feb 21 12:56 0 -> pipe:[4566812]
l-wx------ 1 jdanek users 64 Feb 21 12:56 1 -> pipe:[4566813]
l-wx------ 1 jdanek users 64 Feb 21 12:56 2 -> pipe:[4566814]
lr-x------ 1 jdanek users 64 Feb 21 12:56 5 -> pipe:[4573268]
l-wx------ 1 jdanek users 64 Feb 21 12:56 6 -> pipe:[4573268]
Found 2 new fd(s) after the test
2 != 0
Expected :0
Actual :2
{noformat}
Regarding how the test is written. It might make sense to have the mock broker
running in a child subprocess, or possibly both the client and broker each in
their respective subprocesses, just to simplify analyzing which fd belongs to
what. On the other hand, that would make the test seem unnecessary complicated
when this is fixed and nothing is leaking any more.
Edit: another issue is that the accounting of fds is imprecise in the test. I
noticed that when there is more than one test leaking, and fds are then being
closed by timeout, the test starts reporting nonsense (such as -2 fds leaking
in a test that actually works fine, but the test before failed with +2 fds
leaked and they got released later...).
was (Author: jdanek):
Issue is currently still present on master.
{noformat}
27: test_connection_close_all
(blocking_connection_fd_leak_test.BlockingConnectionFDLeakTests) ... 27: FAIL
27: test_connection_close_all__do_not_check_test_broker
(blocking_connection_fd_leak_test.BlockingConnectionFDLeakTests) ... ok
27: test_connection_receiver_close_all
(blocking_connection_fd_leak_test.BlockingConnectionFDLeakTests) ... 27: FAIL
27: test_connection_sender_close_all
(blocking_connection_fd_leak_test.BlockingConnectionFDLeakTests) ... 27: FAIL
27: test_just_start_stop_test_broker
(blocking_connection_fd_leak_test.BlockingConnectionFDLeakTests) ... 27: FAIL
{noformat}
On 0.27.0, I also saw that opening a sender does not leak. Regarding opening a
receiver, although no socket file descriptors are leaked when receiver is
opened and closed, there are pipe file descriptors which do seem to be leaking
when running the test with out-of-process broker. Plus there is a leaking
socket fd from the mock broker used in the test, when it is run that way.
{noformat}
FAIL: test_connection_receiver_close_all(self):
----------------------------------------------------------------------
total 0
lr-x------ 1 jdanek users 64 Feb 21 12:56 0 -> pipe:[4566812]
l-wx------ 1 jdanek users 64 Feb 21 12:56 1 -> pipe:[4566813]
l-wx------ 1 jdanek users 64 Feb 21 12:56 2 -> pipe:[4566814]
lr-x------ 1 jdanek users 64 Feb 21 12:56 5 -> pipe:[4573268]
l-wx------ 1 jdanek users 64 Feb 21 12:56 6 -> pipe:[4573268]
Found 2 new fd(s) after the test
2 != 0
Expected :0
Actual :2
{noformat}
Regarding how the test is written. It might make sense to have the mock broker
running in a child subprocess, or possibly both the client and broker each in
their respective subprocesses, just to simplify analyzing which fd belongs to
what. On the other hand, that would make the test seem unnecessary complicated
when this is fixed and nothing is leaking any more.
> python-qpid-proton 0.28 BlockingConnection leaks connections (does not close
> file descriptors)
> ----------------------------------------------------------------------------------------------
>
> Key: PROTON-2121
> URL: https://issues.apache.org/jira/browse/PROTON-2121
> Project: Qpid Proton
> Issue Type: Bug
> Affects Versions: proton-c-0.28.0
> Reporter: Lukas
> Priority: Major
>
> Starting in proton 0.28.0 and verified in 0.29.0b1 (pre-release) I can
> confirm following issue:
>
> {code:java}
> from proton.utils import BlockingConnection
> c = BlockingConnection(YOUR_ADDRESS)
> c.close()
> # ^^ FINE, all file descriptors closed properly
> from proton.utils import BlockingConnection
> c = BlockingConnection(YOUR_ADDRESS)
> s = c.create_sender(YOUR_EXCHANGE)
> s.close()
> c.close()
> # ^^ leaks the socket file descriptor - connection not closed properly (ls
> /proc/YOUR_PID/fd to verify){code}
>
> Version 0.27.0 is *not* affected by this issue.
>
> Having a quick look at the proton bindings, this very well might be bug in
> the qpid proton library itself, not the python bindings!
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
