My Oracle Support Banner

Charging Node Disconnected From Coherence Cluster But Process Is Still Running (Doc ID 2617093.1)

Last updated on DECEMBER 24, 2019

Applies to:

Oracle Communications BRM - Elastic Charging Engine - Version 11.3.0.6.0 and later
Information in this document applies to any platform.

Purpose

This note is to clarify some questions started from this observation:
An user recently received an alert that one of the charging nodes in the Disaster Recovery (DR) site was down. The process itself was running, but validating the log.coherence files for the affected node and other nodes, the messages seem to be matching what is reported by the alarm, as the logs of other Elastic Charging Server (ECS) indicate that a node disconnected, and then the cluster began to balance itself.

Of interest, the Garbage Collection (GC) log reports a full GC, which matches messages at the same time in other .log.coherence files, where they report a communication delay, as well as the time where the alert was raised.

Questions and Answers

To view full details, sign in with your My Oracle Support account.

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


In this Document
Purpose
Questions and Answers
 What could have caused the disconnection of the charging node from the cluster?
 What value should be for the MaxDirectMemorySize flag?
 
From a technical standpoint for the Charging Nodes, what exactly is the impact of the XX:MaxDirectMemorySize flag on the GC performance?
 Are these leaked segment messages on the log files the cause of the OOM exception? If not, could they be related?
 
What would be the purpose of adding the XX:MaxDirectMemorySize flag? Would it be to clean up these leaked segments?
References


My Oracle Support provides customers with access to over a million knowledge articles and a vibrant support community of peers and Oracle experts.