Reinhard Vicinus
2018-10-20 22:36:03 UTC
Hi,
we have recently activated multi threading in our haproxy (version
1.8.14) and stumbled over the following problem:
we balance ftp via haproxy and after enabling multi threading, trying to
transfer very small files via ftp sometimes failed, with log entries
like this:
 Oct 20 22:45:58 vptest02 haproxy[11753]: 127.0.0.1:56631
[20/Oct/2018:22:45:58.787] ftp ftp/ftp 1/-1/0 0 CC 2/2/1/1/0 0/0
I could narrow down the problem to the option abortonclose. If enabled
and the frontend receives the complete data transfer before fully
establishing a connection to the backend the backend connection gets
reseted and the line above is logged.
Attached is a test haproxy configuration were i was able to reproduce
the problem and a tcpdump showing the problem.
I'm not sure if this is a bug or the documentation of the abortonclose
option should be expanded. From the documentation I first thought that
the option abortonclose only works in conjunction with mode http,
because only the http protocol is mentioned. In tcp mode the question in
my opinion is: "When is a connection aborted?". Thinking about it I came
to the conclusion that the abortonclose can make sense on mode tcp too
as long as the protocol used on the connection requires an answer from
the server. But if that is the case then the documentation of
abortonclose should explicitly mentioning that there are tcp based
protocols with which it will produce errors because they don't expect an
answer from the server.
Regarding why it only happens with multi threading enabled: Could it be
that a single threaded haproxy always opens the backend connection fully
prior to closing the frontend connection and therefore avoided the
problem altogether?
But I'm no haproxy expert so I can be completely wrong and the issue is
something completely differently. Please let me know if further
information is needed to investigate this issue.
Regards
Reinhard Vicinus
we have recently activated multi threading in our haproxy (version
1.8.14) and stumbled over the following problem:
we balance ftp via haproxy and after enabling multi threading, trying to
transfer very small files via ftp sometimes failed, with log entries
like this:
 Oct 20 22:45:58 vptest02 haproxy[11753]: 127.0.0.1:56631
[20/Oct/2018:22:45:58.787] ftp ftp/ftp 1/-1/0 0 CC 2/2/1/1/0 0/0
I could narrow down the problem to the option abortonclose. If enabled
and the frontend receives the complete data transfer before fully
establishing a connection to the backend the backend connection gets
reseted and the line above is logged.
Attached is a test haproxy configuration were i was able to reproduce
the problem and a tcpdump showing the problem.
I'm not sure if this is a bug or the documentation of the abortonclose
option should be expanded. From the documentation I first thought that
the option abortonclose only works in conjunction with mode http,
because only the http protocol is mentioned. In tcp mode the question in
my opinion is: "When is a connection aborted?". Thinking about it I came
to the conclusion that the abortonclose can make sense on mode tcp too
as long as the protocol used on the connection requires an answer from
the server. But if that is the case then the documentation of
abortonclose should explicitly mentioning that there are tcp based
protocols with which it will produce errors because they don't expect an
answer from the server.
Regarding why it only happens with multi threading enabled: Could it be
that a single threaded haproxy always opens the backend connection fully
prior to closing the frontend connection and therefore avoided the
problem altogether?
But I'm no haproxy expert so I can be completely wrong and the issue is
something completely differently. Please let me know if further
information is needed to investigate this issue.
Regards
Reinhard Vicinus