Bug 844470 - Java applications lose mysql db connectivity after several hours
Java applications lose mysql db connectivity after several hours
Status: CLOSED DUPLICATE of bug 841389
Product: OpenShift Origin
Classification: Red Hat
Component: Containers (Show other bugs)
Unspecified Unspecified
high Severity high
: ---
: ---
Assigned To: Dan Mace
libra bugs
: Triaged
Depends On:
  Show dependency treegraph
Reported: 2012-07-30 15:06 EDT by Nam Duong
Modified: 2015-05-14 18:57 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2012-07-31 10:23:05 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Nam Duong 2012-07-30 15:06:47 EDT
Description of problem:

There are a couple of threads where users are having mysql db connectivity hours after several hours.  See:

This is different from https://bugzilla.redhat.com/show_bug.cgi?id=841389 where scaled apps have db connectivity issues after a minute or so.
Comment 1 Dan Mace 2012-07-30 15:40:30 EDT

I still suspect this is the same issue as https://bugzilla.redhat.com/show_bug.cgi?id=841389. The current default MySQL datasource pool configuration we provide in standalone.xml does not configure a connection pool checkout test, and so even without scaling, the application will still attempt to use stale connections. The only difference is that when using an unscaled app, the connection TTLs are much longer by default, which explains why the apps are having trouble after hours rather than minutes in the scaling scenario (in which the TTL becomes 60 seconds due to the proxy sitting between the application and MySQL).

Users can work around this by configuring their app's standalone.xml to add the pool checkout configuration described in bug 841389.

This isn't a bug in OpenShift per say, but rather a poor default configuration we've provided. Ultimately users are responsible for configuring their connection managers to account for stale connections. Going forward we will provide better defaults.

I'll also respond with this information on the forum threads. Please revisit the issues in the context of this comment and let's talk about closing it as a duplicate of bug 841389.
Comment 2 Dan Mace 2012-07-30 15:51:38 EDT

I forgot to add: If users are experiencing MySQL connection loss even with the new configuration from 841389, please also consider another recently resolved bug:

Comment 3 Dan Mace 2012-07-31 10:23:05 EDT

*** This bug has been marked as a duplicate of bug 841389 ***

Note You need to log in before you can comment on or make changes to this bug.