[
https://issues.apache.org/jira/browse/CALCITE-1350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15418083#comment-15418083
]
Julian Hyde commented on CALCITE-1350:
--------------------------------------
Maybe. But what if {{openConnection}} got part way through? Which call is
responsible for clean-up?
It seems clear that to be robust, {{closeConnection}} should be idempotent. So
can't we use that robustness, and call it when it isn't clear whether
{{openConnection}} succeeded? It should (at the very least) do no harm when
called on a connection that wasn't fully initialized.
And what about if {{openConnection}} succeeded, but wasn't able to communicate
its successful result back?
> Avoid closeConnection when openConnection doesn't finish/succeed
> ----------------------------------------------------------------
>
> Key: CALCITE-1350
> URL: https://issues.apache.org/jira/browse/CALCITE-1350
> Project: Calcite
> Issue Type: Improvement
> Components: avatica
> Reporter: Josh Elser
> Assignee: Josh Elser
> Fix For: avatica-1.9.0
>
>
> I've noticed during testing of Avatica, often times when SPNEGO
> authentication is misconfigured, the client will get stuck in
> openConnection().
> If we consider sqlline and the user control-C's it, sqlline will try to close
> the driver as well which would do a closeConnection() (which would also
> obviously fail).
> I believe we should be able to short-circuit the the closeConnection() when
> we know that the openConnection() didn't succeed properly.
> Another scenario is when the Avatica server is down. openConnection will
> fail, but we'll still attempt the closeConnection on exit.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
