<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Aug 30, 2024 at 8:00 PM Paul B. Henson <<a href="mailto:henson@cpp.edu">henson@cpp.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Fri, Aug 30, 2024 at 01:19:23PM -0400, Steven Premeau via users wrote:<br>
<br>
> ... It seems my driver or connection manager remains hopeful that the<br>
> resource will return rather than return a failure, holding up the<br>
> sign-in process.<br>
<br>
What driver are you using?<br></blockquote><div><br></div><div>I've tried a few combinations, but am currently using the current MariaDB Connector/J release with its "internal pool" configuration.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> Does anyone happen to have a MariaDB driver / connection manager<br>
> combination that "quickly knows when to give up"  along with any<br>
> configuration tips?<br>
<br>
I haven't played with it much myself, but the mariadb jdbc driver<br>
documents support for galera clusters, and even has a special<br>
galeraAllowedState option, so I would think it would work well in that<br>
environment. It allows either sequential "first listed first tried"<br>
access or load balanced access across all nodes.<br></blockquote><div><br></div><div>Ultimately what I appear to be having problems with is getting it to "give-up". </div><div><br></div><div>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.</div><div><br></div><div>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. </div><div><br></div><div>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.</div><div><br></div><div>Steve.</div></div><div><br></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div style="color:rgb(136,136,136);font-size:12.8px">Steven Premeau, <span style="font-size:12.8px">Director of Enterprise Systems Architecture & Administration</span></div><div style="color:rgb(136,136,136);font-size:12.8px"><span style="font-size:12.8px">University of Maine System:</span> Information Technology</div><div style="color:rgb(136,136,136);font-size:12.8px"><br></div></div></div></div>