Dynamic Topic Creation - Source Code Modification

[afinnell]

Through my use of other JMS providers such as OpenJMS, SonicMQ and a few others I've never seen a provider deny the creation of a topic through session.createTopic() if the topic hasn't been administratively added. I thought this was quite interesting as it doesn't make much sense having to administratively create non-durable topics.
Looking through the code I came across JMSDestinationManager.java. I changed the code to automatically create the destination if it doesn't exist. Here are the relevant changes.

file: org/jboss/mq/server/JMSDestinationManager.java

 /**
 * #Description of the Method
 *
 * @param dc Description of Parameter
 * @param name Description of Parameter
 * @return Description of the Returned Value
 * @exception JMSException Description of Exception
 */
 public Topic createTopic(ConnectionToken dc, String name) throws JMSException
 {
 SpyTopic newTopic = new SpyTopic(name);
 if (!destinations.containsKey(newTopic))
 {
 /** Instead of denying the topic, just add a new topic if it didnt exist */
 JMSTopic jmsTopic = new JMSTopic (newTopic, null, this, new BasicQueueParameters());

 // throw new JMSException("This destination does not exist !");
 addDestination (jmsTopic);
 }
 return newTopic;
 }

Now this appears to work so that JBossMQ is a little more consistent with other providers that allow true dynamic topic creation through session.createTopic (). I understand the JMS Spec doesn't say that createTopic needs to create a new topic if it doesn't exist but it's always nice to place well with others. :)
There is one problem with this approach that I see off hand and that is no MBean gets associated with the Topic. In and of itself that isn't too bad because I dont want to admin these topics anyways. What other problems could arise from this solution that I may not be aware of?

Andrew T. Finnell

[adrian.brock]

The javadocs say this method is creating the topic identity, i.e. the
javax.jms.Topic object.

It explicitly excludes the creation of the physical destination.

CreateTopic

public Topic createTopic(java.lang.String topicName)
 throws JMSException

 Creates a topic identity given a Topic name.

 This facility is provided for the rare cases where clients need to dynamically
manipulate topic identity. This allows the creation of a topic identity with a
provider-specific name. Clients that depend on this ability are not portable.

 Note that this method is not for creating the physical topic. The physical creation of
topics is an administrative task and is not to be initiated by the JMS API. The one
exception is the creation of temporary topics, which is accomplished with the
createTemporaryTopic method.

[afinnell]

Adrian,

You bring up an excellent point however I must say that requiring the user to administratively create topics to enable them to establish topic's of interest makes for an unsound architecture. In many architectures dynamic topic's need to be created that cannot be known ahead of time. The only solution then is to create these topic's by remote administration such as JMX or the URL approach provided in many JBoss examples. This breaks down the standardization of the JMS API that should allow the same code to be used with different providers.
While TemporaryTopic's can be used to establish true dynamic topic's they may not always be practical as the topic's may be dynamic but might need to confirm to some specific naming structure. What are the architectural reasons for not allowing createTopic() to create the logical representation of the Topic on the server side? Many JMS providers automatically create the topic without requireing the need for customization to the provider. Maybe we can get some other feedback as to the architectural disadvantages to automatically creating the topic. I believe if the topic's can be administratively added through outside means it can only furthur the ease of use and abilities of JBoss to allow the automatic creation of the Topics in the server through createTopic.

Andrew T. Finnell

[adrian.brock]

There are no architectural considersations. It is purely a case of following the spec.
I have little interest in how other jms implementations break the spec, especially
on a method that is explicity described as non-portable.

I don't see how it can be made portable. Although most vendors implement the JMS spec
in a fairly literal manner, the jms api can be used to wrap disparate messaging systems.
e.g. it could wrap an e-mail system, then you could have:

Queue queue = session.createQueue("[e-mail]");
Topic mailingList = session.createTopic("[e-mail]");

My prefered solution would be for the spec to standardize on a set of jms messages that
could be sent to a spec defined destination (e.g. JMS_ADMIN) to configure the server.

e.g.

...
QueueSender sender = session.createSender(jmsAdmin);
AdminMessage adminMessage = session.createAdminMessage();
adminMessage.setType(AdminMessage.CREATE_TOPIC);
adminMessage.setName("MyTopic");
adminMesasge.setProperty(...);
adminMessage.setRoles(...);
sender.send(adminMessage);

But I guess that suggestion will have to wait until work starts on JMS2.0,
there are no plans for such a review that I'm aware of.

[afinnell]

I agree that an administration set of commands would be an excellent addition to JMS to provide for a more portable solution across providers. Until then I support we all will make due with what we have. Possibly a standarized JMX solution could be brought into JMS for configuration of queue's and topic's.

This discussion was enlightening as to the reasons createTopic does not create a physical representation of the Topic. It's reassuring to know that JBoss was following the spec and didnt drop the ball on creating topics. I was having doubts as to JBossMQ's viability until our discussion. Thanks.

Andrew T. Finnell