I have question can we track the messages ( transaction) in websphere MQ, if yes how to enable the tracking in queue manager level.or is there any support pack for the same.
#Josh: Thanks for your replay
Recently we have faced the issue around 300 imps msgs are didn't received to my receiver application, so we have checked the queue manager status, queue cur-depth and checked is there any UNCOM msgs available in Queue level UNCOM is status is '0' channel status is running no error found in queue manager error logs with time stamp of issue.
and also we have checked with database team no information is available for the same.
for this situation we need to track the message so we can easily identify the issue.
# Roger: can your please suggest me what are commercial product we have,so we can check with application owners for the same.
MsgId will be unique for every message sent out from queue manager.
Related
I have a Normal IBM MQ developer edition 924 installed on a ubuntu virtual machine. And have cpp code files for Publisher and Subscriber model. I created a topic and started sending messages on the topic.
The issue happens when I send a larger message on the topic, the error code of 2031(MQRC_MSG_TOO_BIG_FOR_Q_MGR) is outputted. (https://www.ibm.com/docs/en/ibm-mq/9.1?topic=arc-2031-07ef-rc2031-mqrc-msg-too-big-q-mgr)
I changed the maxmsgl value for the Queue manager and the SVR channel as well. I ran the following commands for this:
runmqsc QM1
ALTER QMGR MAXMSGL(104857600)
ALTER CHANNEL(SYSTEM.AUTO.SVRCONN) CHLTYPE(SVRCONN) maxmsgl(104857600)
But still the error persists, could someone reflect on what needs to be done regarding this error code. And also as message segmentation is not allowed on pubsub what is the maximum limit of message size it can handle.
When using a topic for publish/subscribe, the messages sent to subscribers are still put onto a queue for safe storage until they are consumed by the subscribing/getting application. These queues must also have MAXMSGL set appropriately.
If you do not know which queue to adjust, follow these steps:-
Run the subscriber application - assuming that it will wait around for a while
Issue the following MQSC command (e.g. using runmqsc):-
DISPLAY SUB(*) DEST DESTCLAS TOPICSTR DURABLE
The name shown in the DEST field in the output is the queue your subscription is using. If it's name starts with SYSTEM.MANAGED and it also shows DESTCLAS(MANAGED) then your subscription is a managed subscription. You say that your subscription is not managed, but if you don't know which queue is in use by that subscriber then it is most likely that it IS managed, since that means you don't have to worry about the queue.
A managed subscription queue is built from a MODEL queue referenced on the topic. If you are unsure which MODEL queue would be used, issue the following command using the TOPICSTR value from the output of the above command.
DISPLAY TPSTATUS('topic-str-value') MNDURMDL MDURMDL
If the output from the DISPLAY SUB command earlier showed that your subscription was DURABLE(YES) then the MODEL queue in use is the one shown in the field MDURMDL (Managed DURable MoDeL). If it showed DURABLE(NO) then the MODEL queue in use is the one shown in the field MNDURMDL (Managed Non-DURable MoDeL).
Using the name determined in step 4 if it is not managed, or in step 5 if it is managed, issue the following MQSC command:-
ALTER QLOCAL('q-name-from-step-4') MAXMSGL(104857600)
or
ALTER QMODEL('q-name-from-step-5') MAXMSGL(104857600)
Now re-make your subscription (so that it deletes the previous temporary queue it created and makes a new one from the model) and re-run your publisher application.
We have a application iconnect,iconnect( Receiver ) application is expecting the message from the RTGS(Sender) application,RTGS is transferred the around 40000 messages. iconnect application is received the all messages except one messages. we have checked with RTGS application for the same,they have successfully sent the messages to targeted queue.
{ 1)We have checked all channel status its working fine,
2)We have checked the xmit queue and local queue curdepth.no messages are pilled up in queue.
3)We have checked the uncom messages in queue level no uncom messages are available.
4)And also we have checked application logs and DB logs,we haven't found the transaction. }
we unable to find the one transaction can any one help me for why the transaction got failed.and where we can find the failed transactions transactions.
#Subbarao: thanks for replay we have already tried the below command getting popup "no transaction found"
dspmqtrn -m queue manager name.
is there any process to we can find the losses transaction.
We are using IBM MQ8.0. Activitiy logs are getting logged for outgoing messages which we are sending to external system. But there is no log available for the messages which are from external system to our MQ Manager.
Is it problem with client channel configuration ?
Or MQ logging configuration issue ?
IBM describes these "activity logs" as recover logs in the Knowledge center page "Making sure that messages are not lost (logging)"
IBM MQ records all significant changes to the persistent data controlled by the queue manager in a recovery log.
This includes creating and deleting objects, persistent message updates, transaction states, changes to object attributes, and channel activities. The log contains the information you need to recover all updates to message queues by:
Keeping records of queue manager changes
Keeping records of queue updates for use by the restart process
Enabling you to restore data after a hardware or software failure
Please note that non-persistent messages are not logged to the recover log.
Based on your question it is likely that the messages you are sending to the external system are persistent messages and the messages you are receiving from the external system are non-persistent messages, this would explain why they are not logged to the recover log files.
Persistence is determined at the time the message is first PUT.
IBM has a good Technote "Message persistence FAQs" about this subject.
Q3. What is the best way to be certain that messages are persistent?
A3. Set MQMD message persistence to persistent (MQPER_PERSISTENT), or nonpersistent (MQPER_NOT_PERSISTENT) and your message will always retain that value.
Note: MQPER_PERSISTENCE_AS_Q_DEF is the default setting for the persistence value in the MQMD. See the persistence values listed below.
...
Additional information
MQPER_PERSISTENCE_AS_Q_DEF can lead to unexpected results. If there is more than one definition in the queue-name resolution path, the default persistence attribute is taken from first queue definition in the path at the time of the MQPUT or MQPUT1 call. This queue could be an:
alias queue
local queue
local definition of a remote queue
queue-manager alias
transmission queue
cluster queue
The external system will need to make sure the messages they send you are set as persistent messages if you want them to be logged.
I am wondering if MQ can be used as a state cache for monitoring? And is this a good idea or not?
In theory you can have many sources (monitoring agents) that detect problem states and distribute them to subscribers via an MQ system such as RabbitMQ. But has anyone heard of using MQ systems to cache the state, so when clients initialize, they read from the state queue before subscribing to new state messages? Is that a bad way to use MQ?
So to recap, a monitor would read current state from a state queue then setup a subscription queue to receive any new updates. And the state queue would be maintained by removing any alerts that are no longer valid by the monitoring agents that put the alert there to begin with.
Advantage would be decentralized notification and theoretically very salable by adding more mq systems to relay events.
I have a use case for Rabbit MQ that holds the last valid status of a system. When a new client of that system connects it receives the current status.
It is so simple to do!
You must use the Last Value Cache custom exchange https://github.com/simonmacmullen/rabbitmq-lvc-plugin
Once installed you send all your status messages to that exchange. Each client that needs the status information will create a queue that will have the most recent status delivered to that queue on instantiation. After that it will continue to receive status updates.
IBM MQ FTE uses such way for storing logs.
I think it is good idea, if you can prevent destination queue from overflow, because IBM MQ for example remove overdue messages only during GET call.
This is in Cluster Environment. Queue Manager lost its identity in cluster and it is unable to connect to other servers. All channels to repository and others were retrying state.
CPU usage is optimal in this server. This is a UNIX box.
When I checked the logs below is it,
AMQ9532: Program cannot set queue
attributes.
EXPLANATION: The attempt to set the
attributes of queue
'SYSTEM.CLUSTER.TRANSMIT.QUEUE' on
queue manager 'QMGR.SERVER6A' failed
with reason code 2102.
ACTION: Ensure
that the queue is available and retry
the operation.
----- amqrmssa.c : 690 --------------------------------------------------------
AMQ9999: Channel program ended
abnormally.
EXPLANATION: Channel program
'Channel.Coord00' ended abnormally.
ACTION: Look at previous error
messages for channel program
'Channel.Coord00' in the error files to
determine the cause of the failure.
----- amqrccca.c : 883 --------------------------------------------------------
03/06/11 08:24:26 AMQ9544: Messages
not put to destination queue.
EXPLANATION: During the processing of
channel 'Channel.Server6A' 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
1, 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 '1372200'.
----- amqrmrca.c : 1318 -------------------------------------------------------
Then I did recycled the queue manager it is now fine?
My question here is how did the MQ resource problem occurr? CPU usage of this server is not more than 15%. Please advise.
There are three different and unrelated problems shown in the log.
AMQ9532: Program cannot set queue
attributes.
EXPLANATION: The attempt to set the
attributes of queue
'SYSTEM.CLUSTER.TRANSMIT.QUEUE' on
queue manager 'QMGR.SERVER6A' failed
with reason code 2102.
The 2102 is MQRC_RESOURCE_PROBLEM and presumably the resource issue referred to in the posting. The 2102 can be any kind of scarce resource, including semaphores, user processes, queue handles, etc. Since the QMgr was attempting to set an attribute of the queue, it would have already had a thread instantiated but it would have required additional queue handles. When something like this occurs, use your admin tool (WMQ Explorer, mqmon or one of the many 3rd party tools) to look into the number of open queue handles, open channels, etc. Note that for a resource error, it will be necessary to maintain an open connection to the QMgr or else the tool will be unable to make a new connection when the resource shortage occurs.
AMQ9999: Channel program ended
abnormally.
EXPLANATION: Channel program
'Channel.Coord00' ended abnormally.
ACTION: Look at previous error
messages for channel program
'C00.US.MP00' in the error files to
determine the cause of the failure.
This error appears to actually be two different errors since it references two different channels. One of these appears to be an outbound cluster channel and the other appears to be a point-to-point channel. Neither channel mentioned in this error are associated with the first and last error message.
03/06/11 08:24:26 AMQ9544: Messages
not put to destination queue.
EXPLANATION: During the processing of
channel 'Channel.Server6A' 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 1,
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 '1372200'.
The last error appears to be an inbound cluster channel. Since the first error was trying to set attributes of the cluster transmit queue, it could only have been associated with an outbound channel. Therefore the first and last error messages are unrelated. This error message appears to show an inbound message that was destined for a queue and that queue was full, PUT-disabled, or otherwise unable to accept the message. The message was therefore routed to the dead letter queue.
For the resource error, I would suggest reviewing the performance report appropriate to your platform. Go to the SupportPacs page and look for those SupportPacs named MP* and then look for the one for your platform. The Performance Reports give you specific tuning advice.
You may also want to review the Problem Determination chapter in the System Administration manual for additional advice on how to identify resource issues.
The WebSphere MQ cluster design and operation article in the developerWorks Mission:Messaging series has specific advice about keeping clusters healthy.
Last but not least, the WebSphere MQ MustGather page has sections on troubleshooting for all major platforms and categorized by problem area.
To increase the MAXMSGL to 100 MB in IBMMQ,
(Reason code-2102 - MQRC_RESOURCE_PROBLEM) after setting the MAXMSGL to 100 mb
Category: IBM WebSphere MQ
If you are receiving error Reason code:2102 - MQRC_RESOURCE_PROBLEM, then try
Queue manager->properties->Extended->Increase Log->Log primary files and Log->Log secondary files->value to 20