I'm new in using Websphere MQ. I need help in this.
I have a websphere located in a server remotely and I have an application that retrieves and sends the information to the websphere. Is it possible to send my queue to a remote websphere server and at the same time retrieve it? It's something like this.
If yes, how should I configure this one in the websphere remote server? Thanks!
Sorry to say your question is confusing. You don't send/receive queue. You send/receive messages to queue or topic. Can you clarify?
Update:
You can have WebSphere MQ queue manager running on machine and client application on different machine. Application can send and receive messages to/from remote queue manager. This is called as the client mode connection to queue manager and most commonly used type of connection mode.
Please read the WebSphere MQ InfoCenter.
Related
I am doing lot of analysis for a new Java MQ client requirement got some doubts. Currently in the Unix system Queues Queue manager all created where MQ server is running.
In order to run Java MQ client we are going to install MQ client on other Unix Solaris system. Mean while we had one windows server where MQ client installed before going to MQ client installation on unix System need to clear my clarifications.
Since I am new MQ.
Can we run Java MQ client from windows server to connect MQ server unix system(Queues,Queuue Manager)
If yes what need for this to connect Windows Server to unix Solaris
The code is compiled with MQ libraries
Is any error will come to face.
It would be great if you provide steps or solution.
Yes, you can run the Java MQ client from any machine to connect to a queue manager on any other machine. The MQ Clients (Java, 'C' or .NET version) all support any platform to any platform combinations, and all support any MQ version to any MQ version. So for example, you can have a V8 Client on Windows connecting to a V9 Queue manager on Unix. Equally you can have a V9 Client on Windows connection to a V8 Queue manager on Unix, i.e. any to any version can be upwards or downwards.
In order to connect a client to a queue manager, you will need the client libraries on the client machine, in your case the Java client.
You will also need to ensure that your queue manager has a TCP/IP listener running and that you know the port number.
You will need a channel definition on the queue manager of a type called SVRCONN, and know the name of it. e.g.
DEFINE CHANNEL(MQGEM.SVRCONN) CHLTYPE(SVRCONN) DESCR('Channel for my client application to connect to')
In order for your Java client to connect to the queue manager it will need to use
The channel name
The host name of the machine where the queue manager is running
The port number of the TCP/IP listener
If you face any errors, they may be related to connectivity, because your application is connected by the network to the queue manager. Remember to pay attention to any return codes you get from MQ, they will be in the form of 4 digits, e.g. 2059. For Java you should ensure you get hold of the linked exception. It may also be useful to look in the error log of the queue manager too.
You may also face security errors if this is your first use of IBM MQ. The queue manager is locked down by default so that remote applications cannot simply connect in and do damage (e.g. delete important messages from other applications!). There are a number of posts on here that describe these errors and their solutions. Best advise, get the MQRC code (4-digits) and the AMQERR01.LOG error message from the queue manager. Armed with this information you should be able to describe and diagnose any error situations you encounter.
I need to know how IBM Websphere MQ works.
As of my knowledge.
IBM Websphere MQ is an application that runs continuously
IBM Websphere MQ has a queue manager, queue name, port, host where it is runs, channel name.
We have a two different application in two different remote place.
Two applications and the IBM Websphere MQ applications are connected through network.
Using IBM Websphere MQ credentials the applications are able to send and receive messages between them via IBM Websphere MQ.
If I have anything wrong then please guide me.
My questions are:
If one application sends a message to the queue then where will the memory be consumed?
Where do we run the MQ listeners? On the applications environment or the Websphere environment (where we installed the IBM Websphere MQ)?
Do we need to run any programs in the application environments or are the IBM Websphere MQ credentials (queue manager, queue name, port, host where it is runs, channel name) enough to send and receive the messages?
If one application sends a message to the queue then where will the memory be consumed?
A Running Queue Manager requires memory in order to run and handle processing/storage of messages. As well as that every MQ Client application that connects to a Queue Manager requires memory to connect to and put/get messages. This is no different than any application that runs on any system.
Where do we run the MQ listeners?
Assuming you mean MQ Listeners. The MQ Listeners are run on the Queue Manager and specify the (TCP) port you want the Queue Manager to listen on.
Do we need to run any programs in the application environments or are the IBM Websphere MQ credentials (queue manager, queue name, port, host where it is runs, channel name) enough to send and receive the messages?
To run a Queue Manager on a machine, your machine must meet the System requirements stated in the System Requirements for WebSphere MQ page.
Here is the MQ v8 one
Likewise to run a MQ Client application that can connect into a Queue Manager, the application needs to have be ran on a machine that has the IBM MQ Client libraries installed on and meet the system requirements.
You also need to tell the application:
The location of the Queue Manager hostname/IP Address and port number.
The channel to connect into, which must exist on the Queue Manager
The Queue name to interact with, which must exist on the Queue Manager
Depending on your Queue Manager's configuration you need to ensure that your application is running with the correct user/supplying the correct user to ensure it is properly authorized to access the Queue Manager.
An MQ Input node can only connect to the MQ that is bound to the MessageBroker installation. I would like to connect to a remote MQ. I would like to avoid using the JMS Input.
Would it be possible to use the MQ Service for connecting to a remote MQ?
I'm using tve version 9, so actually the IIB.
You can deliver outbound messages to remote queue managers via the broker's queue manager if suitable channels and xmit queues are setup.
This however is not the same as a client connection to a remote queue manager which is not currently supported.
You could use a JCN to call the MQ base API or you could raise a request for enhancement here:
http://www.ibm.com/developerworks/rfe/?PROD_ID=532
I have two clustered managed servers running on Weblogic, and seperate JMS server1 and server2 are running on each managed server. The problem is in application properties file, we only hardcoded and pass JMS server1 JNDI name to the application. So both applications running on each node actually only uses one fixed JMS server, which is not truly distributed and clustered. If JMS server 1 is down, the whole application will be down.
My question is how to let application dynamically find JMS server in above senario? Can you please point me a direction? Thanks!
It's in the Weblogic docs at: http://docs.oracle.com/cd/E14571_01/web.1111/e13738/best_practice.htm#CACDDFJD
Basically you created a comma separated list of servers and the JMS connection logic should be automatically able to handle to case when one of the servers is down:
e.g.
t3://hostA:7001,hostB:7001
When you use a property like jms.jndi.provider.url=t3://hostA:31122,hostA:31124
it tells wls to connect to either hostA:31122 or hostA:31124.
Note your JMS client is connected to only one Host at any given time.
when you shutdown hostA the connection between JMS client and server is cut abruptly resulting in an exception, your code will have to handle this exception gracefully and attempt to connect to WLS again periodically to ensure it connects to hostB.
WLS internally will round robin the request if more than 1 instance of the JMS client is running.
When using MDB as JMS client and deploying it to a cluster and using such a url 1 mdb instance would connect to one host and the other instance would connect to another host. MDB also inherently has the ability to reconnect periodically to the JMS destination.
A easy solution to your problem could be to
1) Set the jms.jndi.provider.url=t3://hostA:31122,hostA:31124
2) Have 2 instance of the JMS client code running, so one will connect to port 31122 and other to 31124
3) Set Forward-Delay on the JMS Queue so that message dont remain in queue without getting consumed for long and get forwarded to the other queue which has an active consumer.
I am updating my progress here instead of adding more comments. I have tested using a standalone JMS client by changing properties file from t3://hostA:7001 to t3://hostA:7001,hostB:7001 for JMS provider. The failover is automatically handled by WLS. No code change. The exception I got above is caused by using wlclient.jar, it is working after it changed to wlfullclient.jar.
I followed this link to generate wlfullclient.jar.
Thanks everyone!
I'm unable to connect remotely from WebSphere Application Server with Queue Manager at WebSphere MQ. Anyhow it get connected to Queue Manager from WAS that is installed on same machine. I'm using version 7.5 of WebSphere MQ and version 7.0 of WebSphere Application Server.
While attempting to connect WAS remotely to Queue Manager following error messages were logged.
Error Message from WebSphere MQ:
1/30/2013 21:12:09 - Process(3624.6) User(MUSR_MQADMIN)
Program(amqrmppa.exe)
Host(KHILT-269) Installation(Installation1)
VRMF(7.5.0.0) QMgr(QM.TEST)
AMQ9504: A protocol error was detected for channel 'TEST_CHANNEL'. EXPLANATION: During communications with the
remote queue manager, the channel program detected a protocol error.
The failure type was 11 with associated data of 0. ACTION: Contact the
systems administrator who should examine the error logs to determine
the cause of the failure.
Error Message at WebSphere Application Server:
A connection could not be made to WebSphere MQ for the following
reason: CC=2;RC=2009
As it can be seen from logs, I have created Queue Manager as QM.TEST and channel as TEST_CHANNEL. The listener port defined for the Queue Manager is 1417 along with protocol TCP.
I did lot of google but didn't find any appropriate solution. I appreciate any help in this regard.
Thanks in adv, KAmeer
I had a similar issue where I have WAS 7 and WMQ 7.5. I was able to make a connection to my existing WMQ 7.0 QM but not my new WMQ 7.5 QM. Apparently there was a change to the WMQ components bundled with WAS 7 after the initial release 7.0.0.0. After updating the resource adapter I was able to make a successfull connection to both queue managers.
The queue manager generates protocol error and terminates the connection immediately when it receives unexpected TSH flow from the client. As a result the client receives 2009 error. Technically, low level MQ client will be able communicate with higher version MQ queue manager and vice versa unless there are known restrictions and/or there is a MQ defect/APAR. The error message indicates the queue manager is running at MQ 7500 and this is MQ base 7.5 version. It is recommended upgrading the queue manager to the latest fixpack available to rule out any known problems. You could also try disabling shared conversion on the SVRCONN(i.e. setting SHARECNV to 0) channel and check whether it workarounds the problem until the problem is resolved.
Open a PMR with IBM as this sounds like a bug.
the cause for this is mq 7 client cannot talk to mq 7.5, the client needs to use mq 7.5 jar files
I had this problem. In my case was the mq library that was doing an MQGET with an infinite loop, so the lib was locked on the mqget while i called the kill and generated an event and tried to disconnect while the get was still running. As the mqget does not support unlocking via signal, i had to change the code to not stay infinite on get and add some flags on the kill command so the app could detect that it was time to die, when it returned from the get.