Memory management and saving to redis not working

[richard-webb-dev]

del not guaranteed to be called ever. Needs to be removed in favour of context managers

save() calls put in del as a backup, but manual calls should still be used when object is changed

atexits looked at and it's a no go.

[richard-webb-dev]

Related issue - https://github.com/Jaeger2305/werewolves-site/issues/9

Also issues with Player instantiation causing multiple objects with same p_id. Not cool.

[richard-webb-dev]

On initialisation of a Game() or Player() (or anything else that needs to be retained), I should search an object pool to check if it already exists, then return a reference to that object, instead of recreating from scratch.

Or just reference the object pool each time I need to create a player (this could have functions for extract, create, delete etc.)

[richard-webb-dev]

Here's the issue (and the associated game reference in Player().join_game()). Found in characters.py line 40sh.

    def attacked_by_werewolves(self):
        self.state = "dead"
        # returning an even here doesn't work yet. self.game isn't referenced properly
        return event.EventFactory.create_event("dying", self.game)

Inspect module could be useful for tracking down memory leaks. https://docs.python.org/3/library/inspect.html.

Also see: http://mg.pov.lt/blog/python-object-graphs.html

To solve this problem, it's fairly simple: replace all reference to Game() with a g_id. Then instantiate the Game() every time you need to use its functions, but never storing the Game object outside of its single use thing. Locks must be implemented when altering (equivalent to transactions)

The theory is that instantiating the game (from Redis) would be quick, and makes the system more atomic with one central store that can then be manipulated or saved to a more permanent database.

[richard-webb-dev]

https://docs.python.org/3/library/weakref.html

An alternative or accompaniment for if initialising a game is a pretty costly operation, and if many operations are to be performed by a character successively to prevent frequent rapid initialisations.

I like this method, but would make bug tracking/memory leaks pretty awkward. Maybe with lots of logging.

[richard-webb-dev]

inspect was a no go. Trying pympler/muppy instead: https://pythonhosted.org/Pympler/#download

Might be an issue with the python environment setup in visual studio.

[richard-webb-dev]

Muppy working.

Derefenced event file, but issues now when testing game.

Make sure game is saved whenever it could be re-referenced. Technically, Game doesn't need to lose its object references, but i think it'd be a lot clearer if it follows the same rule as everyone else. Ends up with messy code, but no memory leaks :/

[richard-webb-dev]

calls to save() need to be very carefully looked at. Any tiny change to a Game attributes must be saved otherwise they can be overwritten. This is probably a symptom of poor methods! Every attribute should be set via a method, which will then call save as appropriate.

This is manifesting as a bug in the event loop (unable to archive an event).

[richard-webb-dev]

Not loading events properly. (creating game from g_id results in event with autogenerated id)

[richard-webb-dev]

remove_timeout not working with passed in parameter for some reason.

[richard-webb-dev]

Useful thread for memory leaks. Issue has been solved by removing the use of objects. Whenever object functionality is required, the object should be initialised using its id. This calls to redis, then "commits" those changes using the objects .save() function.

This created a number of issues around how events were executed and managed. These are now (hopefully) fixed.