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