[DISCUSS][FlightRPC] Lifetime of endpoints

[James Duong <ja...@bitquilltech.com.INVALID>]

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 | jamesd@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.

Re: [DISCUSS][FlightRPC] Lifetime of endpoints

[David Li <li...@apache.org>]

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 | jamesd@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.