| Author |
Message
|
| codeguy03 |
 Posted: Fri Aug 06, 2021 5:26 am Post subject: Random 2059 error when connecting to QueueManager |
 |
|
Newbie
Joined: 05 Jun 2021
Posts: 6
|
I am using this code to connect to a queue manager.I am using the AMQMDNETSTD.dll version 9.2.3
Hashtable properties = new Hashtable();
properties.Add( MQC.HOST_NAME_PROPERTY, Host );
properties.Add( MQC.PORT_PROPERTY, Port );
properties.Add( MQC.USER_ID_PROPERTY, UserId );
properties.Add( MQC.PASSWORD_PROPERTY, Password );
properties.Add( MQC.CHANNEL_PROPERTY, ChannelName );
properties.Add( MQC.TRANSPORT_PROPERTY, TransportType );
// Following line throws an exception randomly
MQQueueManager queueManager = new MQQueueManager( qmName, properties );
At times randomly I will get a 2059 error when trying to connect. I had to put the connection within a try catch block and try to reconnect within the catch block. This is hacky way but it works.
Is there a way to keep trying to reconnect on failure or exception without doing this?
try
{
MQQueueManager queueManager = new MQQueueManager( qmName, properties );
}
catch(Exception)
{
MQQueueManager queueManager = new MQQueueManager( qmName, properties );
}
EDIT: A little more context.
I am connecting to a queuemanager under a FQDN.
Under this Domain I have two servers and each server can connect to any one of two queuemanagers called QM1 and QM2.
So if QM2 through server 1 is busy it should connect to QM1 on server 1 or server 2. It seems to be looking for the first QM on a single server and if it isnt available then it throws an exception.
Only then does it look for that QM again and works the second time. |
|
| Back to top |
|
 |
| RogerLacroix |
| Posted: Mon Aug 09, 2021 3:46 pm Post subject: |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3264
Location: London, ON Canada
|
Maybe I'm reading your question wrong but are you looking for some sort of magic in MQ?
There is nothing in MQ that would determine if your connection to QM1 fails that it should try QM2 on the same server or different server.
If you want to use the reconnection logic, to the same queue manager on different servers, then you would do the following:
| Code: |
| properties.Add(MQC.CONNECTION_NAME_PROPERTY,"server1(1414),server2(1414)"); |
Finally, maybe the reason for the reason code of 2059 is that the queue manager has reached its maximum allowed number of connections. i.e. default is 100. Also, each channel has 2 attributes that control the number of connections allowed: "Maximum Instances" and "Maximum Instances per Client".
Regards,
Roger Lacroix
Capitalware Inc.
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
| Back to top |
|
|
| codeguy03 |
| Posted: Mon Aug 09, 2021 8:17 pm Post subject: |
|
|
Newbie
Joined: 05 Jun 2021
Posts: 6
|
| RogerLacroix wrote: |
Maybe I'm reading your question wrong but are you looking for some sort of magic in MQ?
There is nothing in MQ that would determine if your connection to QM1 fails that it should try QM2 on the same server or different server.
If you want to use the reconnection logic, to the same queue manager on different servers, then you would do the following:
| Code: |
| properties.Add(MQC.CONNECTION_NAME_PROPERTY,"server1(1414),server2(1414)"); |
Finally, maybe the reason for the reason code of 2059 is that the queue manager has reached its maximum allowed number of connections. i.e. default is 100. Also, each channel has 2 attributes that control the number of connections allowed: "Maximum Instances" and "Maximum Instances per Client".
Regards,
Roger Lacroix
Capitalware Inc. |
OK thank you for the reply.
So I think the servers connections might be maxed. So after each put and get is there a setting that will automatically close and release the connection ( kind of like a using statement or similar) without calling queue.close()? I run alot of puts and gets on a separate threads as a task.
I need as many connections made available as fast as possible at all times. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Aug 10, 2021 4:44 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| codeguy03 wrote: |
So I think the servers connections might be maxed. So after each put and get is there a setting that will automatically close and release the connection ( kind of like a using statement or similar) without calling queue.close()? I run alot of puts and gets on a separate threads as a task.
I need as many connections made available as fast as possible at all times. |
That's called using a connection pool. Read the documentation  and see how it is implemented for you in MQ. And no you'd still need to call queue manager disconnect to release the connection to the pool...
In brief, review your setup. You should be opening the connection once, accessing the queue once, do any number of MQGET or MQPUT and then close the queue, and then disconnect from the queue manager... 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| RogerLacroix |
| Posted: Tue Aug 10, 2021 10:43 am Post subject: |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3264
Location: London, ON Canada
|
| codeguy03 wrote: |
So I think the servers connections might be maxed. So after each put and get is there a setting that will automatically close and release the connection ( kind of like a using statement or similar) without calling queue.close()? I run alot of puts and gets on a separate threads as a task.
I need as many connections made available as fast as possible at all times. |
Well, that could explain what is happening as you are shooting yourself in the foot.
Some basic programming rules that you must follow:
- if you open a queue, then in all circumstances, you must close the queue.
- if you have connected to a queue manager then when done, in all circumstances, you must disconnect from the queue manager.
By all circumstances, I'm referring to the finally clause of try/catch/finally, where you would put the code for close and disconnect.
Hence, by you not closing the queue and disconnecting from the queue manager, those connections stay around until they go stale and get cleaned up at the TCP expiry value (usually 2 hours). i.e. You shot yourself in the foot and end up blocking yourself from making new connections.
A queue manager can support 1000's of connections. First, clean up your code to do proper coding for closing and disconnecting then you can update the queue manager's qm.ini file to increase the maximum allowed connections.
i.e.
| Code: |
Channels:
MaxChannels=500 |
Regards,
Roger Lacroix
Capitalware Inc.
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Tue Aug 10, 2021 11:12 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
Also increase MaxActuveChannels stanza.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| RogerLacroix |
| Posted: Tue Aug 10, 2021 11:40 am Post subject: |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3264
Location: London, ON Canada
|
Hi Bruce,
The MQ Knowledge Center says:
| Quote: |
MaxChannels= 100|number
The maximum number of current channels allowed. The default is 100.
You can set MaxChannels to a different value to limit the maximum number of current channels if required. For IBM MQ Appliance, the default value is 999 999 999, and should not be changed.
MaxActiveChannels= MaxChannels_value
The maximum number of channels allowed to be active at any time. The default is the value specified for the MaxChannels attribute. |
So, you don't need to set a value for MaxActiveChannels because it will just default to whatever value is set for MaxChannels.
Regards,
Roger Lacroix
Capitalware Inc.
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
| Back to top |
|
|
| markt |
| Posted: Tue Aug 10, 2021 11:53 am Post subject: |
|
|
Knight
Joined: 14 May 2002
Posts: 508
|
| The same question is on stackoverflow and in that, it looks like the OP doesn't really understand DNS and how naming works. |
|
| Back to top |
|
|
| codeguy03 |
| Posted: Thu Aug 12, 2021 9:56 pm Post subject: |
|
|
Newbie
Joined: 05 Jun 2021
Posts: 6
|
| markt wrote: |
| The same question is on stackoverflow and in that, it looks like the OP doesn't really understand DNS and how naming works. |
Does this make you feel good? Like why even come on here to type this out?
I don't understand the lack of compassion on these forums. It seems any question is met with strong condescending undertones. Just like your post.
I never hurt anyone, nor said anything to offend but you decide to post something that is unfruitful. The same negative undertones are throughout this thread and all across this message board.
Someone asks a legitimate question for help and it is met with negativity.
The people and interpersonal skills on this forum is really lacking and could use alot of work
 |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Fri Aug 13, 2021 6:58 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| codeguy03 wrote: |
