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.

Reply via email to