21:32
Para: dev@geode.apache.org
Asunto: Re: Clean C++ client metadata in timeouts
+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
ailto:dev@geode.apache.org>>
Asunto: Re: Clean C++ client metadata in timeouts
Let's please consider how this would controlled and look for ways other than
YetAnotherProperty
Thanks,
EB
On 9/17/20, 12:59 PM, "Dave Barnes"
mailto:dbar...@apache.org><mailto:dbar...@apac
___
De: Ernie Burghardt mailto:burghar...@vmware.com>>
Enviado: jueves, 17 de septiembre de 2020 22:08
Para: dev@geode.apache.org<mailto:dev@geode.apache.org>
mailto:dev@geode.apache.org>>
Asunto: Re: Clean C++ client metadata in timeouts
Let's please consider how this would cont
Alberto B.
De: Ernie Burghardt
Enviado: jueves, 17 de septiembre de 2020 22:08
Para: dev@geode.apache.org
Asunto: Re: Clean C++ client metadata in timeouts
Let's please consider how this would controlled and look for ways other
than YetAnotherProperty
Than
/
Alberto B.
De: Ernie Burghardt
Enviado: jueves, 17 de septiembre de 2020 22:08
Para: dev@geode.apache.org
Asunto: Re: Clean C++ client metadata in timeouts
Let's please consider how this would controlled and look for ways other than
YetAnotherProperty
Thanks,
EB
Let's please consider how this would controlled and look for ways other than
YetAnotherProperty
Thanks,
EB
On 9/17/20, 12:59 PM, "Dave Barnes" wrote:
If a straight-up change solves a constant headache, as you suggest,
Alberto, and as Blake concurs, that sounds like the way to go.
If a straight-up change solves a constant headache, as you suggest,
Alberto, and as Blake concurs, that sounds like the way to go.
Why introduce a new option or property if the user will always prefer one
behavior over the other? (And from a docs perspective, who needs another
optional property,
Given that attempts to retrieve metadata after the C++ cache is closed are a
constant headache for Geode Native development, I am generally in favor of
anything that potentially reduces the number of times/places this happens. If
we've failed the handshake, it's very unlikely things will
Alberto,
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?
If timeouts can sometimes be followed by successful retries, and re-trying
is the current default behavior, then I agree that
Hi geode-dev,
I have a question about the c++ client.
Some months ago we merged GEODE-8231 to solve a problem we observed regarding
the native client was trying to connect to stopped server.
GEODE-8231 solution consists on remove the client metadata when an "IO error in
handshake" exception is
10 matches
Mail list logo
