Bukkit

I used to use LogBlock, which I liked a lot better mainly because it would work reliably even if the MySQL server wasn't super fast. LogBlock wouldn't let you rollback unless all the changes were written to the database. If I try to rollback with HawkEye before everything is written to the database, it will only rollback what is in the database. So if it takes 20 minutes to write a big explosion to the database, and I try a rollback a few minutes after the explosion happens, only a few blocks will be rolled back. Also, there's no way to check if there are pending changes.

LogBlock also is generally faster with the rollbacks. It won't freeze or crash the server. HawkEye will slow down or freeze the server when I try a rollback (even a relatively small one). Turning off delete after rollback helps a bit, but doesn't solve it completely.

I also like LogBlock's feature where it will write the pending database changes to a file if the server is going down before everything is done. Then when the server starts back up it will import the changes into the real database.

All the other big block logging plugins have gone down the hole, Guardian just isn't happening and the guy making LogBlock quit minecraft months ago. If I'm going to use HawkEye, I need it to work reliably even if the MySQL server isn't fast enough to take all the block changes at once in real time.

I will be looking into ways to optimize data storage and rollbacks in the near future.

Rollbacks/rebuilds have been modified a bit to limit the number of block changes per second so the server doesn't hang on big rollbacks, this will be included in the next release.

I will look into the database writing. What exactly do you mean by "there's no way to check if there are pending changes", do you want a command to check if any data is waiting to be written to the database?

@GoalieGuy6: Go

What I meant is; even when there are pending changes that are waiting to be written to the database, HawkEye will still do a rollback. So either a command to check if data is waiting to be written, or not allowing you to rollback until all data is written would be good.

LogBlock is a good example; when you try to do a rollback, it will tell you something like "Current queue size: X", and wait for the changes in the queue to be written to the database. Then when the changes are written, it will do the rollback.

The problem with doing rollbacks while there are still changes that haven't been written to the database is that when you rollback, only some of the changes will be rolled back. The rest that haven't yet been written won't be rolled back. For example, if there's a big fire or explosion on the server and I try to roll it back immediately after (before the changes have had a chance to be written to the database), only a small amount of the damage will be fixed. But if there was a command to check how much is waiting to be written, then I could use that to determine when it is safe to roll it back.

@GoalieGuy6: Go

Also, LogBlock will write the data to .sql files when it can't write it to the database (I think it will try to reconnect 10 times, then it will give up and put it in a file), which should probably be easy to implement with the mysql library. Just an idea to help you get started if you plan to implement that.

And when the server starts up the next time, LogBlock will look in the imports folder to see if there are any .sql files there, and it will import them to the database if it can.

Could this be causing hawkeye to not fully rollback multiple TnT explosions after they happen?

@Poopfish: Go

Certainly. When something like a big explosion or fire happens, it generates a lot of events in HawkEye. All of these events need to be written to the MySQL database. This can take time, and if you try to rollback before it's completely finished writing these to the database, it will only rollback what it had a chance to put in the database.

@Frogging101: Go

Sounds more like an issue that just is... props to the guys at Hawkeye if they can fix this.