Transfer data via Plugin Messaging

Discussion in 'Spigot Plugin Development' started by TacoLover, Jun 6, 2016.

  1. Hello!

    I have a MySQL database to store player data for my servers. The servers are connected to a Bungee coord instance. I am using HikariCP to connect servers to the database from each spigot server. The way I have my plugin setup is to query the database when a player joins and update the database when a player leaves so I am not constantly updating/querying the database. BUT, instead of having hundreds of connections to the database for all my servers, I was wondering if it would be more efficient to have the Hikari CP on the Bungee coord instance and use the plugin Messaging channel to send the player data to certain servers when needed. This way the database does not have tons of connections to it and there would be no layovers (e.g. when a player leaves a server, plugin updates the database, but then gets immediately queried again when player joins a different server on the Bungee instance).

    Hopefully you understand my question!
    Thanks for any help!
  2. Plugin Messaging is a bit buggy, and sometimes it will not send the message, the two options I suggest are:
    • Sockets
    • Good MySQL practices
    Sockets are a bit advanced system, I never used it so I can't help you on that, google it and you will find something.

    Good MySQL practices:
    Don't constantly connect/disconnect, connect when the plugin loads and then just disconnect when the plugin disables.
    Use PreparedStatement, other methods can cause lag in the server, and, if you don't have a lot of RAM, it will be really annoying.
  3. I have never heard that plugin messaging is buggy, I have only heard that you can't send a message to a server without any players on it and vise versa, but the only time I would be sending a message is when a player is online on the target server. I could be wrong.

    But my main concern is having a lot of connections from every server on the network to the MySQL server because I am using a connection pool. I think the sql server would undergo some stress because of that but I don't know.

    Off-topic question: when you have one connection with a database and your plugin runs asynchronous an query every time a player joins, what would happen if 2 players join at the exact same time? The plugin would run a query for the first player, but while the querying is completing would the second player not receive their data because the connection is being used? Or would the second query just wait for the first async one to complete?

    Thanks for the help!
  4. I would highly recommend taking a look at Redis in your situation. It's really powerful when it comes to key-value storage.
    • Agree Agree x 2
  5. Okay thanks! I'll look into it.
    Another side-question. If I use one long-lived connection and I don't run any queries or updates for some time the connection will timeout. It is efficient to run some spam/useless queries to keep the connection alive?
  6. I think you answered your own question right there.
    If it doesn't do anything, you're just using up a CPU cycle for no reason at all.
  7. @TacoLover a connection pool on the Bukkit server should be fine, your database should be able to handle the connections.

    Moreover, you can configure the amount, so it won't use more than you tell it to.
    This is why you use a connection pool. You will have several connections at your disposal, being able to handle several concurrent requests at the same time (the amount depends on your pool configuration)

    Wasn't Redis more used for temporal data, caches, pubsub, etc, and not for long term persistency?
  8. It really depends on what the user actually wants. Yes, Redis is mainly used for the reasons you've said, but it also provides persistent storage.
    If the data that's being sent is just temporary I would use Redis.
    • Agree Agree x 2
  9. Okay thank you for the help! I think I am just going to use a CP with a small number of connections (<4 or so) on each spigot server.