| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| Unexpected Port Issues |
« View previous topic :: View next topic » |
| Author |
Message
|
| PaulClarke |
 Posted: Wed Dec 31, 2014 1:24 pm Post subject: |
 |
|
Grand Master
Joined: 17 Nov 2005
Posts: 1002
Location: New Zealand
|
If I had to guess I'd say this was an application error. My guess is that the application gets some kind of failure when it tries to open a queue (or something) which causes it to go into some kind of loop where it continually reconnects and fails to open. However, it looks like it forgets it already has a connection and connects again. An MQ trace would tell you pretty quickly what the order of events are.
Cheers,
Paul.
_________________
Paul Clarke
MQGem Software
www.mqgem.com |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Wed Dec 31, 2014 1:54 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20757
Location: LI,NY
|
| vsathyan wrote: |
I'm still not convinced why a queue authority setup would result in channel max out and port backlog issues. Trust me, but this is what happened. I'm into MQ for almost 11 years now, but never expected a queue authority to result in channel or port maxing out.
Error logs dont say the object is missing permissions.
When we did the same for the weblogic application, it also just started working fine.
I'm working tomorrow with the app team to do a binary series on the queue object authorities by turning off/on on each attribute to identify which authority is particularly creating this problem.
I'm updating the status here, as it may be helpful for some one in the future if they face similar issues.
Thank you.
Wish you happy new year 2015. |
Like Paul, I'd say your problem has nothing to do with the authorizations by themselves but a lot more to do with how the application deals with them.
Check how the JMS application handles exceptions. If it simply tries to reconnect without first attempting to clean up and closing the connection .... there's your problem....
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| vsathyan |
| Posted: Thu Jan 01, 2015 8:45 am Post subject: |
|
|
Centurion
Joined: 10 Mar 2014
Posts: 121
|
Most intriguing questions on my mind till now...
1. Why is the issue subsiding when +allmqi is given? (When changed to put/get/browse/inq on queues, and connect/inq/dsp on queue manager, the issue resurfaces).
2. Nothing found in error logs stating a particular permission on an object is missing.
3. Same behaviour on c# and JMS clients. And when +allmqi is given, all applications facing these issues work fine. When removed, the issue starts.
I've got the application code for the JMS piece and for a c# windows service from the app teams. Will review them and update this chain again once i have more information.
Thank you personally all for your valuable time and inputs.  |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Jan 01, 2015 10:21 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9472
Location: US: west coast, almost. Otherwise, enroute.
|
| vsathyan wrote: |
Most intriguing questions on my mind till now...
1. Why is the issue subsiding when +allmqi is given? (When changed to put/get/browse/inq on queues, and connect/inq/dsp on queue manager, the issue resurfaces). |
Granting allmqi is a circumvention, and not a solution.
For further problem-determination you need to identify which permission on which object resolves this.
Restore permissions where the issue resurfaces (take away allmqi); then add one permission on one object at a time to see exactly which permission on which object is the culprit.
_________________
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 |
|
|
| PeterPotkay |
| Posted: Thu Jan 01, 2015 10:21 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
The app is using some options on its MQ calls that are covered by +allmqi. If you take away +allmqi, and don't grant all the individual ones they want to use, their app fails on their MQ call, and apparently establishes a new connection, fails again, and the cycle repeats, over and over and over and over and over very rapidly. Until you run out of available connections.
Turn on Authority Events, or use MQ App Activity Trace or, I don't know, look at the app code and see what all the requested options are. If they are appropriate, grant them. If they are not, change the code to not specify them.
Some lazy programmers simply request every potential option on every MQ API call, "just in case".
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| vsathyan |
| Posted: Thu Jan 01, 2015 10:40 am Post subject: |
|
|
Centurion
Joined: 10 Mar 2014
Posts: 121
|
@Bruce,
I agree +allmqi is not a solution, but at this point it is working fine.
As mentioned in one of my older post - that is what i'm going to do. Do a binary series to turn on or off each of the permissions in allmqi and identify which one is causing the issue.
allmqi authority is equivalent to the union of the individual authorities altusr, browse, connect, get, inq, pub, put, resume, set, and sub appropriate to the object type.
For a queue, 6 of the above are valid and I'll do all the 63 possible combinations to identify the one which is failing.
Still, nothing is written to error logs even after the issue occurs? I dont know why.. 
Hope you all had a nice new year party yesterday  |
|
| Back to top |
|
|
| PaulClarke |
| Posted: Thu Jan 01, 2015 11:11 am Post subject: |
|
|
Grand Master
Joined: 17 Nov 2005
Posts: 1002
Location: New Zealand
|
Why would you want to got through the pain of trying 63 combinations? Do as Peter suggests...switch on authority events and browse the message with something which understands event messages. Then you can easily see who did what to whom and what failed.
Cheers,
Paul.
_________________
Paul Clarke
MQGem Software
www.mqgem.com |
|
| Back to top |
|
|
| vsathyan |
| Posted: Thu Jan 01, 2015 8:32 pm Post subject: |
|
|
Centurion
Joined: 10 Mar 2014
Posts: 121
|
Dumb me!
Thats much much better. I'll do that.
Thanks Paul & Peter.
Happy new year! |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Sat Jan 03, 2015 12:55 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20757
Location: LI,NY
|
And just in case you forgot: JMS (or XMS) will require the +inq permission on top of the regular permissions needed.
However apart from the permission setting you should also look into the exception handling of your app. There is obviously something going wrong there...
_________________
MQ & Broker admin |
|
| Back to top |
|
|
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
