1 Reply Latest reply on Jun 14, 2017 9:29 AM by Justin Bertram

    Wildfly 10 - (JMS) Whats the implications of creating tons of queue with Session.createQueue(..) with same queueName?

    dbdbdb dbdbdb Newbie

      We have a app thats uses JMS in a wrong way.

      This application creates a new Queue for every single new message when publishing it.

      For every publish, creates a new Queue with Session.createQueue. The queueName parameter is always the same.

       

      Some days we publish about 15k messages. So, 15k new queues. Consuming with a MDB.

      Sometimes our server's CPU rapidly goes 100% and we don't know why. In the logs, the most common log are timeout for getting a new JMS Connection. The trasactions are in rollback state and the server goes down.

      Is this wrong use of JMS could be responsable for his CPU hog?

       

      We fix it today. Now we have a queue in standalone.xml and lookup it with JNDI and publishing the message with JMSContext (with try-with-resources).

       

      But now I'm curious to know the implications of this wrong approach.

      How Wildfly handle this queues? Are these queues "physical" like the JNDI ones?

       

      Thanks!

        • 1. Re: Wildfly 10 - (JMS) Whats the implications of creating tons of queue with Session.createQueue(..) with same queueName?
          Justin Bertram Master

          Is this wrong use of JMS could be responsable for his CPU hog?

          You don't provide enough information to say.

           

          My guess is that since you're invoking createQueue every time you send a message that you're also creating a new connection, session, and producer as well which is a significant anti-pattern.  Connections specifically are heavy and meant to be re-used whenever possible.

           

          In any event, to track down the cause of CPU spikes you'd need to gather thread dumps from the server at the time of the spike to see what's really going on.

           

          But now I'm curious to know the implications of this wrong approach.

          How Wildfly handle this queues? Are these queues "physical" like the JNDI ones?

          As the JavaDoc for Session.createQueue (which you linked) states, "Note that this method simply creates an object that encapsulates the name of a queue. It does not create the physical queue in the JMS provider."  The Artemis client will also perform a query so that if the name of the queue which is passed to createQueue does not physically exist on the server a JMSException will be thrown.  This query is probably less costly than performing a JNDI lookup because a JNDI lookup needs its own connection (which you're probably creating every time you do a look-up).