I would like my Java MQ client to be able to access (do puts) to multiple MQ server endpoints (by endpoint i mean 'host/port/Qmanager/Queue/Channel'). Basically this Java app will get a request to put a message and the endpoint detail along with the request. It should be able to find the corresponding connection pool for the endpoint and use it to do the put.
From my limited understanding so far, the MQEnvironment is a global configuration (only one is possible in one JVM?) which can be configured to one endpoint at a time. So if the idea is multiple threads accessing multiple MQserver endpoints parallely - this does not seem to implementable with current understanding.
You can also use a Hashtable to pass connection parameters while creating a connection to queue manager. For example:
Hashtable<String, Object> properties;
properties = new Hashtable<String, Object>();
properties.put("hostname", "remotehost");
properties.put("port", new Integer(1414));
properties.put("channel", "REMOTEQM.SVRCONN");
MQQueueManager queueManager = new MQQueueManager(queueManagerName, properties);
Either you don't understand MQ very well or your MQ environment is not set up correctly.
Your MQ application should be connecting (and stay connected) to a single queue manager. The queue managers in your MQ environment should be interconnected such that when your MQ application puts a message destined for another queue manager, the local queue manager (that your application is connected to) will route the message to the correct queue manager.
Related
So I have a ConnectionFactory configured from a properties file containing a broker list, meaning that when the session gets created it will have connected to one of the brokers in the list based on availability/policy and so on.
My question is: how to programmatically figure out from the Java code, at runtime, which of the broker URLs have I actually connected to.
What I am trying to achieve is to send management GET requests to the broker API programmatically, but for that I need to obtain its URL. Am I thinking about this the wrong way?
P.S. I am doing this from a Spring-boot application, but am not too fussed about using the JmsTemplate.
I am new to JMS and currently developing a simple Chat application explained in Oreilly 'Java Message service'. I've configured a TopicConnectionFactory in ActiveMQ that receives chat messages from TopicPublishers and dispatch that to TopicSubscribers.
My question is 'why do we need to create more than one TopicConnectionFactory' in any JMS application? Since Connectionfactory instances are not tied up with a Topic/Queue, why can't we use one instance of ConnectionFactory for creating connections to all the Topics (or Queues) configured in an application?
Technically speaking you are right. You may be able just to use one ConnectionFactory.
However it is a better design to use multiple ConnectionFactories depending on your requirements so the traffic would be spread out evenly and you do not run out of connections.
So if you know about a JMS Client application that may be problematic (the logic does not allow proper connection handling open/close), you may isolate it to use its own connection factory.
Also some connection factories allow a pool of 10 default active connections at the same time (it depends on the implementation/ settings) if you will need more you may use more than one connection factory.
I've configured a TopicConnectionFactory in ActiveMQ that receives chat messages from TopicPublishers and dispatch that to TopicSubscribers.
Very ambiguous statement. TopicConnectionFactory does not receive or send any messages. It is just one of the admin Objects used to create Connection which in turn creates Session which in turn creates your publishers and subscribers which publish and subscribe the messages.
why can't we use one instance of ConnectionFactory for creating connections to all the Topics (or Queues) configured in an application?
You definitely can. There is no one stopping you from doing that.
As per specs
A connection factory object encapsulates a set of connection configuration
parameters that has been defined by an administrator. A client uses it to
create a connection with a JMS provider.
So unless you have different configuration requirements you can use same ConnectionFactory to create multiple Connections. And yes as otc has mentioned above number of connections is one of the configuration parameter.
When we set up a queue connection factory, a topic connection factory, a queue, a topic in websphere application server throguh the console, what exactly happens?
The server stores the configuration details in an xml and at server startup, it creates the connection factory(ies), topic(s),queue(s) and puts them in a pool?
I ask because the actual queue(s) and topics(s) itself do not reside on the App server, they reside on a separate (remote) websphere MQ server. So why do we need to 'create' the queues in Websphere App server?
The configuration is metadata for connecting to the remote objects. When the server starts (or an app restarts, or configuration is refreshed), the server reads the .xml, then binds Reference objects into JNDI. The actual connection factories aren't created/pooled until the Reference is first looked up.
I don't have enough experience with JMS to answer your second question, but presumably the metadata is required for the queue in order to access it remotely.
I am developing a service for JMS messaging using IBM WMQ version 7.5 as Message oriented middleware. I am in a dilemma. The IBM specification says to use WebSphere MQ JMS API in JAVA EE environment. My sender and receivers will be in remote JBoss deployments. IBM provides a resource adapter to connect via JCA. This connection requires static administration of components such as Queue managers, queue channels, queue names.
Is JCA the best I can do ? Is there any other way where I can dynamically create the queues provided that I know other configuration details ? There will be multiple applications using this setup running on their own servers. If I use JCA, all have to make their own configurations. Can I make dynamic configurations ?
Typically within the application server environment resources would be created in some JNDI context. These would be Connection Factories and Destinations.
Depending on the app server, it may be possible to share this configuration across a network of individual servers. So typically there would be some set of static definitions.
However within say a servlet the MQConnectionFactory can be dynamically created.
In all cases the backing WMQ Resources do need to exist; though it is possible to send administrative command messages to WMQ to create queues and do other admin. The only exception is topics, accessing a topic string brings it into existence. Though this has default security properties that you might not want.
I wrote a java client to connect to jms in websphere.
I was able to connect and produce and consume message.
Problem I am facing is when I do Session.createQueue(), websphere jms is not creating a new queue.
Please could some one throw some light on this issue...
Thanks in advance...
If you are working with WebSphere MQ as the messaging provider within WebSphere Application Server the queue will need to be created on the WebSphere MQ QueueManager first. This can be done either via the graphical WMQ Explorer or via the command line using the 'runmqsc' tool.
Information can be found for these via the WMQ InfoCentre - suggest doing a websearch for "WMQ Library" to get the latest link, currently though it is http://www-01.ibm.com/software/integration/wmq/library/index.html
Topics though don't need to be pre-created - though they can be if required. Various properties can be set different to the default.
If the Queue doesn't need to be permanent, for example as a temporary reply to then look into creating a temporary queue from the JMS Connection.
createQueue doesn't create a new queue. It simply creates a javax.jms.Queue object from a vendor specific identifier. javax.jms.Queue objects are just references to existing queues. Typically, you retrieve javax.jms.Queue objects from JNDI; createQueue is only useful in scenarios where using JNDI is not possible or not desirable.
Note: there is one exception to this, namely JMS providers that support autocreation of queues (I think ActiveMQ has such a feature).