Async & Mercury Changes

[suirad]

• Adds new async methods for most db calls that return void.
• Changes internal use of most(where appropriately applicable) db calls to use new async methods.
• Added/changes mercury messaging to apply changes directly to cache, instead of forcing one(or many) db hits due to recaching.
• Changed many group related methods to have alternate calls that take a boolean determining whether or not the call will modify the db, or only the local cache. Defaulting to true, preserving existing call-sites.
• Standardized mercury access and plugin checks. Also localizing pretty much all mercury messaging to sites that trigger db events, essentially binding the two. So you can reliably expect that, if you look at places where the db is modified, you can expect a mercury message there, as the db change would only apply at the source server of the change.

[CivcraftBot]

Can one of the admins verify this patch? Type 'ok to test' to test.

[Maxopoly]

Looks good overall, but I think it would be a lot better if all mercury messages sent were together in one MercuryManager class. Right now they are spread out all over the place and that makes debugging them very hard.

[suirad]

You should elaborate on that suggestion. The mercury parts aren't much different then how they were previously. Is that something that should delay this pull?

[Maxopoly]

So my concern with the mercury messages is just that its very hard to debug them if they are all over the place. For normal function I can easily look up where they are called, but for Mercury messages I cant, so having all messages being sent in a single class makes things a lot easier and cleaner imo. If Dan disagrees with this opinion, just go ahead and ignore me

[ProgrammerDan]

Ok, I've reviewed. Sadly this PR is not ready for inclusion. Some of the issues are Namelayer's and not the fault of this Pull, and if it were those issues alone I would merge it now. However, some other issues do remain with this PR itself, and those need to be resolved or clarified before we can proceed.

[suirad]

Added another commit, correcting review above. Please review.

[ttk2]

bump, whats the status of this?

[ttk2]

soo shards are crashing and we need these fixes, progress?

[ProgrammerDan]

i'm a bit gun-shy after our last batch of async changes caused enormous duplication problems....

was namelayer the cause of the crash?

[Maxopoly]

Yes, group creation took too long

[suirad]

Well after our discussions Dan, most of my async changes add capability, but are not in use. As in it will have the capability if we find good places that need it, but it's not being used anywhere in the codebase. Merging in its current state will primarily change how mercury messages are handled as each message modifies the cache directly instead of forcing recache from the db for every little change, across every shard.

Really the only thing left for this is a db upgrade to strip pipe chars from group names. I won't have time to hack on it till tomorrow, unless someone else wants wants to take the helm I'd appreciate it ;).

On Sat, Aug 20, 2016, 10:21 PM Maxopoly notifications@github.com wrote:

Yes, group creation took too long

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/Civcraft/NameLayer/pull/212#issuecomment-241236657, or mute the thread https://github.com/notifications/unsubscribe-auth/AIZCbdNOxH7s2DRNE7wjZZFD4Ji8zfByks5qh8QkgaJpZM4JeaYL .

[ttk2]

Is the encoding ASSCI? if its Unicode then I think we could find a much better char than | to use.

But I don't care that much, even if we break existing groups with | in them although an upgrade path that strips all group names of | would be great.

[ProgrammerDan]

Something went wrong here

[ProgrammerDan]

Note to future: use git rebase -i master where master is a clean checkout of remote civcraft's master branch. This will recreate your commit nodes, yes, but cleanly; so that history is preserved as linear and more useful then the commitspam that happens if you begin to multiply merge master into a branch that was created some time ago.

Or better as ttk2 suggested use git rebase -i origin/master assuming origin points to this repository :)