Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

CPU Leak in botRateLimiter

See original GitHub issue

Yesterday, I put my JDA 3.0 version of ErisBot live for around 40 minutes. I did this to catch any errors pre-launch.

During the test I noticed my CPU was maxed out for no reason. I loaded up VisualVM and found com.neovisionaries.ws.client.WebSocketInputStream.readBytes() completely chewing on the CPU.

I did some further testing to then find net.dv8tion.jda.core.requests.ratelimit.botRateLimiter$Bucket.run() was also be doing the same (not in production, just testing)

In testing, I created a for loop and queued 50 messages which is what caused the ratelimiter to eat the cpu. It was eating around 20% of my overall CPU (i7-6700k) which shouldn’t even be possible for queuing 50 messages.

Here are some screenshots: http://i.imgur.com/VOXLLB7.png - Overall CPU usage http://i.imgur.com/4IJmwX4.png - Messages from the queue http://i.imgur.com/1KYIzim.png - The top CPU usages http://i.imgur.com/eWIISOe.png - JVM CPU Usage (Spikes are when the messages were sent) http://i.imgur.com/knr4K1F.png - Thread spike when flooding the channel (Can’t replicate, unsure what the cause of this was)

I would also like to note that I did the same test on another JDA bot, which is designed completely different due to it’s private use. I received the exact same results.