Ex: Fail-Fast persistent (database) storage ... ?

[Steven Premeau]

On Fri, Aug 30, 2024 at 8:00 PM Paul B. Henson <henson at cpp.edu> wrote:

> On Fri, Aug 30, 2024 at 01:19:23PM -0400, Steven Premeau via users wrote:
>
> > ... It seems my driver or connection manager remains hopeful that the
> > resource will return rather than return a failure, holding up the
> > sign-in process.
>
> What driver are you using?
>

I've tried a few combinations, but am currently using the current MariaDB
Connector/J release with its "internal pool" configuration.



>
> > Does anyone happen to have a MariaDB driver / connection manager
> > combination that "quickly knows when to give up"  along with any
> > configuration tips?
>
> I haven't played with it much myself, but the mariadb jdbc driver
> documents support for galera clusters, and even has a special
> galeraAllowedState option, so I would think it would work well in that
> environment. It allows either sequential "first listed first tried"
> access or load balanced access across all nodes.
>

Ultimately what I appear to be having problems with is getting it to
"give-up".

Even in what should be the ultimate in obvious failures -- TCP RST /
Connection Refusals -- the connection blocks for almost exactly 30s,
apparently waiting for the server (node) to return.

I've set the documented MariaDB connect and socket timeout to much less
than that, and the JDBCStorageService "transactionRetries" to 1.... with no
apparent change in timeout behavior.

For what my current use is (managing Warning Intercept notifications),
(re)showing the warning on DB failure is a more acceptable solution than
blocking access.  I was hoping that a StorageAwareCookieManager could be
the best of client-side and server-side tracking ... but it seems that all
the "good" of client side tracking is overshadowed by the delays (or
errors) experienced by the user when the DB connection fails.

Steve.

-- 
Steven Premeau, Director of Enterprise Systems Architecture & Administration
University of Maine System: Information Technology
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20240903/88646c25/attachment.htm>