Report

I use mongodb for my Discord Bot, and just recently I had an issue where the the process running the driver would keep growing in memory size. This is a new problem as far as I can tell, or at least it hadn’t caused any issues before this. I looked at heap dumps, at it appears that there are many many objects and closures being created in a denque inside the ConnectionPool object. When looking at all of these objects inside the denque, it appears that every one only has one method, callback. This has another function in its context (like a scope from what I understand) called callback, which is an instance of callbackWithRetry. This chain continues far down the line until eventually the only things left inside its context are a resolve() and reject() method. There are thousands of these callback chains, each taking up around 4 KB of memory.

Tracing down the line, here’s what each level of callback nesting has that might help identify what each is called for.

1. Context has a this variable which is the ConnectionPool (seems to be the class scope)
2. Context has variables named topology, inTransaction, operation, and serverSelectionOptions
3. Context has variables named owner, session, and operation
4. Context has a this variable set to a Cursor, as well as a cursor variable also referencing the same Cursor. This context also has a callback as well as a queryCallback
5. Context has a variable self set to that same Cursor, with no other variables except callback
6. Context has variable cursor set to that same Cursor
7. Empty except for callback variable
8. Empty except for callback variable
9. Context has variables named owner, session, and operation (reference different variables than level 3)
10. Context has resolve and reject variables and nothing else (no callback variable, end of chain)

I do not know whether this is normal operation or not, but I found it very interesting that there would be such a long chain of callbacks, and so many of them all put together. The process just keeps taking memory until it’s killed. Does anyone have any insights as to what’s going on here, and how it can be mitigated or fixed?

Dependencies

• Driver connection pool and wait queue management

Acceptance Criteria

Implementation Requirements

• Identify where the denque is getting the object with a callback inserted from
• Reproduce case where denque grows unbounded

Testing Requirements

Documentation Requirements

• none

Follow Up Requirements

• Capture results in Community post