Author |
Message
|
yanaK |
Posted: Wed Jun 03, 2020 11:54 pm Post subject: 2035 while trying to load test using JMeter |
|
|
Acolyte
Joined: 28 May 2020 Posts: 69
|
I am trying load test a queue manager (MQ 7.1.0.7) using Jmeter 7.3 and the mqmeter plugin (https://github.com/JoseLuisSR/mqmeter).
I am trying to run from my local mac (with user_id = mqm) to the queue manager server (RHEL 7) and I keep on getting this:
Code: |
2020-06-04 00:27:54,072 INFO c.s.m.MQClientSampler: MQ Manager properties are hostname: z3421 port: 1422 channel: SFO.PS
2020-06-04 00:27:54,072 INFO c.s.m.MQClientSampler: Connecting to queue manager MQPS3
2020-06-04 00:27:54,073 INFO o.a.j.t.ThreadGroup: Started thread group number 1
2020-06-04 00:27:54,073 INFO o.a.j.e.StandardJMeterEngine: All thread groups have been started
2020-06-04 00:27:56,076 INFO o.a.j.t.JMeterThread: Thread started: PutGetMessages 1-2
2020-06-04 00:27:56,077 INFO c.s.m.MQClientSampler: MQ Manager properties are hostname: z3421 port: 1422 channel: SFO.PS
2020-06-04 00:27:56,077 INFO c.s.m.MQClientSampler: Connecting to queue manager MQPS3
2020-06-04 00:27:56,783 INFO c.s.m.MQClientSampler: setupTest MQJE001: Completion Code '2', Reason '2035'. MQRC_NOT_AUTHORIZED
2020-06-04 00:27:56,784 INFO c.s.m.MQClientSampler: Accessing queue: SYSTEM.CLUSTER.TRANSMIT.QUEUE to put message.
2020-06-04 00:27:56,784 ERROR o.a.j.t.JMeterThread: Error while processing sampler: 'PutGetMessage'.
java.lang.NullPointerException: null
at co.signal.mqmeter.MQClientSampler.setupTest(MQClientSampler.java:206) ~[mqmeter-2.1.0.jar:?]
at org.apache.jmeter.protocol.java.sampler.JavaSampler.sample(JavaSampler.java:194) ~[ApacheJMeter_java.jar:5.3]
at org.apache.jmeter.threads.JMeterThread.doSampling(JMeterThread.java:630) ~[ApacheJMeter_core.jar:5.3]
at org.apache.jmeter.threads.JMeterThread.executeSamplePackage(JMeterThread.java:558) ~[ApacheJMeter_core.jar:5.3]
at org.apache.jmeter.threads.JMeterThread.processSampler(JMeterThread.java:489) [ApacheJMeter_core.jar:5.3]
at org.apache.jmeter.threads.JMeterThread.run(JMeterThread.java:256) [ApacheJMeter_core.jar:5.3]
at java.lang.Thread.run(Thread.java:834) [?:?] |
I've verified with dspmqaut that it has the following permissions:
Code: |
Entity mqm has the following authorizations for object SYSTEM.CLUSTER.TRANSMIT.QUEUE:
get
browse
put
inq
set
crt
dlt
chg
dsp
passid
passall
setid
setall
clr |
When I try to run from the local RHEL server, I get a 500 too. What am I missing here? What should that user_id be?
I even tried with a different user, set auth for put and get and even set channel auth to USERLIST(ALLOWANY) but no luck.
Any help (or general pointers on load testing MQ) is appreciated.
Last edited by yanaK on Thu Jun 04, 2020 12:23 am; edited 1 time in total |
|
Back to top |
|
|
exerk |
Posted: Thu Jun 04, 2020 12:19 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006 Posts: 6339
|
The error logs of queue manager MQPS3 should show the exact issue. You should see something like:
Code: |
AMQ8077W: Entity 'xxxxxxxx' has insufficient authority to access object 'SYSTEM.CLUSTER.TRANSMIT.QUEUE'.
EXPLANATION:
The specified entity is not authorized to access the required object. The following requested permissions are unauthorized: ???????? |
Either the user being passed to the queue manager may not be what you think it is, especially as mqm should not generate any authorisation errors.
Posting any CHLAUTH rules you have set, including back-stop etc., would be helpful in diagnosing the issue.
Also, the version of MQ you're using is no longer supported. _________________ 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 |
|
|
yanaK |
Posted: Thu Jun 04, 2020 12:43 am Post subject: |
|
|
Acolyte
Joined: 28 May 2020 Posts: 69
|
Thanks @exerk
When I look at AMQERR01.LOG I see:
Code: |
AMQ8077: Entity '2xsk ' has insufficient authority to access object
'MQPS3'.
EXPLANATION:
The specified entity is not authorized to access the required object. The
following requested permissions are unauthorized: connect |
When I try to setmqaut with +connect I get this (in fact +connect is failing for other users too):
Code: |
AMQ7097: You gave an authorization specification that is not valid. |
What other permissions do I need to run this test?
However those errors occurred 30min back (while I am running the test from mq box now) - may be those were from the time when I was trying to connect from my dev box.
Posting any CHLAUTH rules you have set
Is there a command for that?
the version of MQ you're using is no longer supported.
I know due for upgrade.
Last edited by yanaK on Thu Jun 04, 2020 12:49 am; edited 1 time in total |
|
Back to top |
|
|
exerk |
Posted: Thu Jun 04, 2020 12:49 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006 Posts: 6339
|
And the entity shown is your user ID on the Mac? If so, that user will most likely not exist on the RHEL server, hence the failure.
The DIS CHLAUTH command will give you the output you need and the Knowledge Centre (KC) gives you the correct syntax.
Google Morag Hughson's articles on CHLAUTH, which deal with mapping to an ID etc. (all hail the wondrous Morag!). _________________ 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 |
|
|
yanaK |
Posted: Thu Jun 04, 2020 12:59 am Post subject: |
|
|
Acolyte
Joined: 28 May 2020 Posts: 69
|
May be I did something wrong here - when I do dis chlauth (SFO.PS) I get record not found. But if I do for sfo.ps,, I get the USERLIST(ALLOWANY) back which show its case-sensitive. The rest are:
Code: |
AMQ8878: Display channel authentication record details.
CHLAUTH(SYSTEM.ADMIN.SVRCONN) TYPE(ADDRESSMAP)
ADDRESS(*) USERSRC(CHANNEL)
AMQ8878: Display channel authentication record details.
CHLAUTH(SYSTEM.*) TYPE(ADDRESSMAP)
ADDRESS(*) USERSRC(NOACCESS)
AMQ8878: Display channel authentication record details.
CHLAUTH(*) TYPE(BLOCKUSER)
USERLIST(*MQADMIN) |
I can try setting the SFO.PS channel to ALLOWANY but before that I'd like to try other options if any.
And the entity shown is your user ID on the Mac? If so, that user will most likely not exist on the RHEL server, hence the failure.
Yes it is the user id on mac and it has an account in the RHEL server - and why then it also fails when I login to the RHEL server as mqm and run the test?
I don't get MQ auth model
|
|
Back to top |
|
|
exerk |
Posted: Thu Jun 04, 2020 1:28 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006 Posts: 6339
|
MQ is very much case-sensitive, which is something that catches everyone at some time.
yanaK wrote: |
May be I did something wrong here - when I do dis chlauth (SFO.PS) I get record not found. But if I do for sfo.ps,, I get the USERLIST(ALLOWANY) back which show its case-sensitive. The rest are:
Code: |
AMQ8878: Display channel authentication record details.
CHLAUTH(SYSTEM.ADMIN.SVRCONN) TYPE(ADDRESSMAP)
ADDRESS(*) USERSRC(CHANNEL)
AMQ8878: Display channel authentication record details.
CHLAUTH(SYSTEM.*) TYPE(ADDRESSMAP)
ADDRESS(*) USERSRC(NOACCESS)
AMQ8878: Display channel authentication record details.
CHLAUTH(*) TYPE(BLOCKUSER)
USERLIST(*MQADMIN) |
I can try setting the SFO.PS channel to ALLOWANY but before that I'd like to try other options if any. |
yanaK wrote: |
...And the entity shown is your user ID on the Mac? If so, that user will most likely not exist on the RHEL server, hence the failure.
Yes it is the user id on mac and it has an account in the RHEL server... |
Because the entity will require ALL necessary authorities; see the KC for setmqaut and the required syntax.
yanaK wrote: |
...and why then it also fails when I login to the RHEL server as mqm and run the test?... |
Most likely because you're running the test application as an MQ Client, and even as 'mqm' you'll be blocked. That feature is to stop people presenting their user ID as 'mqm' and getting god rights to a queue manager.
yanaK wrote: |
...I don't get MQ auth model
|
You're in good company. There are people whom have worked with MQ for years and still don't! (I know, I'm one of them).
Again, google Morag's articles; they're full of useful and top-notch information and you can use them to walk you through the right way to achieve what you want.
Additionally, as you are using queue manager clustering (as evidenced by your original post) consider using a QALIAS (QA) to reference the cluster queues (giving the necessary authorities for the userid to the QA) - old school style - or setting the ClusterQueueAccessControl attribute of the qm.ini Security stanza.
CAVEAT: I don't have a copy of the KC for the version you're testing against so I'm not sure if ClusterQueueAccessControl is applicable.
Lastly, are you relatively new to MQ? If so, push back on management and ask for training. _________________ 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 |
|
|
yanaK |
Posted: Thu Jun 04, 2020 8:45 am Post subject: |
|
|
Acolyte
Joined: 28 May 2020 Posts: 69
|
Yes my experience with MQ is little over a month
Because the entity will require ALL necessary authorities; see the KC for setmqaut and the required syntax.
So theoretically if I assign +all to a user, should it work? What is KC?
Most likely because you're running the test application as an MQ Client, and even as 'mqm' you'll be blocked
Then why it works when I run amqsput ? (I'm running as the same user)
I'll go through the articles.
Also did you mean either try QALIAS or ClusterQueueAccessControl (or both)?
Thanks for all the help. Truly appreciate it. |
|
Back to top |
|
|
Vitor |
Posted: Thu Jun 04, 2020 9:10 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
Knowledge Center. The product documentation.
yanaK wrote: |
Then why it works when I run amqsput ? (I'm running as the same user) |
Because amqsput doesn't use the client; amqsputc uses the client.
yanaK wrote: |
Also did you mean either try QALIAS or ClusterQueueAccessControl (or both)? |
QALIAS _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
|
Vitor |
Posted: Thu Jun 04, 2020 9:14 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
exerk wrote: |
There are people whom have worked with MQ for years and still don't! (I know, I'm one of them). |
Oh Lord, grant me the strength to resist this temptation.....
exerk wrote: |
Again, google Morag's articles; they're full of useful and top-notch information and you can use them to walk you through the right way to achieve what you want. |
@morag is the Almighty Godess of MQ Security.
All shall bow before her, and bathe in the generous light of her knowledge. _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
|
exerk |
Posted: Thu Jun 04, 2020 9:19 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006 Posts: 6339
|
Vitor wrote: |
Oh Lord, grant me the strength to resist this temptation..... |
Do I detect a soupcon of mellowing as your years march onward? _________________ 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 |
|
|
yanaK |
Posted: Thu Jun 04, 2020 1:31 pm Post subject: |
|
|
Acolyte
Joined: 28 May 2020 Posts: 69
|
So I defined a QALIAS:
Code: |
QUEUE(QALIAS.PL) TYPE(QALIAS)
ALTDATE(2020-06-04) ALTTIME(12.32.07)
TARGET(SYSTEM.CLUSTER.TRANSMIT.QUEUE) CLUSNL( )
CLUSTER( ) CLWLPRTY(0)
CLWLRANK(0) CUSTOM( )
DEFBIND(OPEN) DEFPRTY(0)
DEFPSIST(NO) DEFPRESP(SYNC)
DEFREADA(NO) DESCR(Alias for PL)
GET(ENABLED) PUT(ENABLED)
PROPCTL(COMPAT) SCOPE(QMGR)
TARGTYPE(QUEUE) |
And then gave +all auth to the user. And I still see 2035. What might be missing?
Code: |
$:/opt/mqm/samp/bin$ ./amqsputc QALIAS.PL MQPS3
Sample AMQSPUT0 start
MQCONN ended with reason code 2035 |
What is missing? |
|
Back to top |
|
|
bruce2359 |
Posted: Thu Jun 04, 2020 2:34 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008 Posts: 9442 Location: US: west coast, almost. Otherwise, enroute.
|
yanaK wrote: |
And then gave +all auth to the user. And I still see 2035. What might be missing?
$:/opt/mqm/samp/bin$ ./amqsputc QALIAS.PL MQPS3
Sample AMQSPUT0 start
MQCONN ended with reason code 2035
What is missing? |
What got written to the AMQERR01.LOG of the affected qmgr? What username? _________________ 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 |
|
|
yanaK |
Posted: Thu Jun 04, 2020 2:53 pm Post subject: |
|
|
Acolyte
Joined: 28 May 2020 Posts: 69
|
Interestingly I don't see any auth errors in that log. Instead during that time I see this:
Code: |
----- amqrmrca.c : 1044 -------------------------------------------------------
06/04/2020 02:29:47 PM - Process(9143.11108) User(mqm) Program(amqrmppa)
Host(z3421) Installation(Installation1)
VRMF(7.1.0.7) QMgr(MQPS3)
AMQ9544: Messages not put to destination queue.
EXPLANATION:
During the processing of channel 'TO.BQPS3' one or more messages could not
be put to the destination queue and attempts were made to put them to a
dead-letter queue. The location of the queue is 2, where 1 is the local
dead-letter queue and 2 is the remote dead-letter queue.
ACTION:
Examine the contents of the dead-letter queue. Each message is contained in a
structure that describes why the message was put to the queue, and to where it
was originally addressed. Also look at previous error messages to see if the
attempt to put messages to a dead-letter queue failed. The program identifier
(PID) of the processing program was '9143'. |
May be unrelated though.
So just to make sure, we've to create a QALIAS, point to the target queue and set auth +all for the user I'm load testing with - right? Any other step? Also to I need to restart queue manager after these?
Again, thanks for all your help. |
|
Back to top |
|
|
bruce2359 |
Posted: Thu Jun 04, 2020 3:43 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008 Posts: 9442 Location: US: west coast, almost. Otherwise, enroute.
|
yanaK wrote: |
Interestingly I don't see any auth errors in that log. Instead during that time I see this:
Code: |
----- amqrmrca.c : 1044 -------------------------------------------------------
06/04/2020 02:29:47 PM - Process(9143.11108) User(mqm) Program(amqrmppa)
Host(z3421) Installation(Installation1)
VRMF(7.1.0.7) QMgr(MQPS3)
AMQ9544: Messages not put to destination queue.
EXPLANATION:
During the processing of channel 'TO.BQPS3' one or more messages could not
be put to the destination queue and attempts were made to put them to a
dead-letter queue. The location of the queue is 2, where 1 is the local
dead-letter queue and 2 is the remote dead-letter queue.
ACTION:
Examine the contents of the dead-letter queue. Each message is contained in a
structure that describes why the message was put to the queue, and to where it
was originally addressed. Also look at previous error messages to see if the
attempt to put messages to a dead-letter queue failed. The program identifier
(PID) of the processing program was '9143'. |
May be unrelated though.
So just to make sure, we've to create a QALIAS, point to the target queue and set auth +all for the user I'm load testing with - right? Any other step? Also to I need to restart queue manager after these?
Again, thanks for all your help. |
An MQCONNect failure has nothing to do with queues; rather, your app failed to connect to the qmgr - had insufficient authority to do so.
What username is logged onto the shell where you attempt to connect to qmgr MQPS3? Try the UNIX whoami command in the same shell before you attempt the amqsputc command. _________________ 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 |
|
|
yanaK |
Posted: Thu Jun 04, 2020 5:22 pm Post subject: |
|
|
Acolyte
Joined: 28 May 2020 Posts: 69
|
the username is mqm.
And I've reached some success - amqsputc seems to be working:
Code: |
$:/opt/mqm/samp/bin$ ./amqsputc QALIAS.PL MQPS3
Sample AMQSPUT0 start
target queue is QALIAS.PL |
Now when I try to run the tests from my mac I see this error:
Code: |
----- amqrmrsa.c : 939 --------------------------------------------------------
06/04/2020 05:21:48 PM - Process(27940.124) User(mqm) Program(amqzlaa0)
Host(z3421) Installation(Installation1)
VRMF(7.1.0.7) QMgr(MQPS3)
AMQ8077: Entity 'psqr ' has insufficient authority to access object
'MQPOSE8A1'.
EXPLANATION:
The specified entity is not authorized to access the required object. The
following requested permissions are unauthorized: inq
ACTION:
Ensure that the correct level of authority has been set for this entity against
the required object, or ensure that the entity is a member of a privileged
group.
----- amqzfubx.c : 618 --------------------------------------------------------
06/04/2020 05:21:49 PM - Process(27940.125) User(mqm) Program(amqzlaa0)
Host(z3421) Installation(Installation1)
VRMF(7.1.0.7) QMgr(MQPS3)
AMQ8077: Entity 'psqr ' has insufficient authority to access object
'MQPS3'.
EXPLANATION:
The specified entity is not authorized to access the required object. The
following requested permissions are unauthorized: inq
ACTION:
Ensure that the correct level of authority has been set for this entity against
the required object, or ensure that the entity is a member of a privileged
group. |
I then ran this:
Quote: |
setmqaut -m MQPS3 -t qmgr -p psqr +all
|
And all the load tests (from my mac) are running successfully!
However when I login to the MQ server (as mqm) and run the same test, I get Errors.
I see nothing in the logs though.
It doesn't work even if I explicitly specify psqr in the test config.
I logout and login as me and retry - same result.
What might be missing from the same server? |
|
Back to top |
|
|
|