Hi Team,

I am facing an issue. I created topic/queue using Java API. But when I am trying to subscribe to that topic using a JMS trigger , the topic/queue is not getting listed. I did a JNDI lookup and the topic/queue were not looked up. Now in the enterprise manager , do I need to manually create those topic/queue in the JNDI tab?

Please share your inputs.

Thanks and Regards
Abir Banerjee

Abir,
the recommended way to create a queue or topic for use with JMS is through the Enterprise Manager JNDI tab. That will create the channel/queue with the right settings AND it will create the JNDI destination object.
If you only use the UM Java API to directly create a channel/queue, it will create the channel/queue, but you will not have the JNDI entry.
You can also look at Command Central for creating queues/topics (9.10 or higher). Here you also use the JNDI configuration and it can automatically create the queue/channel as well.

Thanks a lot Jonathan for your response. That means if I create the topic/queue using UM API , I will have to use the API to publish/consume messages, since JNDI entry will not be there hence I will not be able to use the pub.jms:send and the JMS Trigger for send/receive. Is that the correct assumption here?

Yes I am looking at the Command Central option also.

Regards
Abir

Hi,

You should check the source code of the JMSadmin command-line tool.

It does create the queue/topic and its corresponding JNDI entry.
Tested on 9.9.

Best Regards,

I concur with Gerardo , you need to either use JMSAdmin command line tool / Enterprise Manager or Command Central to create both JMS destinations and corresponding JNDI look-up entry.

If you use UM Java API , it creates only JMS destinations , the JNDI entries are not created.

Thanks everyone for your response .

We will be using the Command Central command line functionality to create the topics/queues. Actually we need to create around 2000-3000 topics/queues , hence manual creation will be challenging and time consuming.

Regards
Abir

Hi Abir,

I’m not able to imagine the reason of the scenario where you would need to create administratively (and maintaining) 2000-3000 topics/queues. If you need to interconnect an huge amount of users the most appropiated way to do it is using the publish & subscribe paradigm. In this way if you create a set of few different topics, you may sent the information to all subscriptors previously engaged to this information (each subscriptor must to have a configuration with your preferences). If the subscriber is listening by means of an appropiated filter, it may be the unique receiver of a information.

In this way, the same subscriptor code is shared among thousand of users but the queueing resources and configuration is common.

Hi Juan,

Thanks for your suggestions. I will definitely take this up with the client.

Regards
Abir