I am working on a JMS subscriber application in which i need to connect to a remote SonicMQ queue. When i connect to the queue using broker url,username,password etc, I am getting Queue not found exception but the queue exists on the broker and queue details are available on the .binding file. So can all the queues available in the .binding file be accessed using the non-.binding file method(connecting to broker using broker url and port)? Is there any difference between connecting to the broker using the brokerurl,username,password etc and connecting using .binding file as a provider url?
Related
I am new to the IBM MQ and I am doing research for one of the requirement. I have two MQ channels in the queue manager that I will be connecting from JMS client (Standalone Java Application) and I need to configure those in CCDT file.
When primary MQ channel that I am connected to is down, it has to connect to secondary standby MQ channel after waiting for certain amount of time while trying to reconnect to primary MQ channel.
Can I configure that wait time in CCDT file or in JMS client java class?
I have gone through the some of the IBM documentation and I see the setCCDTURL() and setConnectionTimeout() methods for factory object, I am not sure if that fulfills my requirement.
We are trying to connect to IBMMQ using CCDT file and JMS configuration.
We are able to connect to it but we have an issue here:
since we are using spring to set connection factory with CCDT file, this is initialized once at the start of the application, but unfortunately it picks only one queue manager at a time,i.e it sends all the messages to same queue manager and it does not load balance.
Though i observed, if i manually set the CCDT file before every request then its able to load balance the Queue Managers, ideally it looks to me Queue Manager is decided whenever i set the URL to CCDT file. which is wrong practice. My expectation was to initialize the connection factory with CCDT file and then this configuration will be able to load balance on its own.
Can you help me this?
This is the expected behavior. MQ does not load balance clients, it connection balances them. The connection is the single most time consuming API call and in the case of a mutually authenticated TLS connection can take seconds to complete. Therefore a good application design will attempt to connect once, then maintain that connection for the duration of the session. The JMS architecture and Spring framework both expect this pattern.
The way that MQ provides load distribution (again, not true balancing, but rather round-robin distribution) is that the client connects a hop away from a clustered destination queue. A message addressed to that clustered destination queue will round-robin among all the instances of that queue.
If it is a request-reply application, the thing listening for requests on these clustered queue instances addresses the reply message using the Reply-To QMgr and Reply-To Queue name from the requesting message. In this scenario the requestors can fail over QMgr to QMgr if they lose their connection. The systems of record listening on the clustered queues generally do not fail over across queue managers in order to ensure all queue instances are served and because of transaction recovery.
Short answer is that CCDT and MQ client in general are not where MQ load distribution occurs. The client should make a connection and hold it as long as possible. Client reconnect and CCDT are for connection balancing only.
Load distribution is a feature of the MQ cluster. It requires multiple instances of a clustered queue and these are normally a network hop away from the client app that puts the message.
I have an application which uses ActiveMQ broker. In order to have some integration test I have created another tool which puts messages into the queue.
What I want to achieve is to avoid using physical ActiveMQ but initialize AMQ together with starting my application, then connect my tool which loads messages into this queue and at the end close all connections. I can do sth like this using the same process (unit tests) when I start AMQ transport like vm://localhost but it doesn't work when I want to connect from another process to put sht onto the queue. Has anybody faced similar issue?
The vm transport cannot communicate outside the JVM in which it was started.
Combining peer transport with vm allows for embedded brokers to discover remote brokers over discovery networks (multicast, jgroups, etc), but this seems like overkill, suggest using tcp for simplicity.
//create embedded broker using tcp
BrokerService broker = new BrokerService();
broker.addConnector("tcp://localhost:61616");
broker.start();
//remote client use tcp to connect, but local JVM client can use vm
vm:broker:(tcp://localhost:61616)
Created a webpage where a user can paste their XML file and after clicking the submit option, the XML file will go to other system ( which is test environment). That system is basically running on IBM (MQ) and I have to use JMS for it. I have QUEUE, Port, host name. Does anyone has any similar example which I can use as direction?
Basically, this is what you will need to do:
Accept the XML mesaage from UI.
Create a MQ Connection factory with details of your port,host and queue.
Create a JMS connection from MQ Connection Factory.
Create a JMS session off the JMS connection.
Create a JMS message Producer off the JMS session.
Create a JMS TextMessage containing the XML file.
Send the message to the JMS queue via the producer.
Will try to add a code example in a while, in the meantime for each step you will be able to find multiple examples online.
Dont forget to close the JMS message producer, jms session and jms connection in the finally block as they are resources.
When we use a client acknowledgement mode in JMS (I am using Websphere MQ and WAS), the MDB sends the acknowledgement to whom (the docs say to the JMS server).
But in this case, the JMS server means what: the WebSphere MQ which actually has all the queues and the messages or the web sphere application server that is connecting to the websphere MQ.
Acknowledgements, no matter the type, are always sent to the JMS server. Message producers and consumers never communicate directly due to the asynchronous nature of JMS.
Are you using connection factories to obtain a connection? If so, look at the broker url configuration in those factories. You should find the connection url points to WSMQ brokers. So, when you get a connection from a connection factory, the client connection goes directly to the JMS server in WSMQ.