Fuse Message Broker - Exploring JMS - Revising Parameters in the Build File

Revising Parameters in the Build File

Basics

The Ant build.xml file was revised to add the Fuse Message Broker version and installation location. Now you will change and add parameters in the target section for each sample run. Each parameter's name-value pair is presented as two sequential arguments. For example:

<target name="chat1">
  <java classname="Chat" ... >
    ...
    <arg value="-u"/>
    <arg value="Chatter1"/>
  </java>
</target>

That listing shows that the -u parameter, the user name, is assigned the value "Chatter1".

Changing the User Name

Change the user name value from "Chatter1" to "Fred" as shown:

<target name="chat1">
  <java classname="Chat" ... >
    ...
    <arg value="-u"/>
    <arg value="Fred"/>
  </java>
</target>

Save the file, and then enter ant chat1 in one of the sample windows, type Hello, and then press Enter. The response line is:

[java] Fred: Hello

	Note
	The `password` parameter requires implementation of security. For these samples, that would require all the user names and their respective passwords be defined in the security store. For information about securing JMS applications see Security Guide.

Changing destination names

The queue and topic names used in the sample are arbitrary and can be created dynamically. Some pub/sub application applications let you specify the publish topic and the subscribe topic as parameters. For wildcard, the HierarchicalChat exposes the topic to which the application publishes as the -t parameter, and the topic to which it subscribes as the -s parameter. You could change these topics to demonstrate a Fuse Message Broker feature by extending the publish topic to a fourth level, and changing the wildcard on the subscriber topic from * to >. That expands the wildcard from all topics at the current hierarchical level to all topics at that level or deeper.

<target name="wildcard">
  <java classname="HierarchicalChat" fork="true">
    ...
    <arg value="-u"/>
    <arg value="HierarchicalChatter"/>
  </java>
</target>

Other topic and queues could be changed in the build file so you can observe how they interact with other sample applications. For the MessageMonitor application, change its depth of topic hierarchies in its properties file, MessageMonitor.properties, to subscriptionTopics jms.samples.>

Changing the queue round trips

The QueueRoundTrip application is set in the build file to iterate 10,000 times through sending a message to a queue, receiving it off the queue, and taking that as the cue to send another message. You can change that number to a larger or smaller value to see start and stop operations are impactful. Try 1000 (one thousand), save the build file, and run ant roundtrip. Try 100000 (one hundred thousand), save the build file, and run ant roundtrip. For example:

<target name="chat1">
  <java classname="QueueRoundTrip" ... >
    ...
    <arg value="-n"/>
    <arg value="1000"/>
  </java>
</target>

Distributing the client and the broker

At this point in exploring JMS, the broker used by the samples is always on the computer where the sample applications run. While you might use a local or an embedded broker, JMS messaging is designed so that the sample applications can run on a computer that has the appropriate libraries, yet can connect to a broker on a different system to produce and consume messages. The standalone broker system would typically be in a location where it can be monitored and provided resources that ensure optimal availability to any applications that use it.

The sample applications provide a -b parameter to specify the protocol, host, and port of the preferred broker. As the default broker configuration specifies the TCP protocol on localhost, listening on port 61616, you can use another installation of the Java, Fuse Message Broker, Ant, and the Exploring JMS files (as described in the previous chapter) on another computer to experience distributed connection. On one host set up and start the broker. On the other host (the remote host), do the same.

Stop the broker on the remote host, then modify the build.xml file on the remote host to add the connection parameter and specify the host name where the broker is running. For example:

<target name="chat1">
  <java classname="Chat" ... >
    ...
    <arg value="-u"/>
    <arg value="Fred"/>
    <arg value="-b"/>
    <arg value="tcp://remoteHostName:61616"/>
  </java>
</target>

Save the build file and then run chat1 in a sample window on each of the computers. When you enter messages in either Chatter_1 window, the subscribers both get the message from the same broker.

Comments powered by Disqus

Contents
Search