Hi Willy,
Op 15-11-2015 om 8:48 schreef Willy Tarreau:
Pieter,
I'm just seeing this part in your description while merging
the patch :
On Sun, Nov 08, 2015 at 07:19:21PM +0100, PiBa-NL wrote:
HOWEVER.
-i have not checked for memoryleaks, sockets not being closed properly
(i dont know how to..)
I'm not worried for this one, at first glance it looks OK.
-is setting current and last steps to null the proper way to reset the
step of rule evaluation?
Yes that's apparently it.
-CO_FL_ERROR is set when there is a connection error.. this seems to be
the proper check.
Indeed.
-but check->conn->flags & 0xFF is a bit of s guess from observing the
flags when it could connect but the server did not respond
properly.. is there a other better way?
This one is ugly. First, you should never use the numeric values
when there are defines or enums because if these flags happen to
change or move to something else, your value will not be spotted
and will not be converted.
Agreed it was ugly, but i could not find the enums based equivalent for
that value.. Now i think its only checking 1 bit of it. But that seems
to work alright to.
Second, normally you would just need "!CONNECTED", as this flag
is set once the connection is established. Note that I understood
from the commit message that you wanted to cover from connection
issues, but the code makes me think that you wanted to retry even
if the connection was properly established but the mail could not
be completely delivered.
I was thinking the state might include 'more' than only !CONNECTED.
Thus I'm attaching two proposals that I'd like you to test, the
first one verifies if the connection was established or not. The
second one checks if we've reached the last rule (implying all
of them were executed).
From my tests both work as you describe.
v1 one retries the connection part, v2 also retries if the mail sending
did not complete normally.
I think v2 would be the preferred solution.
Though looking through my tcpdumps again i do see it tries to connect
with 3 different client ports thats not how a normal tcp socket would
retry right? But i think thats not so much a problem, it does still make
me wonder a little what happens if a packet is lost in the middle of a
tcp connection, will it resend like a normal tcp connection? Its
difficult to test though..
If you can apply the v2 patch i think that solves most issues that one
or two lost packets can cause in any case.
Thanks,
Willy
Thanks,
PiBa-NL
