[asterisk-dev] ARI leaking memory?

[Watson, Kenneth]

Hi,

We have been evaluating building some custom software on top of Asterisk 
12, interacting via the new REST interface.

Since this will likely be a fairly high-throughput system, part of our 
evaluations involved a simple continuous loop performing GET requests to 
various endpoints in order to determine ARI's reactions to a constant 
stream of requests.

While ARI does indeed perform admirably, we did note that Asterisk's 
memory usage climbs throughout the test run, and the memory used is 
never released. Essentially, if left long enough, it will consume all 
available memory on a system.

We've tested on two different installs, using the latest SVN checkouts 
of the Asterisk 12 branch (this issue seems persistent across all the 
builds we've done, so I doubt it's something introduced via any new ARI 
features in the latest commits). It's otherwise completely standard 
configuration-wise, with only ARI and AMI enabled.

The issue can be easily duplicated via a simple Javascript loop 
performing any sort of GET request. I can provide the script we used if 
required.

What we're interested in finding out at the moment is, is this a known 
issue (nothing like this on the issue tracker at the moment), and is 
this perhaps considered an "acceptable" leak at the moment, considering 
the apparent slow speed at which it allocates memory (although it seems 
related to the size of the GET response - getting a list of existing 
bridges does it faster than an empty list of bridges), or do you suppose 
have we configured something wrong or not enabled something during our 
builds which might be causing this.


Unfortunately we do not really have the C skills in-house to track down 
or determine if/where the problems lie.


Regards,

  - Ken


Disclaimer

The information contained in this communication from the sender is confidential. It is intended solely for use by the recipient and others authorized to receive it. If you are not the recipient, you are hereby notified that any disclosure, copying, distribution or taking action in relation of the contents of this information is strictly prohibited and may be unlawful.

This email has been scanned for viruses and malware, and automatically archived by Mimecast SA (Pty) Ltd, an innovator in Software as a Service (SaaS) for business.  Mimecast Unified Email Management (UEM) offers email continuity, security, archiving and compliance with all current legislation.  To find out more, visit http://www.mimecast.co.za/uem.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20140109/4f0c392b/attachment-0001.html>