Unable to perform database query.

[ZentixUA]

Hello. I discovered a funny thing - if no one joins to the server for a long time (more than 8 hours), then I get this error after players join:

[ForkJoinPool.commonPool-worker-21/WARN]: [VoidWhitelist] Unable to perform a database query: The last packet successfully received from the server was 38,857,955 milliseconds ago. The last packet sent successfully to the server was 38,857,955 milliseconds ago. is longer than the server configured value of 'wait_timeout'. You should consider either expiring and/or testing connection validity before use in your application, increasing the server configured values for client timeouts, or using the Connector/J connection property 'autoReconnect=true' to avoid this problem.

I have default mariadb options set.

[ZentixUA]

I think you need to do an automatic reconnection if I understand correctly

[voidpointer0x00]

Yep. That's weird that it's not in the plugin

[ZentixUA]

Lel 😆

[voidpointer0x00]

For now you can just manually reconnect (there's a command for that in case you changed database settings)

I'll get to it a few hours, it's a quick fix, just gotta change two lines like this one

VoidWhitelist/src/main/java/voidpointer/spigot/voidwhitelist/config/DbmsFactory.java

Line 77 in 7cb46fc

return format("jdbc:mysql://%s:%d/%s", host, port != -1 ? port : MYSQL_PORT, database);

[voidpointer0x00]

Just fixed the code, I'm going to run two servers hopefully for about 12 hours — one running old 0.9.1 and the other one running 0.9.2 whitelist, if the issue won't reproduce I'll merge fix and release it. You can download the new 0.9.2 at tag v0.9.2-unstable

[ZentixUA]

In older version plugin was disabled due to inactivity in mariadb/mysql

for testing, you can change mariadb's wait_timeout to a small value, like 60 (seconds). I miss your time, heh

[voidpointer0x00]

Thanks, I didn't even consider changing mariadb setting lol 🤣

[ZentixUA]

hahah, lol

[ZentixUA]

It seems the problem is still there. Last build

[VoidWhitelist] Unable to perform a database query: The last packet successfully received from the server was 71 668 milliseconds ago. The last packet sent successfully to the server was 71 668 milliseconds ago. is longer than the server configured value of 'wait_timeout'. You should consider either expiring and/or testing connection validity before use in your application, increasing the server configured values for client timeouts, or using the Connector/J connection property 'autoReconnect=true' to avoid this problem.
[17:39:39 INFO]: Disconnecting com.mojang.authlib.GameProfile@42d74db8[id=8f36620b-0a47-3fea-924f-40399aac3be4,name=Genife,properties={},legacy=false] (/91.224.96.197:42436): Вас нет в whitelist.
[17:39:39 INFO]: com.mojang.authlib.GameProfile@42d74db8[id=8f36620b-0a47-3fea-924f-40399aac3be4,name=Genife,properties={},legacy=false] (/91.224.96.197:42436) lost connection: Вас нет в whitelist.

Hmm, if the player tries to reconnect to the server, everything will be fine

[ZentixUA]

(mariadb commands)

SET GLOBAL wait_timeout=60;
SET SESSION wait_timeout=60;

[voidpointer0x00]

So does it fix itself even though it fails for the first time? Weird

Hmm, if the player tries to reconnect to the server, everything will be fine

[voidpointer0x00]

So does it fix itself even though it fails for the first time? Weird

Yep, that seems to be the case, just tested both versions. I'll look into other methods of fixing it, the most undesirable is to automatically initiate reconnection to the database in case of an error directly in the code, but it would require some architectural changes to codebase to make it look at least decent. What I'm thinking is, perhaps, a connection poll also might fix the issue

All in all, I think the current state is satisfactory: retrying to connect or just typing a command for the second time is not a big deal. And as long as there's a player online, the plugin will keep running sync tasks to SQL server every N (30 by default) minutes, which will keep the connection running.

[voidpointer0x00]

Fixed with PR #15, release page.

There will be no need to reuse the command/reconnect to the server, the plugin will automatically try to reestablish database connection.