| Author |
Message
|
| Rodeo |
 Posted: Thu May 10, 2007 3:15 am Post subject: MQJMS2005: failed to create MQQueueMAnager / Reason 2059 MQJ |
 |
|
Apprentice
Joined: 11 Apr 2007
Posts: 30
|
We are trying to have XI JMS adapter communicate with MQ. WBRK6_DEFAULT_QUEUE_MANAGER is the QM I am using.
The SVRCONN Channel is set up. Listener is up and running on port 2414. This is the configuration on my machine that has MQ and the queues set up.
On XI JMS adapter, they have configured sender/receiver channels and used the parameters I provided to connect to MQ on my machine.
We are getting the following error on XI side in the JMS adapter connection.
Error during channel initialization: exception trace:javax.jms.JMSException: MQJMS2005: failed to create MQQueueMAnager for dg75h1c1:WBRK6_DEFAULT_QUEUE_MANAGER”
MQException: MQJE001: An MQException occurred: Reason 2059 MQJE001: socket connection attempt refused.
Any thoughts on this error?
Though XI/JMS adapter and MQ are installed on different machines both are located in the same intranet.
Do I have to explicitly do anything to allow another machine to access my local queues like adding that userid to my mqm group?
Or anything else that could possibly be causing this error? |
|
| Back to top |
|
 |
| Vitor |
| Posted: Thu May 10, 2007 3:23 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
Do a search through the forum for your 2059 code - it's a common problem and some of the discussions may point you in the right direction. The code means "queue manager inaccessable" but there are any number of possible causes.
I'd look at network issues (firewalls and the like) as a first pass. Also any SSL requirements - the "connection attempt refused" is telling here.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Rodeo |
| Posted: Thu May 10, 2007 3:30 am Post subject: |
|
|
Apprentice
Joined: 11 Apr 2007
Posts: 30
|
Thanks Vitor
| Quote: |
| Do a search through the forum for your 2059 code - it's a common problem and some of the discussions may point you in the right direction. |
I already searched the forum, but couldn't find anything that could be an issue in my set up here. 
| Quote: |
| I'd look at network issues (firewalls and the like) as a first pass. Also any SSL requirements - the "connection attempt refused" is telling here |
I thought about this. But when we are on this intranet all firewalls are disabled. We have not set up any SSL so I am not sure if that would be something causing this error. Any thoughts? |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu May 10, 2007 3:36 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
I'd remain focused on the "connection refused" as a key clue. Make sure the listener is running on the port you think it is, try telneting to it to see if you can reach it from your source box. Also make sure there are no network issues like firewalls or hardware switches - if I had a fiver for every time I'd been told there was no firewall between 1 queue manager and another, only to be told 3 hair-pulling days later "apart from this one" I'd be able to get effective treatment. 
My only real tip on that is be certain you're not being routed out of the intranet and back again - that's happened to me before now.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Rodeo |
| Posted: Thu May 10, 2007 3:48 am Post subject: |
|
|
Apprentice
Joined: 11 Apr 2007
Posts: 30
|
| Quote: |
| Make sure the listener is running on the port you think it is, try telneting to it to see if you can reach it from your source box. |
I checked the listener, and it is up and running when I see in MQ explorer. It is the DFLTBRKLISTENER running on port 2414. We were able to successfully ping the machine hosting MQ from the machine having XI/JMS adapter.
I will also double check if I am able to telnet to the MQ box on this port and possible firewall issues.
Also in a scenario like this where one host machine is trying to communicate to MQ on another host, is there anything else that needs to be done besides setting up SVRCONN Channel/listener/queues/queue manager.
*Like adding that username of that host to the mqm group on the machine hosting MQ? |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu May 10, 2007 4:00 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Rodeo wrote: |
Also in a scenario like this where one host machine is trying to communicate to MQ on another host, is there anything else that needs to be done besides setting up SVRCONN Channel/listener/queues/queue manager.
*Like adding that username of that host to the mqm group on the machine hosting MQ? |
If you were having security problems I'd have expected a 2035 reason code not a 2059. Which is not to say you do need to take some action to authorise the user on the target box because you do.
I would not recommend adding users to the mqm group. This will give them administrative rights over the queue manager, which is a security exposure and seldom needed. Authorise a given group to use the required MQ facilities, and add the users to that.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Rodeo |
| Posted: Thu May 10, 2007 10:46 am Post subject: |
|
|
Apprentice
Joined: 11 Apr 2007
Posts: 30
|
Thanks Vitor.
I will also double check if I am able to telnet to the MQ box on this port and possible firewall issues.
I checked for telnet connectivity and realized that the port I was using earlier did not allow that connection. However, when I used another port telnet connectivity worked and the error message also disappeared.
I have not seen any firewall issues though. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu May 10, 2007 12:37 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| Rodeo wrote: |
Thanks Vitor.
I will also double check if I am able to telnet to the MQ box on this port and possible firewall issues.
I checked for telnet connectivity and realized that the port I was using earlier did not allow that connection. However, when I used another port telnet connectivity worked and the error message also disappeared.
I have not seen any firewall issues though. |
Well if the right port does not accept a connection (telnet) how can that not be a firewall problem ? (The assumption here is there is nothing wrong with the network card or definition..)
Some firewalls are software running on the machine itself...
So if your listener is running on port 2414 and you cannot from your client machine run
| Code: |
| telnet qmgrmachine_name/ip 2414 |
you have a firewall/communications problem that you need to resolve before you can advance to the next box (do not collect $200 and go directly to jail...) 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| Rodeo |
| Posted: Thu May 10, 2007 1:25 pm Post subject: |
|
|
Apprentice
Joined: 11 Apr 2007
Posts: 30
|
Thanks fjb_saper
| Quote: |
Well if the right port does not accept a connection (telnet) how can that not be a firewall problem ? (The assumption here is there is nothing wrong with the network card or definition..)
Some firewalls are software running on the machine itself...
So if your listener is running on port 2414 and you cannot from your client machine run |
I created another queue manager and set up a listener for that on port 3414 and then tried telneting to that port. This worked. So the parameters on JMS adapter for SAP have been changed to use 3414 instead of 2414. So now it is working. |
|
| Back to top |
|
|
|
|
