Does attempting to use the client and retrying authentication errors work? Also - if the endpoints are ephemeral, the clients would just get evicted from/time out of the cache naturally anyways right?
I've always found the implied statefulness of Handshake rather fragile/unsuited to gRPC and would rather try to get rid of it… On Tue, Aug 2, 2022, at 16:09, James Duong wrote: > Raising a discussion from this JDBC PR: > https://github.com/rafael-telles/arrow/pull/42#discussion_r930298691 > > It would make sense for an application to want to pool FlightClients when > possible. When getFlightInfo is used, it can potentially return several > different servers to connect to. However the calling application currently > cannot tell anything about these server's lifetime. For example, the > endpoints returned could be some set of fixed clusters or they could be > short-lived kubernetes containers. Since the application cannot make any > assumptions about the reusability of FlightClients, it cannot create > connection pools reliably. > > So I'm thinking an enhancement to the protocol would be an optimization > hint in the endpoint message to describe the endpoint lifetime. Perhaps > this can also be used to indicate if a full handshake is required to > connect to the endpoint or if existing headers from the originating request > can be re-used. > > -- > > *James Duong* > Lead Software Developer > Bit Quill Technologies Inc. > Direct: +1.604.562.6082 | jam...@bitquilltech.com > https://www.bitquilltech.com > > This email message is for the sole use of the intended recipient(s) and may > contain confidential and privileged information. Any unauthorized review, > use, disclosure, or distribution is prohibited. If you are not the > intended recipient, please contact the sender by reply email and destroy > all copies of the original message. Thank you.
