How to increase the MAXMSGL for Queue Managers, Queues and Channels from the default 4 MB to a higher number - Middleware News

You have a Client application that works fine in sending short messages to a WebSphere MQ queue manager. However, whenever the size of the message is greater than 4 MB, you get an error with reason code: 2030 (MQRC_MSG_TOO_BIG_FOR_Q)

Cause

The default limit for maximum message size for the queue manager, channels and queues is 4 MB or 4194304 or 4 194 304 byteas. The upper limit is 100 MB or 104857600 or 104 857 600 bytes

Note that if you are using the MQSERVER environment variable which takes precedence over the Channel Client Definition Table (CCDT), the limit in V6 is 4 MB. It was raised to 100 MB in V7.

Resolving the problem

There are 3 sections in this technote:

a) Warnings

b) Few objects to support maximum message length of 100 MB.

c)All objects to support a maximum message length of 100 MB.

The following article discusses issues related to mixing messages of different types and sizes:

Mission:Messaging: Of mice and elephants
Multiple message types sharing resources is like all zoo animals in the same cage
T.Rob Wyatt, Senior Managing Consultant, IBM



a) Warnings!

Keep in mind that increasing the maximum message length from 4 MB to a high value such as 100 MB will impact many tuning parameters of the queue manager. Improper tuning may result in exhaustion of server resources which in turn will negatively impact the queue manager, including possible failure. Tuning parameters affected by MAXMSGL include the following:

* Channel batch sizes are expressed as a number of messages, regardless of the message size. With default settings, the channel will not attempt to send more than 200MB in a single batch. Since batches are transactional, this also means that no more than 200 MB is held under syncpoint for any given channel with default settings. With MAXMSGL set to 100 MB and a channel batch size of 50, the largest possible channel batch size is 5 GB. This can cause wide variation in channel performance when large and small messages are mixed on the same channel, or even total failure of the channel (see the bullet on log file tuning below). If possible, segregate very large and very small messages onto separate channels that are tuned appropriately.

* MAXUMSGS is a queue manager parameter that limits the maximum number of uncommitted messages a process may hold under syncpoint before a rollback of the transaction is forced. Each of these messages consumes disk space, memory and some portion of log file active extents. Raising MAXMSGL to 100MB allows the same number of messages under syncpoint to consume up to 25 times more of these resources. Depending on the volume of very large messages, it may be advisable to tune MAXUMSGS to a lower value.

* All data held under syncpoint at any given moment must fit within the primary and secondary log file extents. This is true even when linear logging is used. The default log file settings provide for 80 MB of data total, for all processes including internal queue manager processes such as channels, under syncpoint at any moment. Log file size and extents must be tuned according to the number of very large messages that are expected to be in flight at any moment. Changing the number of log file extents requires a restart of the queue manager. Changing the size of the log file extents requires deleting and rebuilding the queue manager so it is advisable to perform this tuning before the queue manager is created.

* The default MAXMSGL is designed to insure that the maximum disk space for a queue fits within the 2 GB limit of older file systems. In some cases it may be necessary to tune MAXDEPTH to a lower value to maintain this limit. If the queue exceeds the maximum file size for the underlying file system applications attempting to PUT a messages receive a return code indicating a resource error rather than the expected QFULL or MSG_TOO_LARGE..

* When MAXMSGL is set to 100 MB it is much more likely that the underlying file system will fill before the application hits MAXDEPTH on the queue. When an application attempts to exceed MAXDEPTH that application receives a QFULL error code and can retry the PUT. However if the file system fills the entire queue manager and all connected applications are prevented from putting any new messages. It is always advisable to insure adequate disk storage under the queue and log files and this is especially true when tuning for very large messages.

* Queue manager restart times vary based on the amount of data queued up and under syncpoint. This is true for stand-alone as well as multi-instance and hardware clustered queue managers. Thus there is a trade-off between the amount of data that can be queued versus the speed of recovery after failure. If restart time is critical and very large messages are common, it may be necessary to tune MAXDEPTH and log file capacity to lower values.

This Technote provides a brief introduction to tuning the queue manager in order to provide some insight into the possible effects of arbitrarily raising or eliminating tunable limits such as MAXMSGL. Please refer to the WebSphere MQ V7 Information Center for detailed information on each of the tuning parameters.

