I agree with David. The client and server classes provided by the Flight library have always been intended as low-level tools. So the intent is for developers to use these to create user-facing tools that handle the details that are particular to a certain server implementation.
On Tue, Nov 3, 2020 at 7:03 AM David Li <li.david...@gmail.com> wrote: > > I think in that case, you'd give users a wrapper around a > FlightClient, and not a FlightClient directly - after all, if you have > custom server-side resources to clean up, I'd assume you'd also want > higher-level operations than what FlightClient gives directly. > > Best, > David > > On 11/2/20, James Duong <jam...@bitquilltech.com> wrote: > > The concern I have about making this a custom action is that FlightClient > > (in Java) is a Closeable resource already. > > It's a bit unintuitive to require users to run an explicit cleanup > > operation, while also automating some of the clean-up > > as well. It seems error-prone. > > > > On Fri, Oct 30, 2020 at 3:56 PM Wes McKinney <wesmck...@gmail.com> wrote: > > > >> Do you need this beyond FlightSQL? Since any user/client interface to > >> a server is going to require some custom development anyway (just like > >> the server requires custom development), if there is a need to close > >> resources, it seems like this could be implemented by an action that > >> is specific to the particular client/server implementation (such as > >> FlightSQL). > >> > >> On Fri, Oct 30, 2020 at 4:43 PM Kyle Porter <ky...@bitquilltech.com> > >> wrote: > >> > > >> > Hi, > >> > > >> > Carrying on from this thread: > >> > > >> https://mail-archives.apache.org/mod_mbox/arrow-dev/202010.mbox/%3CCAJPUwMA25jprszWEsrL2zr0xz%3DgsqdB%3D_4jP06eG8S8b5--mdg%40mail.gmail.com%3E > >> > (apologies, as I was not a member of the list at the time of this > >> > thread > >> > starting and am unsure if it's possible to reply directly after the > >> fact), > >> > I think there are a few options we can use to manage session lifetimes. > >> > > >> > As Wes suggested, we could add some RPC calls, but given that > >> FlightServer > >> > (as I understand it) is meant to be stateless by default it seems odd > >> that > >> > we would elevate these to top-level RPC calls. > >> > > >> > An alternative would be to build on > >> > https://issues.apache.org/jira/browse/ARROW-10427 and, when using > >> session > >> > headers, to allow the specification of an optional close handler for > >> > the > >> > FlightServer. This would then add a "close" Action to the server which > >> > would invoke the closeHandler for release of the session resources. > >> > > >> > We would then maintain a clear distinction between stateless > >> FlightServers > >> > and those that opt into session headers where there may be state, and > >> > the > >> > ability to close would be restricted to when state is implied. > >> > > >> > Feedback on the idea would be appreciated. > >> > > >> > *Kyle Porter* > >> > > > > > > -- > > > > *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. > >
