title: Fast JMS consuming with Spring JmsTemplate
body: <p>Let say we need to wait for any new messages available in the queue and process them imediatly. There is no requirenments related to transactional delivery.  </p>
  
  <p>While <code>JmsTemplate#receive</code> is quite handy, it is not quite clear for me if it is good in performance point of view; it appeared to be quite slow to be honest.  </p>
  
  <p>My guess is that it is slow because same initialization stuff is executed for each call. So I've made it next way, reusing connectin, destination and consumer which appeared to be much faster:  </p>
  
  <pre><code>private void startAsyncReceiver(final BlockingQueue&lt;String&gt; localQueue, final String remoteQueueName) {
      Thread t = new Thread(new Runnable() {
          @Override
          public void run() {
              jmsTemplate.execute(new SessionCallback&lt;Object&gt;() {
                  @Override
                  public Object doInJms(Session session) throws JMSException {
                      try {
                          Destination destination = destinationResolver.resolveDestinationName(session, remoteQueueName, false);
                          MessageConsumer consumer = session.createConsumer(destination);
                          sessionsStartedLatch.countDown();
                          while (true) {
                              Message message = consumer.receive(MAX_VALUE);
                              String body = (String) jmsTemplate.getMessageConverter().fromMessage(message);
                              localQueue.put(body);
                          }
                      } catch (InterruptedException e) {
                          return null;
                      }
                  }
              }, true);
          }
      }, remoteQueueName + "-Receiver");
      t.setDaemon(true);
      t.start();
  }
  </code></pre>
  
  <p><strong>Q1</strong>: Any idea why <code>JmsTemplate#receive</code> showed worse performabce result for the same algorithm? Am I missing something?<br>
  <strong>Q2</strong>: Can you see any potential issues with current implementation?</p>