| I don't understand the lack of compassion on these forums. |
An interesting observation. We're an MQ technical forum. Compassion is not high on our list of job-related traits - always room for improvement.
Was it Markt's reply that set you off? Were you annoyed at our pointing out your misunderstanding of MQ internals and MQ programming? I found these replies quite on-task. Terse, yes. But I read no evil intent.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| codeguy03 |
| Posted: Wed Aug 18, 2021 9:15 am Post subject: |
|
|
Newbie
Joined: 05 Jun 2021
Posts: 6
|
| bruce2359 wrote: |
| codeguy03 wrote: |
| I don't understand the lack of compassion on these forums. |
An interesting observation. We're an MQ technical forum. Compassion is not high on our list of job-related traits - always room for improvement.
Was it Markt's reply that set you off? Were you annoyed at our pointing out your misunderstanding of MQ internals and MQ programming? I found these replies quite on-task. Terse, yes. But I read no evil intent. |
Its pretty much the lack of "People Skills" and Professionalism around here. That does need to be worked on around here. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed Aug 18, 2021 9:21 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| codeguy03 wrote: |
| bruce2359 wrote: |
| codeguy03 wrote: |
| I don't understand the lack of compassion on these forums. |
An interesting observation. We're an MQ technical forum. Compassion is not high on our list of job-related traits - always room for improvement.
Was it Markt's reply that set you off? Were you annoyed at our pointing out your misunderstanding of MQ internals and MQ programming? I found these replies quite on-task. Terse, yes. But I read no evil intent. |
Its pretty much the lack of "People Skills" and Professionalism around here. That does need to be worked on around here. |
I ask again, what specifically set you off? You are new to this post site, and seem to have arrived ready to be offended. Perhaps something you can work on. Just an observation on my part.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| gbaddeley |
| Posted: Wed Aug 18, 2021 3:39 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
| codeguy03 wrote: |
| markt wrote: |
| The same question is on stackoverflow and in that, it looks like the OP doesn't really understand DNS and how naming works. |
Does this make you feel good? Like why even come on here to type this out? |
codeguy03, If someone has unclear understanding of MQ or associated technologies on one forum, we don't want to repeat the same information and have the same conversations on multiple forums. It is not productive and can be confusing.
This forum has an active group of MQ professionals, many with 10-20 or more years of experience with MQ and related products. Between us, we follow every MQ forum on Internet to provide advice. Often we go above our calling to help folks out and look after each other. We want MQ to grow and succeed and encourage the best ways of using it. 
_________________
Glenn |
|
| Back to top |
|
|
|
|
