After opening questions, dashboards that idled for some hours we get errors, e.g. unexpected end of stream, read 0 bytes from 7

these errors stream, SQLNonTransientConnectionException we get after opening questions that have not been loaded for some hoursare a kind of annoying showstopper and makes the otherwise great metabase software look bad.

We hope that using the information above you can reproduce the issue e.g. setup a similar test environment to debug the issues.

Does anyone have ideas how to fix this or can anyone reproduce and debug this issue on a test system? Would be helpful, we can’t work well with Metabase if it has issues with core functions like it does for us and other people!

System info:

Version of Metabase? (preferably "Diagnostic Info" from Admin > Troubleshooting)

0.33.6

Version of MySQL/MariaDB? Output from Metabase Native query:
SELECT @@version;

5.7.28-1

Output from Metabase Native query:
SHOW VARIABLES LIKE "%timeout%";

delayed_insert_timeout
300
have_statement_timeout
YES
innodb_flush_log_at_timeout
1
innodb_lock_wait_timeout
50
innodb_rollback_on_timeout
OFF
interactive_timeout
28800
lock_wait_timeout
31536000
net_read_timeout
30
net_write_timeout
60
rpl_stop_slave_timeout
31536000
slave_net_timeout
60
wait_timeout
14400"

Are you using any Connection String parameters (Admin > Databases > mysql/mariadb)?

sessionVariables=wait_timeout=14400&collation=utf8mb4_unicode_ci

How is your MySQL/MariaDB connected to Metabase? localhost, local network, SSH tunnel, ...? Are you using TLS or other connection encryption?

Right now using a SSH tunnel, we tried without the SSH tunnel (Directly to the database on localhost) but it behaved very similar, sometimes the mentioned errors when trying to open charts. About encryption I’m not sure, we didn’t activate anything special maybe it’s on by default.

Diagnostic Info

{
“browser-info”: {
“language”: “de”,
“platform”: “Win32”,
“userAgent”: “Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:71.0) Gecko/20100101 Firefox/71.0”,
“vendor”: “”
},
“system-info”: {
“java.runtime.name”: “OpenJDK Runtime Environment”,
“java.runtime.version”: “1.8.0_232-8u232-b09-1~deb9u1-b09”,
“java.vendor”: “Oracle Corporation”,
“java.vendor.url”: “http://java.oracle.com/”,
“java.version”: “1.8.0_232”,
“java.vm.name”: “OpenJDK 64-Bit Server VM”,
“java.vm.version”: “25.232-b09”,
“os.name”: “Linux”,
“os.version”: “4.9.0-11-amd64”,
“user.language”: “en”,
“user.timezone”: “Europe/Berlin”
},
“metabase-info”: {
“databases”: [
“mysql”
],
“hosting-env”: “unknown”,
“application-database”: “mysql”,
“run-mode”: “prod”,
“version”: {
“tag”: “v0.33.6”,
“date”: “2019-11-19”,
“branch”: “release-0.33.x”,
“hash”: “be1e0e1”
},
“settings”: {
“report-timezone”: “Europe/Berlin”
}
}
}

Hi @w92

  1. So you are running Metabase and MySQL on the same machine/container/OS? Meaning that you connect to MySQL in Metabase via localhost:3306? If yes, then there’s no reason to run a SSH tunnel.
  2. What is the reason for wait_timeout=14400? Was it to try to fix this issue? Have you tried other values? The default is 28800
  3. Which MySQL configurations have you made that are different from the defaults of 5.7.28?
  4. Which OS are you using? cat /etc/os-release

Just for reference, this is topic is for troubleshooting, there’s an issue open about it too:
https://github.com/metabase/metabase/issues/9885

  1. We observed the SSH tunnel makes it a bit more stable so we left it like that, we know in theory the tunnel is not needed.
  2. I changed it using the connection string now to 28800, serverside we can’t change.
  3. It’s a managed server but all other apps we use work fine.
  4. uname-a output: 4.9.0-11-amd64 #1 SMP Debian 4.9.189-3+deb9u1 (2019-09-20) x86_64 GNU/Linux

My guess is there are issues in the mysql adapter or metabase since many other users had the same issue as we can see on your github link above.

Before we make too many wild guesses @flamber please try to see of on the github anyone can let you debug the issue on a live server, we can’t for security/privacy reasons.

@w92
3. Okay, but that sounds like MySQL is not running on the same machine/container as Metabase, which means it’s not localhost and you input some IP-address in Metabase’s Admin > Database.
4. The uname -a only outputs the kernel, not the OS or version. Though it seems like it’s some flavor of Debian.

Almost no-one allows access to their data - for good reasons. And there hasn’t been any reports since 0.33.4, beside you, which is why I think the issue is specific to your setup.

@flamber : MySQL & Metabase run on the same machine, we are sure because it’s 1 physical server.

On Github I tagged multiple people, I hope one of them responds to ensure us I’m not the only installation with this specific isse of questions failing after idling for some hours.