Troubleshooting Connection Instability for Data Sources and/or Config DB

Data Sources

The primary method of rectifying connection issues of data sources is by enabling Volatile Data Sources.

What is Volatile Data Sources?

This is a configuration setting that tells Yellowfin to check all of the data source connections every 30 seconds and, if a connection is bad or closed, to reset that connection.

When do I need it?

As data sources frequently reside on servers physically separate from the primary Yellowfin installation, they can be subject to bad and unstable connections. This will typically be reflected in the yellowfin.log with errors similar to 

WARN (JDBCConnection:call) - Error occured when rolling back uncommited changes on connection: java.sql.SQLException: I/O Error: Connection reset
connection exception: connection does not exist

Or within the source.log files with similar correlated errors:

Network error IOException: Connection refused: connect
Connection object is closed

Note that there are many more errors that signify the need for this setting. If you are having problems that you think may be connection related, it may be worth enabling Volatile Data Sources.

Please reference the following Knowledge Base article to enable Volatile Data Sources.


Config DB

The primary means of rectifying Config DB connectivity issues is by enabling JDBC Verify.

How do I know if I need JDBC Verify?

Like any data source, the configuration database that Yellowfin runs on top of can experience connection problems. If you are experiencing "connection closed" or "connection dropped" errors in the JDBC.log file such as the error below, then it may be worth enabling JDBC Verify:

2017-04-05 19:08:38 WARN: Execution problem occurred when clearing warnings: java.util.concurrent.ExecutionException: com.microsoft.sqlserver.jdbc.SQLServerException: The connection is closed.

The JDBC Verify property tells Yellowfin to test the configuration data base connection frequently. If the connection is closed, Yellowfin will attempt to re-open it. This prevents you from having to manually reset this connection.

Please reference the following Knowledge Base article to enable JDBC Verify.

Note: if you're still having connectivity issues with your data source(s) after enabling Volatile Data Sources, connection instability between YF and the config db could be the actual cause, whereby data source instability is actually a symptom, at which point JDBC Verify should also be enabled.


Other Connection Instability Troubleshooting Methods

There are several other settings worth checking if you're still experiencing connection issues.

The following settings can be found under Admin Console > Data Sources > select data source > Connection Pool:

Max Connection Pool parameters - it is recommended this number being set to double the max concurrent users (Ex.: if during peak hours, there are 10 concurrent users, set this number to 20).

Secondary Pool - if you're experiencing issue sending out broadcasts and seeing timeout and/or connection closed errors, you may benefit from enabling a secondary connection pool, which is used specifically for running background tasks, including broadcasts.

Timeout - it may be worthwhile increasing this number slightly, assuming the connection is live and you're running resource intensive reports, though this would be a long time to wait for anything to load, so settings should be checked elsewhere first (Ref: Why is Yellowfin so Slow? and Performance Tuning and Monitoring). This setting is perhaps most useful being increased in the secondary pool for running background tasks such as broadcasts, where you wouldn't be noticing delays when actually using the application.

JVM Max Memory - Yellowfin has hard memory limits that are set in configuration files. The application will never allocate more memory once it reaches these limits, even if the server has more free memory. In some cases this can cause errors if Yellowfin needs more memory. It may be worth a slight boost in memory allocation if reports, dashboards, etc. are taking too long to run or taking so long they timeout. Please reference the following Knowledge Base article to increase JVM Max Memory settings: What is JVM Max Memory and Why Should I Care?

If after implementing all these suggestions you're still experiencing connection issues, it may be worth troubleshooting network connectivity issues from the client side.

If all else fails, please open a support ticket so we can assist further.

Is article helpful?