| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| 2035 while trying to load test using JMeter |
« View previous topic :: View next topic » |
| Author |
Message
|
| yanaK |
 Posted: Tue Jun 09, 2020 11:56 pm Post subject: |
 |
|
Acolyte
Joined: 28 May 2020
Posts: 69
|
When I run in these in the same server (OS) as the queue manager I get these:
| Code: |
> ./amqsput SF.PING PSE8
Sample AMQSPUT0 start
MQCONN ended with reason code 2035
> ./amqsputc PS.PING PSE8
Sample AMQSPUT0 start
MQCONN ended with reason code 2058
> whoami
<myuserid> |
Which makes me think that the 500 we are getting is one of these errors.
And given we are connecting fine, I think its running as client (and getting the 2058). How to fix that? Is there a way to drill down?
To add, if I login as mqm, amqsput is working while amqsputc is getting the same 2058.
Thanks for all the help. |
|
| Back to top |
|
 |
| hughson |
| Posted: Wed Jun 10, 2020 1:43 am Post subject: |
|
|
Padawan
Joined: 09 May 2013
Posts: 1914
Location: Bay of Plenty, New Zealand
|
| yanaK wrote: |
| hughson wrote: |
| yanaK wrote: |
When I do
| Code: |
| id -ng <myusername> |
from my mac, its a part of some domain users but when I do it from the MQ server its something different (called stick  )
Similarly when I do
from my mac, its a part of the same domain users as above while when I do it from MQ server, its psqr.
And mqm is a part of mqm group. |
It only matters what group it is in on the machine where the queue manager in running. |
It is the same machine where the queue manager is running. |
I appear to be somewhat confused. I thought you had two machines, a Mac (where I was assuming you were running client connections to your queue manager) and the machine where your queue manager is running. I wasn't aware that there was a queue manager for Mac (only a client). Can you clear up my confusion. Do you have one machine or two?
When you say "MQ Server" is this the same machine as your Mac?
| yanaK wrote: |
When I run in these in the same server (OS) as the queue manager I get these:
| Code: |
> ./amqsput SF.PING PSE8
Sample AMQSPUT0 start
MQCONN ended with reason code 2035
> ./amqsputc PS.PING PSE8
Sample AMQSPUT0 start
MQCONN ended with reason code 2058
> whoami
<myuserid> |
Which makes me think that the 500 we are getting is one of these errors. |
That certainly would seem possible. It's a good idea to use something simpler like a sample program, to test your setup first.
| yanaK wrote: |
And given we are connecting fine, I think its running as client (and getting the 2058). How to fix that? Is there a way to drill down?
To add, if I login as mqm, amqsput is working while amqsputc is getting the same 2058.
Thanks for all the help. |
So amqsput (local connection) is getting a 2035 - MQRC_NOT_AUTHORIZED - there should be an accompanying message in the queue manager AMQERR01.LOG to give more details there. Please add that in your next reply. It works when you login as mqm because mqm has authority to do everything, and is allowed to connect locally (will be banned by default over a client connection).
The amqsputc (client connection) is getting 2058 - MQRC_Q_MGR_NAME_ERROR. This likely means that you have not set MQSERVER environment variable, and that it is looking for a CCDT and not finding the queue manager name PSE8 in the CCDT, or not finding a CCDT at all. I assume when you run jMeter that you provide a channel name, hostname and port number somewhere in the configuration? We should replicate that setting for the amqsputc sample to replicate the behaviour jMeter sees.
Both of these errors are failing on the connection, but if you are using the same user id that you are using to run your jMeter application, then they are likely suffering from the same problems.
Cheers,
Morag
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
| Back to top |
|
|
| yanaK |
| Posted: Thu Jun 11, 2020 12:23 am Post subject: |
|
|
Acolyte
Joined: 28 May 2020
Posts: 69
|
| Quote: |
| I appear to be somewhat confused. I thought you had two machines, a Mac (where I was assuming you were running client connections to your queue manager) and the machine where your queue manager is running. I wasn't aware that there was a queue manager for Mac (only a client). Can you clear up my confusion. Do you have one machine or two? |
Two - a Mac and a machine where the queue manager is running.
| Quote: |
When you say "MQ Server" is this the same machine as your Mac?
|
It is where the queue manager is running.
Sorry for the confusion.
For the 2035 error this is what I see in AMQERR01.LOG:
| Code: |
AMQ8077: Entity '<myuserid> ' has insufficient authority to access object
'PSE8'.
|
From my mac this error was:
| Code: |
AMQ8077: Entity 'psqr ' has insufficient authority to access object
'PSE8'.
|
Why this difference?
And once I set MQSERVER the amqsputc is working fine. Thanks! |
|
| Back to top |
|
|
| hughson |
| Posted: Thu Jun 11, 2020 7:35 pm Post subject: |
|
|
Padawan
Joined: 09 May 2013
Posts: 1914
Location: Bay of Plenty, New Zealand
|
| yanaK wrote: |
For the 2035 error this is what I see in AMQERR01.LOG:
| Code: |
AMQ8077: Entity '<myuserid> ' has insufficient authority to access object
'PSE8'.
|
From my mac this error was:
| Code: |
AMQ8077: Entity 'psqr ' has insufficient authority to access object
'PSE8'.
|
Why this difference? |
You are using a different user ID it would seem. Do you expect to be using the same user id?
Since we have confirmed that you have two machines, I'll reiterate my earlier statement, the command that shows the primary group of a user ID should be run on the queue manager machine, not on the Mac. It only matters what group the user ID in question is in on the queue manager machine, since that is where the authority checks are being made.
This was important, if you recall, because if you assign authority to a user, by default, it is actually set on the primary group of that user.
To see the authority that each user ID has on the queue manager object PSE8, you can issue the following MQSC command (using something like runmqsc).
| Code: |
| DISPLAY ENTAUTH PRINCIPAL('<myuserid>') OBJTYPE(QMGR) |
| Code: |
| DISPLAY ENTAUTH PRINCIPAL('psqr') OBJTYPE(QMGR) |
This command figures out the set of authority you have from all the groups your ID is in.
If you want to see the authorities that are granted to specific groups or users directly (so not the combined full set like the above command), then you can use this command:
| Code: |
| DISPLAY ENTAUTH GROUP('<group-name>') OBJTYPE(QMGR) |
Cheers,
Morag
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
| Back to top |
|
|
| yanaK |
| Posted: Tue Jun 16, 2020 11:49 pm Post subject: |
|
|
Acolyte
Joined: 28 May 2020
Posts: 69
|
Thanks. So I gave my user id the exact same permission as the psqr and verified by using the command
| Code: |
DISPLAY ENTAUTH PRINCIPAL('<myuserid>') OBJTYPE(QMGR)
|
- they both have the same AUTHLIST
Now when I run the test I see this error in the log:
| Code: |
----- amqrmrca.c : 1044 -------------------------------------------------------
06/17/2020 11:20:40 AM - Process(3812.97) User(mqm) Program(amqrmppa)
Host(z3421) Installation(Installation1)
VRMF(7.1.0.1) QMgr(PSE8)
AMQ9544: Messages not put to destination queue.
EXPLANATION:
During the processing of channel 'TO. PSE3' 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 '3812'. |
May be this is the reason for 500.
I checked the DLQ and didn't find anything interesting e.g. CURDEPTH was 0.
Now the question is why don't I get it while running from local mac? I know this is running as mqm (vs when I run from mac its running as psqr?) and probably that is the only difference. So likely I've to run as psqr even when I'm running from local MQ o/s - am I thinking right? |
|
| Back to top |
|
|
| hughson |
| Posted: Wed Jun 17, 2020 1:19 am Post subject: |
|
|
Padawan
Joined: 09 May 2013
Posts: 1914
Location: Bay of Plenty, New Zealand
|
| yanaK wrote: |
Now when I run the test I see this error in the log:
| Code: |
----- amqrmrca.c : 1044 -------------------------------------------------------
06/17/2020 11:20:40 AM - Process(3812.97) User(mqm) Program(amqrmppa)
Host(z3421) Installation(Installation1)
VRMF(7.1.0.1) QMgr(PSE8)
AMQ9544: Messages not put to destination queue.
EXPLANATION:
During the processing of channel 'TO. PSE3' 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 '3812'. |
May be this is the reason for 500.
I checked the DLQ and didn't find anything interesting e.g. CURDEPTH was 0. |
Were you checking the local or remote DLQ? This error message tells you that it is the remote DLQ, that is, the DLQ on the queue manager at the other end of the channel from this error message.
| yanaK wrote: |
Thanks. So I gave my user id the exact same permission as the psqr and verified by using the command
| Code: |
DISPLAY ENTAUTH PRINCIPAL('<myuserid>') OBJTYPE(QMGR)
|
- they both have the same AUTHLIST |
That command is only checking the authorities on the queue manager object, I suspect we might have to do the same thing for some queues as well. The DLQ message will help to know exactly what.
Cheers,
Morag
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
| Back to top |
|
|
| yanaK |
| Posted: Thu Jun 18, 2020 1:31 am Post subject: |
|
|
Acolyte
Joined: 28 May 2020
Posts: 69
|
Ah yes. Thanks - I see the remote DLQ has 790 CURDEPTH.
I did a ./amqsget on it and cleared it up. I'll retry the tests and try to read the DLQ message. Btw what is the command to read DLQ message?
And one related question comes to my mind - I've multiple applications (say APP1 and APP2) writing to a QLOCAL (SYSTEM.CLUSTER.TRANSMIT.QUEUE) of QM1 which then goes to another MQ (say QM2) which has the destination queues (say APP1SPECIFIC.REQ and APP2SPECIFIC.REQ) - how does the APP1SPECIFIC.REQ know which message to read from SYSTEM.CLUSTER.TRANSMIT.QUEUE in the source? Where is this configured?
Thanks for all your help. |
|
| Back to top |
|
|
| hughson |
| Posted: Thu Jun 18, 2020 2:32 am Post subject: |
|
|
Padawan
Joined: 09 May 2013
Posts: 1914
Location: Bay of Plenty, New Zealand
|
| yanaK wrote: |
| I'll retry the tests and try to read the DLQ message. Btw what is the command to read DLQ message? |
You just need a tool that can format out the DLQ header - MQ Explorer, Q, MO71, and many others, can do this for you.
| yanaK wrote: |
| And one related question comes to my mind - I've multiple applications (say APP1 and APP2) writing to a QLOCAL (SYSTEM.CLUSTER.TRANSMIT.QUEUE) of QM1 which then goes to another MQ (say QM2) which has the destination queues (say APP1SPECIFIC.REQ and APP2SPECIFIC.REQ) - how does the APP1SPECIFIC.REQ know which message to read from SYSTEM.CLUSTER.TRANSMIT.QUEUE in the source? Where is this configured? |
The messages are not pulled from the SYSTEM.CLUSTER.TRANSMIT.QUEUE by APP1SPECIFIC.REQ and APP2SPECIFIC.REQ. Instead the channel that moves the message from the SYSTEM.CLUSTER.TRANSMIT.QUEUE on QM1 over the network to QM2, sends with the message the details of the target queue. The receiver channel that reads the message from the network and has the responsibility of putting it to the target queue, reads those details and uses them to put to the correct target queue.
In case you're interested in seeing it in action, you can stop a channel, and then you can browse the messages on a transmission queue and you will see an extra header has been added to the message called an MQXQH. This contains the target queue name and the target queue manager name. The receiver channel strips this header off when it puts it to the application queue, so you never see it outside of the transmission queue.
Cheers,
Morag
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
| Back to top |
|
|
| yanaK |
| Posted: Thu Jun 18, 2020 8:09 am Post subject: |
|
|
Acolyte
Joined: 28 May 2020
Posts: 69
|
Thanks
| Quote: |
| MQ Explorer, Q, MO71, and many others, can do this for you. |
Are these all UI based tools? Is there anything for RHEL? |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Jun 18, 2020 10:44 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| yanaK wrote: |
Thanks
| Quote: |
| MQ Explorer, Q, MO71, and many others, can do this for you. |
Are these all UI based tools? Is there anything for RHEL? |
Of the list given, Q is command line based. Other command line toold are undoubtably available.
In a worst case scenario, you could take the source code of the amqsdlq sample, which obviously contains the layout of the DLQ, adapt it for your needs / comfort, and compile it for RHEL.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Jun 18, 2020 12:28 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9396
Location: US: west coast, almost. Otherwise, enroute.
|
| yanaK wrote: |
Thanks
| Quote: |
| MQ Explorer, Q, MO71, and many others, can do this for you. |
Are these all UI based tools? Is there anything for RHEL? |
MQExplorer runs on RHEL. You alsocan use the supplied amqsbcg to display the DLH.
_________________
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 |
|
|
| hughson |
| Posted: Thu Jun 18, 2020 7:13 pm Post subject: |
|
|
Padawan
Joined: 09 May 2013
Posts: 1914
Location: Bay of Plenty, New Zealand
|
| yanaK wrote: |
| Quote: |
| MQ Explorer, Q, MO71, and many others, can do this for you. |
Are these all UI based tools? Is there anything for RHEL? |
Do you want something that runs on RHEL or something that runs on a command line? All three of those will run on RHEL, MQ Explorer and MO71 are UI based tools. Q is command line.
You can also just hex dump the message as suggested using amqsbcg IBM-supplied sample, and then pick out the reason code from the hex, but it is much nicer to have the tool do the work for you! 
Also, all these tools can run as a client from another machine connecting to your RHEL queue manager machine if that is required too.
Tool choice is often a personal preference. If you're going to be working with MQ going forward, you should find one you like. Good tools make the experience so much better (or am I just biased  )
Cheers,
Morag
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
| Back to top |
|
|
| yanaK |
| Posted: Fri Jun 19, 2020 12:37 am Post subject: |
|
|
Acolyte
Joined: 28 May 2020
Posts: 69
|
Thanks all!
I need something that runs on command line - and I am trying Q - it works for me
So now I do this:
I do amqsget for QLOCAL PING (we've a ping queue) and SYSTEM.CLUSTER.TRANSMIT.QUEUE in the source queue manager (Correct me if I am wrong but since my test puts and gets from a queue in this queue manager, I probably don't need to involve the destination queue manager for this test)
I run the load tests from the OS local to the queue as me (not as mqm) - the load test basically puts (and gets) few ~50 messages (A string called "Hello from Jmeter" to PING queue on PS.SRC channel):
1. Then I check AMQERR01.LOG on source queue manager - no error (which baffles me given if there was a permission error it should've been here - right?)
2. I did set permission on the queue and verified it (am I missing some permission?):
| Code: |
1 : DISPLAY ENTAUTH PRINCIPAL (<myuserid>) OBJTYPE(QUEUE) OBJNAME (PING)
AMQ8866: Display entity authority details.
OBJNAME(PING) ENTITY(<myuserid>)
ENTTYPE(PRINCIPAL) OBJTYPE(QUEUE)
AUTHLIST(BROWSE,DSP,GET,INQ,PUT)
|
The psqr user has few more though - AUTHLIST(BROWSE,CHG,CLR,DLT,DSP,GET,INQ,PUT,PASSALL,PASSID,SET,SETALL,SETID)
3. Assuming its a permission issue - what else do I need to set auth on? (I've this permissions on QMGR - AUTHLIST(ALTUSR,CONNECT,DSP,INQ,SET,SETALL,SETID) and I checked the channel and listener permissions for psqr and they are empty)
4. And I see the same 500s in the test output. |
|
| Back to top |
|
|
| hughson |
| Posted: Fri Jun 19, 2020 1:44 am Post subject: |
|
|
Padawan
Joined: 09 May 2013
Posts: 1914
Location: Bay of Plenty, New Zealand
|
Can you post the output like you did in the very first post of this thread. Are you still seeing something similar to that?
Yes, if you're still getting a 2035 then there should be something in the AMQERR01.LOG - you are checking the error log in $MQ_DATA_PATH/Qmgrs/PSE8/errors ?
In order to know what permissions you are missing, we need to read the error message that tells us what they are.
Cheers,
Morag
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Fri Jun 19, 2020 4:58 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20696
Location: LI,NY
|
The data path may not be what Morag showed.
run dspmqinf PSE8 (assuming your queue manager is PSE8 )
if you have a DataPath line your path is DataPath Value + errors directory
else your path is
Prefix value + qmgrs + directory value + errors
Of course with the appropriate directory / file separator. enjoy 
_________________
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
|
|
|
|
