Memory Leak for HTTP Server Controller

[phoenix6789]

Hi,

I've have spent the last few days trying to debug a suspected memory
leak in my traffic scripts. For my SIP-only UAC and UAS scenarios, I
found a simple solution to the problem I was having. By enabling the
printHeapUsageOnExit option I was able to quickly note that I had a
alot of persisting UdpSessions kicking around which led me to the fact
that I wasn't invalidating my sessions on all of my error paths. Now
for my SIP-only scenarios I no longer have runaway object creation and
the Ruby ObjectSpace & GC seems to be keeping up. Most of the time
the Ruby process is bounded to about 30 mb or so ...which is a lot
better than it was.

For my scenarios involving SIP and HTTP, I have an HTTP server
controller, and I seem to have a memory leak I can't resolve. It
seems even if I attempt to invalidate no longer needed HTTP sessions,
they are still living. At the end of all of my runs, I have several
thousand DetachedSession objects even though I have called
session.invalidate(true) on them. Is there a known bug with
invalidating HTTP sessions? Unfortunately, over a very short run of
traffic, my HTTP server controller can gobble 500 mb of memory and
most times, near the end of the run, has gobbled 1.6 gb before it
crashes.

Any ideas on things I could try to resolve this problem?

thanks,

Dave Adams.

[phoenix6789]

I simplified my scenario by simply setting up two controllers. An
HTTP Client and an HTTP server. I have the client sending the
server a single light-weight HTTP request, and the server answers back
with a HTTP 200 OK. Under load of 1 cps for 1000 calls I see the
HTTP client memory stay fairly balanced...but the HTTP server memory
grows and grows. Any ideas on things I could try to debug? Is there
a known issue with controllers acting as an HTTP server?

thanks,

Dave Adams.

[sharat mohan]

Hi Dave,

Could you please share your scripts and any logs that you have.

Regards

Sharat

--
You received this message because you are subscribed to the Google Groups "Sipper" group.
To post to this group, send email to sip...@googlegroups.com.
To unsubscribe from this group, send email to sipper+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/sipper?hl=en.

[phoenix6789]

Hi Sharat,

I sent you my scenario and logs to your gmail account.

regards,

Dave Adams.

> > sipper+un...@googlegroups.com<sipper%2Bunsu...@googlegroups.com>

[sharat mohan]

Hi Dave,

Thanks for your effort and in pointing out the problem.

I have submitted the fix for the memory leak problem (revision 240).

You can sync to the latest code or you can make changes to your local copy.

Comment out the line# 23 in "sipper_http_servlet.rb"

Regards

Sharat

To unsubscribe from this group, send email to sipper+un...@googlegroups.com.

[phoenix6789]

Thanks Sharat! I'll give your solution a try. I wasn't sure how
serious the problem was because I hadn't heard from you for a few
days. I was able to work around the problem myself -- but my solution
was different. I made a change to the same file but I changed the
WEBrick database manager from MemoryStore to NullStore and that
immediately reduced the memory profile by 40x and kept Ruby GC at a
normal level. Once I stabilize my scripts, I'll re-sync to the latest
code and hopefully I won't need my hacks anymore.

Dave Adams

On Feb 18, 6:46 am, sharat mohan <sharat.mo...@gmail.com> wrote:
> Hi Dave,
>

> > <sipper%2Bunsu...@googlegroups.com<sipper%252Bunsubscribe@googlegroups. com>