Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 7 Next »

 This page is under construction.

Advanced Features


  • JMSPool is an advanced JMS instance that allow multiple threading messaging for incoming and outgoing messages. It is built on Java 5 concurrency library and also utilize the ActiveMQ Pooled Connection Factory. So only Java 5 and AMQ are supported.
  • For simple JMS usage,
    • a new connection and session are created on every JMS execution block. Resources are closed after usage.
    • user has to manage threads and concurrency. Without special coding, messages are sent and received in a single connection and session. 
  • The currently JMSPool is fairly simple. It does not support features like transaction, connection recovery etc. If you need a full feature JMS Pooling product, you are highly recommended to use Spring JMS or Jencks.
  • With JMSPool
    • You could use a JMSPool intance with multiple threads for incoming and outgoing messaging
    • The threads are managed by Java 5 ThreadExecutor
    • Each thread uses a JMS instance
  • Diagrams
    • JMSPool works differently in different scenarios
    • For outgoing messages to Queue or Topic, it works like the following diagram

      • Without the pool, multiple clients will have to send message in a serial manner. The JMSPool supports clients from multiple threads to send message asynchroniously. When there are more concurrent message than worker threads, the messages will be put on a an internal buffer.
      • Worker threads are spawn to handle connection in parallel, each thread makes a connection to the JMS server.
      • In the initial implementation, the main advantage of the JMSPool over the original JMS are:
        • user could easily send outgoing message in parallel, e.g.
          It spawns 10 threads to send 10 messages in parallel. In this case,
        • Asynchronous sending
          every user call is returned asynchronously after it reaches the internal buffer, instead of waiting for the message to reach the external JMS server. It potentially provide a better throughput when you have a large volume of messages to send. Notice that this is not necessary the ideal behavior in every case and you should be cautious when using it, and without a recovery mechanism in place (as in the initial implementation), your outgoing message may lose if there is exception in delivery and you'll only get an exception via the global exception handler. TODO verify the exception implementation
        • connection reuse
          every thread get a connection from the AMQ connection pool to send message. The connection pool is supposed to provide connection re-use. Session is not shared.
  • No labels