| Author |
Message
|
| inderjeetdhillon |
 Posted: Fri Aug 30, 2013 6:01 am Post subject: |
 |
|
Newbie
Joined: 28 Aug 2013
Posts: 9
|
| Vitor wrote: |
| inderjeetdhillon wrote: |
| i am trying to create a monitor which is more reliable than the throughput monitor for the consumer app. |
Well as we've said, your method is not reliable.
| inderjeetdhillon wrote: |
| Do you think the following link will be helpful |
It does describe the MQINQ facility mentioned in this thread as a better option.
In your position I'd be more interested in developing techniques to identify what causes the throughput of the consumer to drop than a monitor to identify when it happens.
It's like building a burgler alarm that can identify to the second when your house is being broken into rather than reinforcing all the doors and replacing the locks. |
I agree with you 100% ! i just thought it will give me some breathing space while i investigate the consumer issues... |
|
| Back to top |
|
 |
| exerk |
| Posted: Fri Aug 30, 2013 6:11 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| inderjeetdhillon wrote: |
| Vitor wrote: |
| inderjeetdhillon wrote: |
| i am trying to create a monitor which is more reliable than the throughput monitor for the consumer app. |
Well as we've said, your method is not reliable.
| inderjeetdhillon wrote: |
| Do you think the following link will be helpful |
It does describe the MQINQ facility mentioned in this thread as a better option.
In your position I'd be more interested in developing techniques to identify what causes the throughput of the consumer to drop than a monitor to identify when it happens.
It's like building a burgler alarm that can identify to the second when your house is being broken into rather than reinforcing all the doors and replacing the locks. |
I agree with you 100% ! i just thought it will give me some breathing space while i investigate the consumer issues... |
What breathing space will it give you? Surely the time would be better spent identifying the consumer issue from the outset? Who is it - your management or 'their' management - that is breathing down your neck over this?
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Fri Aug 30, 2013 6:55 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9399
Location: US: west coast, almost. Otherwise, enroute.
|
You have probably discovered that a QAlias has no depth, and thus the iteration method.
After MQOPEN of the QAlias, you are given the resolved queue name in the ResolvedQName field of the MQOD. You could MQINQ on that name, provided the other folks have not prevented that access through security rules.
_________________
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: Sun Sep 01, 2013 3:25 pm Post subject: |
|
|
Jedi
Joined: 25 Mar 2003
Posts: 2495
Location: Melbourne, Australia
|
| inderjeetdhillon wrote: |
| I am running the consumer for the queue and have noticed that the throughput of the consumer goes down once in a while, which ends up with a backlog on the queue. I had created throughput monitors but it sends false positives when the input rate is low itself, so i am trying to create a monitor which is more reliable than the throughput monitor for the consumer app. |
Are you using MQ client connection to the Queue Manager? If you add any monitoring functions on the queue that use MQ client, the overall performance will probably get worse.
Usually if the consumer throughput goes down it is due to resource constraints and not MQ. Take a close look at network utilization and the performance of your client system. The problem may also be at the Queue Manager side, it might be worthwhile asking your client to look at performance issues there too.
_________________
Glenn |
|
| Back to top |
|
|
| inderjeetdhillon |
| Posted: Tue Sep 03, 2013 8:44 am Post subject: |
|
|
Newbie
Joined: 28 Aug 2013
Posts: 9
|
I am not able to go beyond
com.ibm.mq.MQException: MQJE001: Completion Code 1, Reason 2068
at com.ibm.mq.MQManagedObject.inquire(MQManagedObject.java:269)
at com.ibm.mq.MQManagedObject.getInt(MQManagedObject.java:442)
at com.ibm.mq.MQQueue.getCurrentDepth(MQQueue.java:1819),
I am simply trying:-
qm = new MQQueueManager ("");
int openOptions = MQC.MQOO_OUTPUT |
MQC.MQOO_INQUIRE |
MQC.MQOO_INPUT_AS_Q_DEF |
MQC.MQOO_FAIL_IF_QUIESCING;
MQQueue outQ = qm.accessQueue(mQueue,
openOptions,
null, // default q manager
null, // no dynamic q name
null); // no alternate user id
depth = outQ.getCurrentDepth();
It maybe due to the access issues...
i did some investigation in the throughput issue and seems almost like the connection freezes between the consumer and queue. I would like to keep that thread separate than this though. |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Sep 03, 2013 8:50 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| inderjeetdhillon wrote: |
| It maybe due to the access issues... |
....in which case you'd expect a code associated with access, like 2035.
2068 has a specific meaning which, on the face of it, doesn't seem connected to access.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Tue Sep 03, 2013 9:53 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9399
Location: US: west coast, almost. Otherwise, enroute.
|
| inderjeetdhillon wrote: |
It maybe due to the access issues... |
Did you go to google and search 'mqrc 2068' to find out what rc 2068 means?
_________________
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 |
|
|
| inderjeetdhillon |
| Posted: Wed Sep 04, 2013 7:06 am Post subject: |
|
|
Newbie
Joined: 28 Aug 2013
Posts: 9
|
| bruce2359 wrote: |
| inderjeetdhillon wrote: |
It maybe due to the access issues... |
Did you go to google and search 'mqrc 2068' to find out what rc 2068 means? |
I did, and i thats why i am asaying i might not have access to do this operation.
I can certainly pick messages from the queue using the same credentials but different open options. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed Sep 04, 2013 7:35 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9399
Location: US: west coast, almost. Otherwise, enroute.
|
| inderjeetdhillon wrote: |
| bruce2359 wrote: |
| inderjeetdhillon wrote: |
It maybe due to the access issues... |
Did you go to google and search 'mqrc 2068' to find out what rc 2068 means? |
I did, and i thats why i am asaying i might not have access to do this operation.
I can certainly pick messages from the queue using the same credentials but different open options. |
Access implies authorization.
This http://publib.boulder.ibm.com/infocenter/wmqv7/v7r0/index.jsp?topic=%2Fcom.ibm.mq.amqzao.doc%2Ffm12690_.htm says that
| Quote: |
| On the MQINQ call, one or more selectors in the Selectors array is not applicable to the type of the queue whose attributes are being inquired. |
Which does NOT sound like authorization.
Search for the MQINQ call, and how to construct selectors.
_________________
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 |
|
|
|
|
