12 Replies Latest reply on Mar 16, 2015 10:30 AM by Kiran Srimat Kandala

    Can MDB deployment fail on missing Queue - memory problems on missing queue and MDB deployment

    Markus Falk Newbie



      right now, I'm facing a heap space problem caused by a deployment of an MDB where the queue is missing. I'm running on JBoss 7.2.0 Alpha release with HornetQ 2.3.0.CR1 included.


      The details:

      I'm deploying and MBD where the queue is missing and it succeeds.


      The serverlog only logs:

      2014-01-22 10:48:17,748 INFO  [vm-mfalk-5660] [org.hornetq.ra] (default-threads - 2) HQ151001: awaiting topic/queue creation queue/GibtsNedQueue


      And one time:

      2014-01-22 10:48:19,765 INFO  [vm-mfalk-5660] [org.hornetq.ra] (default-threads - 2) HQ151002: Attempting to reconnect org.hornetq.ra.inflow.HornetQActivationSpec(ra=org.hornetq.ra.HornetQResourceAdapter@508cb3a8 destination=queue/GibtsNedQueue destinationType=javax.jms.Queue ack=Auto-acknowledge durable=false clientID=null user=null maxSession=15)



      The implementation of the HornetQActivation in the runs in its exception handling part (handleFailure(Throwable failure)), which tries until infinity (reconnectAttempts = -1 by default) to reconnect and logs the INFO mentioned above.

      In this exception handling there is again an exception handling included but no longer logged anymore because of the check '!(t instanceof HornetQNonExistentQueueException)'.


      There are some Infos logged out in DEBUG level and an exception logged out in TRACE level. I would like to post them too here, but I don't know how to format it correctly in some kind of scroll block and it would be too long :-(


      So now to my question:

      Is it possible to configure HornetQ to fail during deployment, when the queue doesn't exist?

      I looked into the properties of the connectors, connection-factories, pooled-connection-factories and HornetQ itself but couldn't find a property which fulfils my needs.


      Thx for you answer,



      PS: Some more infos to the memory leak:

      In a server having this problem, there are 278 Threads of HornetQ-remoting-threads-HornetQServerImp and 113 Threads of HornetQ-client-global-threads, just to give some numbers. Seems that the cleanup doesn't work correctly (at least in version 2.3.0.CR1). HornetQ components use approx. 70 % of the heap space. This will cause the CPU and LOAD of the whole machine to rise. The LOAD on some point quite heavily.