Coherence Memory Leak of Infilter Objects When Extend Clients Connect and Disconnect (Doc ID 2220269.1)

Last updated on JULY 24, 2017

Applies to:

Oracle Coherence - Version 12.2.1.2.0 and later
Information in this document applies to any platform.

Symptoms

On : 12.2.1.2.0 version, Oracle Coherence

Memory leak in storage nodes when registering listeners via Extend Proxy WrapperCacheService.

When a new Extend* connection is established,  a corresponding listener and filter instances are created in the JVM of each storage node.
When the Extend* connection is terminated, the listener and filter instances *are not* dereferenced and so remain active in the JVM memory.

This eventually leads to a memory leak whereby the authorization listeners/filters consume a lot of the JVM memory and leaves not enough space for data storage.


1. After starting the Cache server and proxy server,

# Check live instances of 'com.tangosol.util.filter.Infilter'
jmap -histo:live 12948 | grep 'com.tangosol.util.filter.Infilter'

2. After the client connects, queries the data and disconnects, 

# Check live instances of 'com.tangosol.util.filter.Infilter'
jmap -histo:live 12948 | grep 'com.tangosol.util.filter.Infilter'
  1 24 com.tangosol.util.filter.InFilter

3. After the client connects again, queries the data and disconnects,

# Check live instances of 'com.tangosol.util.filter.Infilter'
jmap -histo:live 12948 | grep 'com.tangosol.util.filter.Infilter'
  2 48 com.tangosol.util.filter.InFilter

 

We can see that the number of instances of com.tangosol.util.filter.InFilter as the clients connects and disconnects. This indicates a memory leak of com.tangosol.util.filter.InFilter

Cause

Sign In with your My Oracle Support account

Don't have a My Oracle Support account? Click to get started

My Oracle Support provides customers with access to over a
Million Knowledge Articles and hundreds of Community platforms