[
https://issues.apache.org/jira/browse/QPID-2694?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12885315#action_12885315
]
Marnie McCormack commented on QPID-2694:
Discussed on list/with Andrew how we
[
https://issues.apache.org/jira/browse/QPID-2694?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12883809#action_12883809
]
Marnie McCormack commented on QPID-2694:
Reviewed files, changes look ok - applied
Le 30/06/2010 09:20, Andrew Kennedy a écrit :
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?
I admit I don't remember seeing a unit test for a memory leak. This is
usually
Emmanuel Bourg wrote:
Le 30/06/2010 09:20, Andrew Kennedy a écrit :
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?
I admit I don't remember seeing a unit test for a memory leak.
I agree with Rafi.
Memory leaks are not the sort that could be verified with a unit test
that runs under a min.
You need to run for a reasonably long time to detect trends.
I used to have a nightly cron tasks that runs a producer consumer pair
with transactions etc for 10 hours and records memory
Marnie McCormack wrote:
How do we currently test that for various operations (like Session close)
the correct messages are dispatched i.e. so we avoid this case where the
close-ok didn't go ?
That was really what I was driving at on the test - obv we can stress
test/profile on a one off basis
