Dev list proposal is optional[1] at this time as there is not an active 1.12.1
or 1.13.1 release, so you are welcome to backport anytime without waiting for
votes.
Thanks for sharing the particulars of this fix, it will be good to have in
place if a support release is proposed.
[1]
This is a long-standing problem that we’d like to get into the support
branches. While the problem affects performance of transmission of large
messages it also causes decryption problems with secure communications using
TLSv1.3. While folks can avoid the problem by using TLSv1.2 we would
+1 to what Anthony is asking.
Rather the “fixing” the current behavior let’s just implement a behavior that
better achieves the goal of single hop optimization.
From what I recall for both the Java and C++ code is that we throw away all
metadata on a region whenever there is any triggering
I’m not sure I have answers so I’ll just ask more questions :-)
When a server is killed, does that provoke an asynchronous metadata update to
clients? I could be wrong about that but if it IS true, then perhaps we should
focus on optimizing that path. The sooner that a client can get accurate
Alberto, give us a mention on the draft PR and we can think about how it might
be tested too... might get more ideas from the group...
Thanks,
EB
On 9/18/20, 3:51 AM, "Alberto Bustamante Reyes"
wrote:
Hi,
Thanks for you messages, here you are some answers:
Dave:
Are there
Hi,
Thanks for you messages, here you are some answers:
Dave:
Are there cases in which one or two timeouts are followed by a successful
retry? Or does one timeout *always* end with more timeouts and, ultimately,
an IO error?
Not in our use case, which is kiling a server. In this case, timeouts
