More than 4MB response from IBM MQ in Jmeter - jmeter

I am trying to run some load tests on jmeter by connecting to IBM MQ. It works fine except for a particular message which get a close to 5 MB response.
So, here's the setup, I push a message from jmeter to a request queue on IBM MQ. My was app picks it up and sends a response to the response queue where the JMETER picks it up. This setup works fine, till i send a particular message whose response is close to 5MB.
The jmeter simply doesn't pick this response and that in turn holds up all the other messages on the response queue.
I think the default recieve size for jmeter is 4MB, but can i change it for MQ response in jmeter properties somewhere.
I tried by making changes to user.properties and jmeter.properties in jmeter bin directory but nothing worked.

The exception thrown is related to MQJMS. So check the linked exception for MQ reason code returned. If you are connecting to queue manager using a client mode connection, then check the MAXMSGL attribute of the Server Connection channel you are using. By default the MAXMSGL is set to 4 MB. You will need to increase the attribute value to larger messages.

Related

Websphere MQ XMS Event Poll Time

I use websphere mq xms.net infrastructure to async message listening.My problem is sometimes there are messages in queue but xms cannot read them on time and waiting 1,2... 5 minutes wait and then get the message.Is there any configuration on xms for that something like event poll interval time ...?Sometimes I got message directly sometimes not?
You are using XMS .NET version 8.0.0.8. I am not sure what value you have set for the XMSC.WMQ_PROVIDER_VERSION property. The default value is "unpspecified" as documented here.
Update:
Apologies. I just checked documentation and IBM.XMS.XMSC.WMQ_POLLING_INTERVAL is valid for MQ 7 and above.
However XMSC.RTT_BROKER_PING_INTERVAL property is not valid when connecting MQ queue manager. It is valid only for Real Time Transport of Message Broker and RTT is no longer supported.
Are you connecting to MQ v6 queue manager by any chance?
I suggest you to not set IBM.XMS.XMSC.WMQ_POLLING_INTERVAL property. The messages should be delivered as soon as they arrive in queue and application is ready to receive.

MQ: Queue is not able to accept 4 MB of message

Queue is not able to accept message greater than 4 MB even though MAXMSGL set to 100 MB on the Queue Manager, Queue, DLQ, SVRCONN and CLNTCONN and provided updated channel tab to application team. This didn't resolved the issue (restarted queue manager as well).
Application team is posting the messages using service/job.
Whereas same job is able to connect and post 4+ MB of message to different queue manager running on different server.
MQ Client Version: 7.5.0.2
MQ Server Version: 7.5.0.3
I tried to post 4+ MB message to the queue using RFHUtil it is successful. But somehow it is failing to send message from application/job.
Issue found once we enabled trace on the client machine. It is observed application is using old channel tab even though entries in environment variables referring to new channel tab.
Restarted MQ Client machine and tested flow by enabling trace and this time it worked as expected and application/job able to post the message greater than 4 MB.

removing RFH header from websphere mq

I'm using jmeter to put message to websphere mq and my another program will pick up that message from mq queue.
When I put manually to mq queue, the message I pick up from my program is exactly the same message I put.
However, when I put message to mq queue using jmeter, the message I pick up from my program became 'RFH :)'. I guess I need to remove RFH header or change the way to put message using Jmeter.
any pointer would be appreciated
Thanks
thank you #siarheib. I set property control to 'None' for message queue. and It works.

MQ Input/Output count increasing when Datapower client is connect using MQ front side handler

I am using MQ 7.5.0.2 and Datapower client IDG7
When MQ send messages to Datapower, Datapower receive those messages using MQ front side handlers and also same way it do send messages using Backend URL
But the problem I am facing it when ever Datapower connects to MQ, Queue Input/Output count increases to (10 ~20) and remains same and the Handle state is INACTIVE.
When I see queue details using below commands it is displaying as below
display qstatus(******) type(handle)
QUEUE(********) TYPE(HANDLE)
APPLDESC(WebSphere MQ Channel)
APPLTAG(WebSphere Datapower MQClient)
APPLTYPE(SYSTEM) BROWSE(NO)
CHANNEL(*****) CONNAME(******)
ASTATE(NONE) HSTATE(INACTIVE)
INPUT(SHARED) INQUIRE(NO)
OUTPUT(NO) PID(25391)
QMURID(0.1149) SET(NO)
TID(54)
URID(XA_FORMATID[] XA_GTRID[] XA_BQUAL[])
URTYPE(QMGR)
Can any one help me in this.It only clearing when ever i restart the queue manager but I dont want to restart the qmgr every time.
HSTATE in INACTIVE state indicates "No API call from a connection is currently in progress for this object. For a queue, this condition can arise when no MQGET WAIT call is in progress.". This is likely to happen if the application(DP in this case) opened the queue and then not issuing any API calls on the opened object. Pid 25391 - is this for an amqrmppa process? Is DP expected to consume messages on this queue continuously?

ActiveMQ Failover Transport -

I am using the active mq failover configuration in my Spring Web based application. There are 4 production active mq boxes and my connection URL for a message producer looks like this
failover:(tcp://hosta:61616,tcp://hostb:61616,tcp://hostc:61616,tcp://hostd:61616)
The failover piece works fine. When a producer tries send message, connection gets established on any of the 4 nodes and if that fails, it goes to a other node.
All is fine here. But if the second host fails, the next one does not get picked up and it sends an exception to the client.
There is only one level of failover that I am able to witness . Do we have to make any additional configuration to make sure all active mq hosts are checked before throwing out an exception to the client.
Any help is appreciated. Thanks.

Resources