Hm.
It's not something I've ever had to do before, I think. Can anyone
help me out on how to write a unit test for a (fixed) memory leak in
Java?
I could just create 100K sessions on a connection, close them and say
that's all good, but that's just the happy path. It wouldn't really
be testing the failure case, as you can't expect to do this:
} catch (OuttOfMemoryError oome) {
fail("What does this program have in common with a sieve?");
}
If I start a child JVM with the -XX HeapDumpOnOOME option, and say
10Mb of heap, then run the number of sessions up as far as possible,
that could work. If there's no heap dump file, the test passes?
Or, I could monitor heap usage as I create the (non) leaky sessions,
and make sure the numbers balance out before and after closing a
session, and would also have to make sure GC has run, and so on. Not
exactly as below, but similar. I don't really like doing this sort of
thing in Java...
long free = Runtime.getRuntime().freeMemory();
if (free < HEAP_LIMIT_LWM) fail("Used too much memory");
So, what do people think would be the best and simplest way to test
this leak is fixed? Or am I over complicating this for myself before
I've had enough coffee?
Cheerz,
Andrew.
--
-- andrew d kennedy ? do not fold, bend, spindle, or mutilate ;
-- http://grkvlt.blogspot.com/ ? edinburgh : +44 7941 197 134 ;
On 30 Jun 2010, at 07:38, Marnie McCormack (JIRA) wrote:
[ https://issues.apache.org/jira/browse/QPID-2694?
page=com.atlassian.jira.plugin.system.issuetabpanels:comment-
tabpanel&focusedCommentId=12883809#action_12883809 ]
Marnie McCormack commented on QPID-2694:
----------------------------------------
Reviewed files, changes look ok - applied to branch. Please add a
test for this case, thanks.
Memory leak in 0-8/0-9 AMQSessions on channel close
---------------------------------------------------
Key: QPID-2694
URL: https://issues.apache.org/jira/browse/QPID-2694
Project: Qpid
Issue Type: Bug
Components: Java Broker
Affects Versions: 0.5, 0.6, 0.7
Reporter: Andrew Kennedy
Fix For: 0.5, 0.6, 0.7
Attachments: 0001-QPID-2694-Fix-channel-close-memory-
leak.patch
When closing a 0-8/0-9 AMQSession, the ChannelCloseOk returned by
the broker is not handled in the client, leading to a memory leak
with AMQProtocolSession objects being left. This is particularly
evident with frameworks like Mule which open a session per
connection.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
