Memory leak using Reuters RFA7.4.1.L1.win

What appears to be a memory leak using Reuters RFA7.4.1.L1.win.

The issue can be duplicated using the StarterConsumer Example program. We used
the VS100_Shared project. We are using RSSL. We set the \itemList configuration parameter
in the StarterConsumer.cfg file to a list of actively traded instruments:

\itemList = "GE,DIS,AAPL,HD,BAC,T,FCX"

We then start the Release_WIN32_VS100_Shared\StarterConsumer.exe application from the
command prompt and bring up task manager. The memory used by StarterConsumer continues
to grow and never stablizes or shrinks.

We also tried changing: void StarterConsumer::processEvent(const Event& event) so that
it does not call processOMMItemEvent(...) on the theory that this routine (or perhaps
one it calls, like the Decoder) wasleaking the memory.

#ifdef notdef
case OMMItemEventEnum:
  processOMMItemEvent(static_cast<const OMMItemEvent&>(event));
  break;
#endif

The process still leaked memory at the same rate. Note that the amount of memory leaked, and the speed at
which it is leaked is directly related to market activity. The more active the market (and
the instruments being watched), the faster the amount of memory used increases.

We also tried to change the message pool memory parameters from:

\Control\MessagePools\OMMItemEventPool\InitialSize  = 10000
\Control\MessagePools\OMMItemEventPool\Increment  = 10000
\Control\MessagePools\OMMItemEventPool\MaximumSize  = 0

to:

\Control\MessagePools\OMMItemEventPool\InitialSize  = 100
\Control\MessagePools\OMMItemEventPool\Increment  = 100
\Control\MessagePools\OMMItemEventPool\MaximumSize  = 100

This did not change the behavior..

Any help is appreciated.

Find more posts tagged with

trep

rfa

memory

rfa-api

Accepted answers

Jirapongse

I got the different result when running StarterConsumer
in RFA C++ 7.6.2.L1 package. I modified the code a bit. Instead of
decoding the data, I modified it to print the update rate that StarterConsumer could handle and retrieve per second.

...
	int		_updateCount;
	unsigned long long endTime;
...
 bool StarterConsumer::init()
{
	...
	_updateCount = 0;
	endTime = AppUtil::getCurrentTime();
	endTime += 1000;
...
}

void StarterConsumer::processMarketPriceResponse(const rfa::sessionLayer::OMMItemEvent& event, const RespMsg& respMsg)
{
	++_updateCount;
	unsigned long long currentTime = AppUtil::getCurrentTime();

	if (endTime <= currentTime)
	{
		RFA_String text("Response Rate: ", 0, false);
		text.append(_updateCount);
		text.append("\n");
		AppUtil::log(__LINE__, AppUtil::TRACE, text.c_str());
		endTime = currentTime + 1000;
		_updateCount = 0;
	}
	return;
…
}

I used the following configurations.

\Control\MessagePools\OMMItemEventPool\InitialSize     = 10000
\Control\MessagePools\OMMItemEventPool\Increment       = 10000
\Control\MessagePools\OMMItemEventPool\MaximumSize     = 0

I connected StarterConsumer to my provider so I could
control the update rate sent to the consumer. I have tested it with several
updates per second (100, 1000, 10000, and 100000). The result is shown below.

From the result, the memory usage is stable. StarterConsumer without
decoding can handle 100000 updates per second without memory growth.

Normally, the memory growth in RFA happens because the
application is a slow consumer. For example, if the application is able to
handle around hundreds of updates per second but the real update rate of all
subscribed items is more than thousands, the memory will definitely grow due to
the increasing numbers of unprocessed events in the event queue.

There are two ways to verify if the application is a slow
consumer.

Verify the number of updates per second that the
application can handle and compare to the real update rate for those items
Or, monitor the return value of EventQueue::dispatch()
method. A non-negative return value from dispatch() indicates an
estimate of the number of remaining events in the event queue or the event
queue group. However, applications should not rely on the exact value as it is
only an estimate

All comments

zoya faberov

Would suggest using a newer version of RFA; going with the latest, RFA 8, if possible. Many important fixes have been introduced to RFA in version 7.6 (please check with version READMEs for the specifics).

RFA 8 offers major new functionality, while incorporating fixes from the previous versions.

RFA before 7.6.2 will be obsolete this year (2016), please refer to:

https://community.developers.refinitiv.com/questions/6299/is-there-a-planed-obsolescence-for-the-rfa-c-74-an.html

sammy.li

I encounter this problem too. I try using 7.6.2 shared or static version. I still get this problem. I download the version 8, but this is only 64 bit version which I need to change a lot for my code. Please help if any work around solution for this. I am working on this problem for nearly 2 months and finally find out this is a bug from your api. Please help.

Jirapongse

...
	int		_updateCount;
	unsigned long long endTime;
...
 bool StarterConsumer::init()
{
	...
	_updateCount = 0;
	endTime = AppUtil::getCurrentTime();
	endTime += 1000;
...
}

void StarterConsumer::processMarketPriceResponse(const rfa::sessionLayer::OMMItemEvent& event, const RespMsg& respMsg)
{
	++_updateCount;
	unsigned long long currentTime = AppUtil::getCurrentTime();

	if (endTime <= currentTime)
	{
		RFA_String text("Response Rate: ", 0, false);
		text.append(_updateCount);
		text.append("\n");
		AppUtil::log(__LINE__, AppUtil::TRACE, text.c_str());
		endTime = currentTime + 1000;
		_updateCount = 0;
	}
	return;
…
}

I used the following configurations.

\Control\MessagePools\OMMItemEventPool\InitialSize     = 10000
\Control\MessagePools\OMMItemEventPool\Increment       = 10000
\Control\MessagePools\OMMItemEventPool\MaximumSize     = 0

From the result, the memory usage is stable. StarterConsumer without
decoding can handle 100000 updates per second without memory growth.

There are two ways to verify if the application is a slow
consumer.

Verify the number of updates per second that the
application can handle and compare to the real update rate for those items
Or, monitor the return value of EventQueue::dispatch()
method. A non-negative return value from dispatch() indicates an
estimate of the number of remaining events in the event queue or the event
queue group. However, applications should not rely on the exact value as it is
only an estimate

EXPLORE OUR SITES