Sounds good - it would be good to have that context available.
Thanks,
David
On Thu, Feb 17, 2022, at 16:19, José Almeida wrote:
> Awesome,
>
> Our intention is not to make FlightSQLClient always wrap the
> RetryingFlightClient, but give the possibility to both have this
> functionality. So makin
Awesome,
Our intention is not to make FlightSQLClient always wrap the
RetryingFlightClient, but give the possibility to both have this
functionality. So making the changes in the FlightClient makes more sense.
Regarding the document, I can create a new one and attach it with the PR,
is that ok?
While we’re talking about this, for engines like Spark/Flink/Dask/Ray where
we might have many executors does it make sense to have centralized refresh
instead of each executor doing a refresh on token expiration?
On Thu, Feb 17, 2022 at 12:40 PM David Li wrote:
> That sounds reasonable.
>
> I w
That sounds reasonable.
I would expect this gets implemented as a wrapper on top of FlightClient, since
that logic could be useful in contexts beyond Flight SQL. Though then we need
to do work to extract an interface out of FlightClient in C++/Java (unless the
intent is that FlightSqlClient wil
So after your reply we discussed it and came up with a suggestion and a
question.
First, we would like to know where is the
best place to implement it, in FlightClient itself or in the
FlightSQLClient.
Our idea for implementing it is to create a new class
"RetryableFlightClient" which will
wrap
For gRPC, in theory, you can get UNAUTHENTICATED at any time, including after
the client has gotten some results.
If you need to retry calls, and you want to do it transparently, you'd need a
gRPC interceptor, yes. (The Flight middleware is not powerful enough to do
that.) But that should be se