The strategy of the default values for WebSphere MQ is to return soft, recoverable errors to applications rather than to allow exhaustion of underlying server resources such as disk space or memory. When raising any of these soft constraints, it is advised to consider the possible effects and whether to compensate by lowering the value of a corresponding tuning parameter.


b) Few objects to support maximum message length of 100 MB

Scenario: An application that uses the MQ Client is connecting via a server-connection channel and accessing a queue.
You need to perform the following configuration changes in MQ to ensure that 100 MB messages can get through from the MQ Client through the server-connection channels to the Queue.

Note: If your scenario uses a Transmission (XMITQ) queue, you need to alter that queue too.

Start by invoking the MQ administration tool:

runmqsc QMgrName

# Display the maximum message length for the Queue Manager.
# The default is 4 MB.
# In this example, the name of the queue manager is QM_VER.
display qmgr maxmsgl
1 : display qmgr maxmsgl
AMQ8408: Display Queue Manager details.
QMNAME(QM_VER) MAXMSGL(4194304)

# Alter the value to the upper limit 100 MB
alter qmgr maxmsgl(104857600)

# Display the maximum message length for the queue (using Q1 as example)
# The default is 4 MB
display ql(Q1) maxmsgl
4 : display ql(Q1) maxmsgl
AMQ8409: Display Queue details.
QUEUE(Q1) TYPE(QLOCAL)
MAXMSGL(4194304)

# Alter the value to the upper limit 100 MB
alter ql(Q1) maxmsgl(104857600)

# Display the maximum message length for the server connection channel.
# Using as example: SYSTEM.AUTO.SVRCONN.
# The default is 4 MB
display CHANNEL(SYSTEM.AUTO.SVRCONN) MAXMSGL
9 : display CHANNEL(SYSTEM.AUTO.SVRCONN) MAXMSGL
AMQ8414: Display Channel details.
CHANNEL(SYSTEM.AUTO.SVRCONN) CHLTYPE(SVRCONN)
MAXMSGL(4194304)

# Alter the value to the upper limit 100 MB
# Notice that the proper CHLTYPE must be specified after the channel name.
alter CHANNEL(SYSTEM.AUTO.SVRCONN) CHLTYPE(SVRCONN) maxmsgl(104857600)

# Display the maximum message length for a Client Connection channel
# (when using CCDT).
# In this example, it is the custom channel named "CH1":
display channel(CH1) chltype(clntconn) maxmsgl
16 : display channel(CH1) chltype(clntconn) maxmsgl
AMQ8414: Display Channel details.
CHANNEL(CH1) CHLTYPE(CLNTCONN)
MAXMSGL(4194304)
.
# Alter the value to the upper limit 100 MB
# Notice that the proper CHLTYPE must be specified after the channel name.
alter channel(CH1) chltype(clntconn) MAXMSGL(104857600)
17 : alter channel(CH1) chltype(clntconn) MAXMSGL(104857600)
AMQ8016: WebSphere MQ channel changed.

# End the session
end


c) All objects to support a maximum message length of 100 MB

This section is also when a message is sent from a Queue Manager to another Queue Manager.
In this case, the changes MUST be done in BOTH queue managers.

If you want all of your channels and queues to support 100 MB message length then you need to alter all existing definitions, and also alter the system defined objects, in that way, new definitions of channels and queues are defined with the maximum message length set to 100 MB.

In addition to the objects mentioned in (a), you will need to change more objects, such as:

Channels:
SYSTEM.DEF.* (such as SYSTEM.DEF.SVRCONN, SYSTEM.DEF.SERVER)

Queues:
SYSTEM.DEFAULT.LOCAL.QUEUE
SYSTEM.DEAD.LETTER.QUEUE
SYSTEM.DEFAULT.ALIAS.QUEUE
SYSTEM.DEFAULT.INITIATION.QUEUE
SYSTEM.DEFAULT.MODEL.QUEUE
SYSTEM.DEFAULT.REMOTE.QUEUE
SYSTEM.DURABLE.MODEL.QUEUE
SYSTEM.RETAINED.PUB.QUEUE

Start by invoking the MQ administration tool:

runmqsc QMgrName

# Alter the value for the Channels and Queues mentioned above.

# End the session
end