2 Replies Latest reply on Aug 21, 2015 6:49 PM by Clebert Suconic

    Possible Memory leak running clustered hornetQ with message redistribution

    Andrew Henderson Newbie



      While running HornetQ in a cluster with a message redistribution delay greater than zero we noticed a memory leak which caused the memory to be exhausted after a couple of weeks.


      Using heapdumps I found that ScheduledFutureTask objects were not being garbage collected. I traced the creation of the instances to the addRedistributor method within the QueueImpl.   The addRedistributor  method creates a new redistributorFuture and adds it to the futures collection.  If another call is made to this method the redistributorFuture is cancelled and removed from the collection of futures.

      A problem could occur if the cancelRedistributor method is called, as  the redistributorFeature is cancelled, but not removed from the collection.  Also the redistributorFeature variable is nulled which would prevent any calls to addRedistributor from removing the redistributor from the list.


      I think the redistributorFuture is not being removed from the requests collection if the cancelRedistributor method is called.  The reference from the collection prevents garbage collection and leaks memory. When I patched the cancelRedistributor method to remove the redistributor from the collection after cancelling it, the garbage collection was successful.


      At face value this looks like a bug, but it may be a mistake in our cluster configuration or use of queues.  Would you recommend reporting this as a bug?


      We are using version 2.3.20 of HornetQ imbedded in JBoss 6.3 EAP. The code appears to be the same in later versions.