Getting OutOfMemoryError while running stress test in MulticastRouterMule2136TestCase

Details

  • User impact:
    High
  • Similar Issues:
    None

Description

Running stress test in MulticastRouterMule2136TestCase causes OutOfMemoryError.

I've tried to run it with yourkit profiler, and found that problems are caused by MemoryPersistenceStrategy. It grows unlimitedly while running stress test because for some reason not every object gets removed from there.
Cleaning it explicitly in the test helps, but I suppose that's not a solution.

Issue Links

relates to

Improvement - An improvement or enhancement to an existing feature or task. MULE-774 Overhaul QueuePersistenceStrategies

  • Major - Major loss of function.
  • Open - The issue is open and ready for the assignee to start work on it.

Bug - A problem which impairs or prevents the functions of the product. MULE-2136 Intermittent Hanging with MulticastRouter, ObjectToXml

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Daniel Feist added a comment -

This test runs fine in maven but fails somewhere after 7000 iteration in both eclipse and idea due to OutOfMemoryError. This may be due to differences in test setup/teardown between IDE's and surefire.

Show
Daniel Feist added a comment - This test runs fine in maven but fails somewhere after 7000 iteration in both eclipse and idea due to OutOfMemoryError. This may be due to differences in test setup/teardown between IDE's and surefire.
Hide
Permalink
Ross Mason added a comment -

it's more likely because you have more memory allocated in you Eclipse JVM settings than in Maven

Show
Ross Mason added a comment - it's more likely because you have more memory allocated in you Eclipse JVM settings than in Maven
Hide
Permalink
Daniel Feist added a comment -

Yes quite likely. the other way around actually.

I just set priority to major, as this is a memory leak which has been confirmed by profiling.

Show
Daniel Feist added a comment - Yes quite likely. the other way around actually. I just set priority to major, as this is a memory leak which has been confirmed by profiling.
Hide
Permalink
Daniel Feist added a comment -

Found the problem!

This happens because this test has outbound vm endpoints which use event queuing but there are no consumer of these queues, i.e. these endpoints have no receivers and neither is receive()/request() used to pull events from the queue.

Not sure what the solution is to this, because in one sense what is happening is valid, rather than an unexpected memory leak due to a bug.

Show
Daniel Feist added a comment - Found the problem! This happens because this test has outbound vm endpoints which use event queuing but there are no consumer of these queues, i.e. these endpoints have no receivers and neither is receive()/request() used to pull events from the queue. Not sure what the solution is to this, because in one sense what is happening is valid, rather than an unexpected memory leak due to a bug.
Hide
Permalink
Daniel Feist added a comment -

Ross:
I think it would be consistent to apply a property similar to the ThreadingProfile.whenPoolExhausted., on the QueuingProfile we could have a similar setting that allows for - wait (with time out), Error and eat, Eat oldest, etc.

We should probably start firing ControlNotifications when queues and pools get exhausted and also allow users to set high water marks so that they get a warning control message when the water mark is reached.

Show
Daniel Feist added a comment - Ross: I think it would be consistent to apply a property similar to the ThreadingProfile.whenPoolExhausted., on the QueuingProfile we could have a similar setting that allows for - wait (with time out), Error and eat, Eat oldest, etc. We should probably start firing ControlNotifications when queues and pools get exhausted and also allow users to set high water marks so that they get a warning control message when the water mark is reached.

People

  • Assignee:
    Unassigned
    Reporter:
    Roman Urosov
Vote (0)
Watch (0)

Dates

  • Created:
    Updated: