nats-io / nats-server / 8430925599 / 1
78%
main: 78%

DEFAULT BRANCH: main
Ran
Files 54
Run time 2s
Badge
Embed ▾
README BADGES
x

If you need to use a raster PNG badge, change the '.svg' to '.png' in the link

Markdown

Textile

RDoc

HTML

Rst
coverage: 85.214% (+0.1%) from 85.099%
8430925599.1

push

github

web-flow 
[FIXED] Possible memory leak due to connections not being released (#5244)

The main issue for router/gateway connections were that they would be
registered with the global account but never removed from there, which
would cause the connection to be retained. The memory leak was apparent
in one user setup with large amount of subscriptions that were
transfered to a slow gateway, causing accumulation of partial buffers
before the connection was dropped.

For gateway connections, we also needed to clean the outbound's map
since it can contain sublist referencing its own connection. Same for
subscriptions in c.subs.

Another found cause for retained connection is with leafnode where we
are using a subscription referencing the leafnode connection that was
globally registered in a global sublist but never removed.

Also the connection's c.out.sg (a `*Cond`) needed to be set to `nil`
when the connection is closed. Without that, it seems that the
connection would not be released (at least based on experimentation). We
now make sure that c.out.sg is not nil before sending a signal.

The bottom line is that it looks like having an object referencing
itself in some way, prevents the GC from releasing the object, even if
the "top level" object is no longer reachable. For instance, suppose
`obj.someField = obj` seem to prevent the GC from releasing `obj`, even
if `obj` itself is no longer referenced.

The original issue/PR (#5212) was simply cleaning the c.out.wnb, but the
way it was done was racy since c.out.wnb is used without lock in
flushOutbound. Once the retain/release issue is fixed, cleaning this
buffer is not really required (but good practice especially if not
running with GOMEMLIMIT), so we take care of cleaning this up, but under
the protection of the flushOutbound flag. If set, flushAndClose() will
not do the cleaning, flushOutbound will do it.

Relates to #5212

Signed-off-by: Ivan Kozlovic <ivan@synadia.com>

64545 of 75745 relevant lines covered (85.21%)

191660.45 hits per line

Source Files on job 8430925599.1