Currently JDA requires all guilds and all of the associated entities to be loaded before starting to fire events. This has serious effects as entire shards can get stuck on a single guild refusing to connect to the gateway. In addition to that JDA can have serious cache issues during outages that can lead to memory issues due to duplicated cache entries that don't get removed.
- [x] Guilds should not prevent startup
- [x] Events should fire when all required entities are loaded
- [x] Cache should be aware of duplicates
- [x] Properly handle unavailability
We have ideas of adding a GuildReadyEvent in addition to ReadyEvent which would be useful to allow events to fire even if not all guilds are ready yet. The ReadyEvent would be fired when all guilds have been initialized, however events may already have fired for them.
I will redirect the issue traffic of #625 / #602 / #512 to this issue because they are closely related to one-another but I will keep them open for now.
As I don't have a lot of free time at the moment, I cannot give any ETA on when I will find time to work on these proposals. This most likely requires a rewrite of JDA internals.
MinnDevelopment
All 5 comments
The current handling has a memory leak in EntityBuilder#cachedGuildJsons during Discord outages, where a first pass occurs but never a second pass.
Frederikam
on 25 May 2018
I've started planning how the new init system should be setup.
The first issue I want to tackle is that we have the logic for setting up the session split across the library in several different classes. I believe it would be sensible to focus all of the setup logic for guilds into a single controller (GuildSetupManager or similar). This manager would then be the central facility to handle the setup for each guild.
Currently I believe this is the list of things that would need to rely on the new manager system:
- GuildLock
- EntityBuilder
- ReadyHandler
- GuildMemberChunkHandler
- GuildCreateHandler
- GuildDeleteHandler
All of these classes should instead of keeping their own cache use the new manager system and just pass information to it. The manager system would then advance the setup for the guild and decide if it is ready for usage.
For example:
- ReadyHandler receives guilds
- The guilds are passed to GuildSetupManager
- GuildCreateHandler receives guild data
- The guild is updated in the GuildSetupManager
- GuildSetupManager decides if it should start chunking
...
The logic here is not really planned, I just want to set an example on how it would work differently to the current system.
This way we have a codebase that can easily be found and understood by a contributor, rather than a complex and laid out system which spans across the api. Additionally we can change how the logic works and possibly allow events to be fired before _all_ guilds are ready.
MinnDevelopment
on 5 Jul 2018
This proposal is currently being worked on in experimental/guild-setup
MinnDevelopment
on 7 Jul 2018
The new system will be included in v3.8.0
MinnDevelopment
on 2 Sep 2018
I am so hype for the guild setup rewrite to go live.
DV8FromTheWorld
on 7 Sep 2018
Related issues
stefaandevylder
路
5Comments
Bungeefan
路
6Comments
ExpDev07
路
6Comments
Frederikam
路
3Comments
liovy
路
3Comments
Most helpful comment
I've started planning how the new init system should be setup.
The first issue I want to tackle is that we have the logic for setting up the session split across the library in several different classes. I believe it would be sensible to focus all of the setup logic for guilds into a single controller (GuildSetupManager or similar). This manager would then be the central facility to handle the setup for each guild.
Currently I believe this is the list of things that would need to rely on the new manager system:
All of these classes should instead of keeping their own cache use the new manager system and just pass information to it. The manager system would then advance the setup for the guild and decide if it is ready for usage.
For example:
...
This way we have a codebase that can easily be found and understood by a contributor, rather than a complex and laid out system which spans across the api. Additionally we can change how the logic works and possibly allow events to be fired before _all_ guilds are ready.