[jira] [Closed] (TINKERPOP-2813) Improve driver usability for cases where NoHostAvailableException is currently thrown

["Stephen Mallette (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/TINKERPOP-2813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stephen Mallette closed TINKERPOP-2813.
---------------------------------------
    Fix Version/s: 3.7.0
                   3.6.2
                   3.5.5
       Resolution: Done

> Improve driver usability for cases where NoHostAvailableException is currently thrown
> -------------------------------------------------------------------------------------
>
>                 Key: TINKERPOP-2813
>                 URL: https://issues.apache.org/jira/browse/TINKERPOP-2813
>             Project: TinkerPop
>          Issue Type: Improvement
>          Components: driver
>    Affects Versions: 3.5.4
>            Reporter: Stephen Mallette
>            Assignee: Stephen Mallette
>            Priority: Blocker
>             Fix For: 3.7.0, 3.6.2, 3.5.5
>
>
> A {{NoHostAvailableException}} occurs in two cases:
> 1. where the {{Client}} is initialized and a failure occurs on all {{Host}} instances configured
> 2. when the {{Client}} attempts to {{chooseConnection()}} to send a request and all {{Host}} instances configured are marked unavailable.
> In the first case, you can get a cause for the failure which is helpful, but the inadequacy is that you only get the failure of the first {{Host}} to cause a problem. The second case is a bit worse because there you get no cause in the exception and it's a "fast fail" in that as soon as the request is sent there is no pause to see if the {{Host}} comes back online. Moreover, a {{Host}} can be marked for failure for the infraction of just a single {{Connection}} that may have just encountered a intermittent network issue, thus quite quickly killing the entire {{ConnectionPool}} and turning 100s or requests per second into 100s of {{NoHostAvailableException}} per second. Note that you can also get an infraction for the pool just being overloaded with requests which may signal that either the pool or server not being sized right for the current workload - in either case, the {{NoHostAvailableException}} is a bit of a harsh way to deal with that and in any event doesn't quite give the user clues as to how to deal with it.
> All in all, this situation makes {{NoHostAvailableException}} hard to debug. This ticket is meant to help smooth some of these problems. Initial thoughts for improvements include better logging, ensuring that {{NoHostAvailableException}} is not thrown without a cause, preferring more specific exceptions in the fist place to {{NoHostAvailableException}}, getting rid of "fast fails" in favor of longer pauses to see if a host can recover and taking a softer stance on when a {{Host}} is actually considered "unavailable".
> Expecting to implement this without breaking API changes, though exceptions may shift around a bit, but will try to keep those to a minimum.
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)