LibraryToggle FramesPrintFeedback
Prev   Next

Build and Run the Example

After building and running the example using Maven, you can use JMX to examine what has happened to the JMS queues involved in the application.

To build and run the transactional JMS example, perform the following steps:

  1. To build the example, open a command prompt, change directory to tx-jms-router, and enter the following Maven command:

    mvn install

    If the build is successful, you should see the file, tx-jms-router-1.0-SNAPSHOT.jar, appear under the tx-jms-router/target directory.

  2. To run the example using the camel-maven-plugin, enter the following Maven command:

    mvn camel:run

    If all goes well, you should see about a dozen occurrences of java.lang.Exception: test scrolling past, before activity in the console window comes to a halt. Do not kill the running application at this point!

    [Note]Note

    But make sure that the exceptions you are seeing in the console do not indicate a failure to download and install the camel-maven-plugin. Normally, the plug-in should download and install without any problems, because the generated POM file, tx-jms-router/pom.xml, contains all of the requisite settings.

  3. What happened? The series of runtime exceptions thrown by the application is exactly what we expect to happen, because the route is programmed to throw an exception every time an exchange is processed by the route. The purpose of throwing the exception is to trigger a transaction rollback, causing the current exchange to be un-enqueued from the queue:credit and queue:debit queues.

    To gain a better insight into what occurred, open a JMX console and point it at the ActiveMQ broker. Open a new command prompt and enter the following command:

    jconsole
    [Note]Note

    The jconsole utility is a standard tool provided with Sun's J2SE distribution (JDK).

  4. To open a JMX connection to the ActiveMQ broker (which is embedded in the running example application), click on the Remote tab of the JConsole: Connect to Agent dialog and enter the Port number, 1099 (the default JMX port for ActiveMQ). Click Connect.

    [Note]Note

    It is possible to customize the JMX port used by ActiveMQ. See http://activemq.apache.org/jmx.html for details.

  5. If the connection succeeds, the JConsole window shows you a summary of the Virtual Machine (VM) instance that you are connected to. Click the MBeans tab and drill down to the giro queue, in Tree/org.apache.activemq/broker1/Queue.

    Notice that the EnqueueCount, DispatchCount, and DequeueCount for giro are all equal to 2, which indicates that two messages entered the queue and two messages were pulled off the queue.

  6. Click on the debits queue. Notice that the EnqueueCount, DispatchCount, and DequeueCount for debits are all equal to 0. This is because the test exception caused the enqueued message to be rolled back each time an exchange passed through the route. The same thing happened to the credits queue.

  7. Click on the ActiveMQ.DLQ queue. The DLQ part of this name stands for Dead Letter Queue and it is an integral part of the way ActiveMQ deals with failed message dispatches. In summary, the default behavior of ActiveMQ when it fails to dispatch a message (that is, when an exception reaches the JMS consumer endpoint, jmstx:queue:giro), is as follows:

    1. The consumer endpoint attempts to redeliver the message. Redelivery attempts can be repeated up to a configurable maximum number of times.

    2. If the redeliveries limit is exceeded, the consumer endpoint gives up trying to deliver the message and enqueues it on the dead letter queue instead (by default, ActiveMQ.DLQ).

    You can see from the status of the ActiveMQ.DLQ queue that the number of enqueued messages, EnqueueCount, is equal to 2. This is where the failed messages have ended up.

  8. You can now kill the example application by typing Ctrl-C in its command window.

Comments powered by Disqus
Prev Up Next
 Home