JDA
JDA copied to clipboard
Allow to disable channel cache by type
Pull Request Etiquette
- [x] I have checked the PRs for upcoming features/bug fixes.
- [x] I have read the contributing guidelines.
Changes
- [x] Internal code
- [ ] Library interface (affecting end-user code)
- [ ] Documentation
- [ ] Other: _____
Closes Issue: NaN
Description
You can disable cache for channels like Category or VoiceChannel which will reduce the memory footprint for bots that don't need these channel types for anything. This will not change existing behavior unless people use setDisabledCacheFlags(EnumSet.allOf(CacheFlag.class)) or similar.
This is going to cause a backup of cached events for channels that are not created due to their cacheflag being disabled https://github.com/DV8FromTheWorld/JDA/blob/459a19aa2b5fa90ed3eb4e0509a5f6502b5d35da/src/main/java/net/dv8tion/jda/internal/handle/MessageCreateHandler.java#L68
That isn't an issue because we have a limit to the number of cached events:
public static final long TIMEOUT_AMOUNT = 100;
https://github.com/DV8FromTheWorld/JDA/blob/6ba908ca54b1888211ffa754aa73098c3e77c0fd/src/main/java/net/dv8tion/jda/internal/handle/EventCache.java#L40
https://github.com/DV8FromTheWorld/JDA/blob/6ba908ca54b1888211ffa754aa73098c3e77c0fd/src/main/java/net/dv8tion/jda/internal/requests/WebSocketClient.java#L916
Even with the timeout stuff, isn't this gonna result in messages being printed about "a large amount of events being cached?"
No there are no warnings about the event cache.
It's been a while since this PR was created. Might need to look at the implications of the
.enableCachecalls increateLightandcreateDefault.Otherwise, looks good. Lets get it in.
it should probably wait for stage channels support to be added
¯_(ツ)_/¯ No real strong reason to wait. We can always add support for the stage channels to CacheFlag when we add support for stage channels.
Is this being held off on until StageChannels are done @MinnDevelopment ?
I need to read myself back in on this PR and make some decisions regarding which events to cache and if we can be smarter about it.
These cache settings raise the question of how ThreadChannel#getParentChannel is currently implemented. Why does it use a cache getter instead of a field?