MQGET for SYSTEM.ADMIN.COMMAND.QUEUE failed with reason code 2071 - Middleware News
Command server fails to start or fails shortly after it receives a message in the SYSTEM.ADMIN.COMMAND.QUEUE. No FDC files are generated. the error received is AMQ8506:
Command server MQGET failed with reason code 2071.
EXPLANATION:
An MQGET request by the command server, for the WebSphere MQ queue SYSTEM.ADMIN.COMMAND.QUEUE, failed with reason code 2071.
Symptom
2071 0x00000817 MQRC_STORAGE_NOT_AVAILABLE
Cause
Well designed MQ server applications typically assume a relatively small initial buffer size, and then heuristically tune the required buffer size based upon the sizes of the messages consumed. For example both the repository manager and the pubsub broker adopt such a scheme.
The MQ command server however allocates a fixed size buffer based upon the MAXMSGL defined for the SYSTEM.ADMIN.COMMAND.QUEUE and then issues it's MQGET's using this buffer size. Because the commands accepted by the command server are not intrinsically big, and the default MAXMSGL for SYSTEM.ADMIN.COMMAND.QUEUE is only 9000 bytes, then this simplistic scheme is generally adequate in this scenario.
However if a very large MAXMSGL is set for SYSTEM.ADMIN.COMMAND.QUEUE, then this would be a relatively inefficient design, as the command server would allocate a very large buffer and the queue manager would interpret this as a hint that very large messages were going to be processed.
If the max message length for the SYSTEM.ADMIN.COMMAND.QUEUE is increased, the command server allocates a larger buffer when reading messages from this queue. If it is significantly increased, say from 4 to 100 MB, the "data" ulimit for the process can be insufficient, causing it to crash.
Resolving the problem
***** PLEASE READ THIS CAREFULLY ******
Do not alter MAXMSGL set for SYSTEM.ADMIN.COMMAND.QUEUE Certain system objects are managed exclusively by the queue manager and should never be modified under any circumstance. However here are some workarounds to get the command server to start. Any of these should work.
*********************************************
In /etc/security/limits, increase the "data" ulimit for the account used to start the queue manager (usually root) to 192 MB or greater. Setting the data segment size (ulimit -d) to unlimited will resolve the issue. Note that the value is configured in 512 byte blocks, and -1 means unlimited.
In runmqsc, reset the MAXMSGL attribute on the SYSTEM.ADMIN.COMMAND.QUEUE to 4194304.
In runmqsc, decrease the queue manager's MAXMSGL attribute to something like 33554432, depending on the "data" ulimit value.
Command server fails to start or fails shortly after it receives a message in the SYSTEM.ADMIN.COMMAND.QUEUE. No FDC files are generated. the error received is AMQ8506:
Command server MQGET failed with reason code 2071.
EXPLANATION:
An MQGET request by the command server, for the WebSphere MQ queue SYSTEM.ADMIN.COMMAND.QUEUE, failed with reason code 2071.
Symptom
2071 0x00000817 MQRC_STORAGE_NOT_AVAILABLE
Cause
Well designed MQ server applications typically assume a relatively small initial buffer size, and then heuristically tune the required buffer size based upon the sizes of the messages consumed. For example both the repository manager and the pubsub broker adopt such a scheme.
The MQ command server however allocates a fixed size buffer based upon the MAXMSGL defined for the SYSTEM.ADMIN.COMMAND.QUEUE and then issues it's MQGET's using this buffer size. Because the commands accepted by the command server are not intrinsically big, and the default MAXMSGL for SYSTEM.ADMIN.COMMAND.QUEUE is only 9000 bytes, then this simplistic scheme is generally adequate in this scenario.
However if a very large MAXMSGL is set for SYSTEM.ADMIN.COMMAND.QUEUE, then this would be a relatively inefficient design, as the command server would allocate a very large buffer and the queue manager would interpret this as a hint that very large messages were going to be processed.
If the max message length for the SYSTEM.ADMIN.COMMAND.QUEUE is increased, the command server allocates a larger buffer when reading messages from this queue. If it is significantly increased, say from 4 to 100 MB, the "data" ulimit for the process can be insufficient, causing it to crash.
Resolving the problem
***** PLEASE READ THIS CAREFULLY ******
Do not alter MAXMSGL set for SYSTEM.ADMIN.COMMAND.QUEUE Certain system objects are managed exclusively by the queue manager and should never be modified under any circumstance. However here are some workarounds to get the command server to start. Any of these should work.
*********************************************
In /etc/security/limits, increase the "data" ulimit for the account used to start the queue manager (usually root) to 192 MB or greater. Setting the data segment size (ulimit -d) to unlimited will resolve the issue. Note that the value is configured in 512 byte blocks, and -1 means unlimited.
In runmqsc, reset the MAXMSGL attribute on the SYSTEM.ADMIN.COMMAND.QUEUE to 4194304.
In runmqsc, decrease the queue manager's MAXMSGL attribute to something like 33554432, depending on the "data" ulimit value.
Comments
Post a Comment