search

ProxioDev / ValioBungee

Synchronize players data between BungeeCord / Velocity proxies
Eclipse Public License 1.0
202 stars 52 forks source link

Persistent random server id generation #5

Closed weihao closed 3 years ago

weihao commented 3 years ago

Summary

Implemented a random UUID generation for empty server ids a few weeks ago, and I saw the limework fork has implemented a UUID generation too but it is not exactly what I wanted, so I want to share this PR with the maintainers.

Goal

This PR generates a random UUID when the initial config is empty, and then it saves the generated id to the config file.

Details

In the limework's implementation, if you always generate and append a random UUID on the flight, the heartbeat will not work.

Unlike limework's implementation, my UUID generation is persistent, and I use it for cloud deployments. Many instances copy from the same source for config files, generates random proxy ids, and save them. Persistency is required to recover from a crash as there are data in Redis linked to the server id.

ham1255 commented 3 years ago

Thanks for the pull request i admit away i have done it is bit weird

ham1255 commented 3 years ago

I found a bug somehow saving the config causes all comments to go away!

ham1255 commented 3 years ago

thanks for pull request again! merged

weihao commented 3 years ago

I found a bug somehow saving the config causes all comments to go away!

This is the expected behavior, yamlconfig loads yaml file into configuration, and all the comments are discarded. the changes you make are in memory and when write to disks, the comments are discarded because they were never loaded.

ham1255 commented 3 years ago

I found a bug somehow saving the config causes all comments to go away!

This is the expected behavior, yamlconfig loads yaml file into configuration, and all the comments are discarded. the changes you make are in memory and when write to disks, the comments are discarded because they were never loaded.

yeah thanks for telling since i think this was snake yaml limitation but it think writing our own yaml parser should do it.