Hello Baptiste,

On 26 February 2018 at 16:04, Baptiste <bed...@gmail.com> wrote:
> Your use case is right and I perfectly understand it and it makes sense to
> me.
> that said, in my use case, I was using (and meaning) SRV records and using
> consul / kubernetes as backend servers.
> What I saw is that when the response is too big, the server will send only
> the SRV records with TC flag and no "ADDITIONAL" section. So in such case,
> it was still acceptable for HAProxy.

I see, that makes sense. But still when your actual SRV records grow
beyond the 1280 byte limit, you would hit the very same issue.



> According to you, what would be the best option:
> - entirely remove this "feature" and consider the admins know what they do
> (I include the copy/paste admins that simply copy content of different blog
> articles until "it works")
> - enable this feature for a single "retry" of the same query? (that would
> happen after we did a retry with a different query type)

Honestly, as long as we don't have proper TC handling with TCP
support, I think it makes more sense to remove it entirely.

Yes, downgrading only for the next retry, adding counters and making
the downgrade optional really helps to mitigate the mentioned issues;
but when I consider that the benefit only affects a certain response
size that can't be too big (so that it fits without the ADDITIONAL
section), then I don't think it's worth it.

Imho it makes more sense to remove this in 1.8 and work towards full
TCP support on TC in 1.9.


But, that is not a strong opinion, it's rather what I would personally
do, also considering the effort that has to be put into TCP support.
As long as we don't downgrade by default, I am OK with it.



Thanks,
Lukas

Reply via email to