Thanks Wes & David, much appreciated for the feedback. *Kyle Porter* CEO Bit Quill Technologies Inc. Office: +1.778.331.3355 | Direct: +1.604.441.7318 | ky...@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. > > From: Wes McKinney <wesmck...@gmail.com> > Date: Tue, Nov 3, 2020 at 9:42 AM > Subject: Re: Closing of Server Resources > To: dev <dev@arrow.apache.org> > > > 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. > > > >
