Tim Zielke
2014-03-01 03:54:15 UTC
Hello,
If you would find this RFE helpful, please vote for -> http://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=45694
Here are more details about the RFE:
Internal Trace Table for MQ Distributed Tracing
This RFE is for an enhancement to the MQ distributed tracing provided by strmqtrc, for an option to allow tracing to go to a wrapping internal (i.e. in memory) trace table instead of the filesystem (i.e. /var/mqm/trace). An enhancement will also be added to endmqtrc to allow the administrator to cause the internal trace table to be written to the file system in an ad hoc fashion, or when turning the trace is being turned off. For application processes being traced, the functionality to write the internal trace table to the file system will run on an MQ owned thread that is separate from the application threads, in order to reduce performance overhead to the application processes.
Example:
Administrator runs the following command:
strmqtrc -m qmgr1 -t all -v 64
This causes all queue manager processes for qmgr1 and application processes connecting to qmgr1 to allocate 64Mb of virtual memory in their respective address spaces for a wrapping internal trace table. The aforementioned processes now start producing trace records into this memory. When the 64Mb of memory is exhausted, the tracing wraps to the beginning and starts overwriting the trace table.
Later, the administrator runs the following command:
endmqtrc -m qmgr1 -a -v
This causes all the processes that were running internal tracing to write their internal trace tables out to the filesystem (i.e. /var/mqm/trace) and then to turn tracing off.
If the administrator was to run the following command instead:
endmqtrc -m qmgr1 -v
This would just cause the internal trace tables to be written to the file systems, but internal tracing would continue running.
The benefits of this enhancement is to allow a much less performance intrusive way to run a distributed trace. Since tracing is only being put into memory, it should add much less performance overhead to the processes than conventional distributed tracing. This would potentially allow an administrator to do something like the following.
1. Turn on internal tracing.
2. Start a watch dog process that scans an application log file for a certain message.
3. When the watch dog process sees the message, issue the command to dump the internal tracing to the file system and turn off internal tracing.
The above use case would be helpful for when you have an application issue that does not happen very often, and you would like to collect tracing leading up to the application error.
Thanks,
Tim
To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html
If you would find this RFE helpful, please vote for -> http://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=45694
Here are more details about the RFE:
Internal Trace Table for MQ Distributed Tracing
This RFE is for an enhancement to the MQ distributed tracing provided by strmqtrc, for an option to allow tracing to go to a wrapping internal (i.e. in memory) trace table instead of the filesystem (i.e. /var/mqm/trace). An enhancement will also be added to endmqtrc to allow the administrator to cause the internal trace table to be written to the file system in an ad hoc fashion, or when turning the trace is being turned off. For application processes being traced, the functionality to write the internal trace table to the file system will run on an MQ owned thread that is separate from the application threads, in order to reduce performance overhead to the application processes.
Example:
Administrator runs the following command:
strmqtrc -m qmgr1 -t all -v 64
This causes all queue manager processes for qmgr1 and application processes connecting to qmgr1 to allocate 64Mb of virtual memory in their respective address spaces for a wrapping internal trace table. The aforementioned processes now start producing trace records into this memory. When the 64Mb of memory is exhausted, the tracing wraps to the beginning and starts overwriting the trace table.
Later, the administrator runs the following command:
endmqtrc -m qmgr1 -a -v
This causes all the processes that were running internal tracing to write their internal trace tables out to the filesystem (i.e. /var/mqm/trace) and then to turn tracing off.
If the administrator was to run the following command instead:
endmqtrc -m qmgr1 -v
This would just cause the internal trace tables to be written to the file systems, but internal tracing would continue running.
The benefits of this enhancement is to allow a much less performance intrusive way to run a distributed trace. Since tracing is only being put into memory, it should add much less performance overhead to the processes than conventional distributed tracing. This would potentially allow an administrator to do something like the following.
1. Turn on internal tracing.
2. Start a watch dog process that scans an application log file for a certain message.
3. When the watch dog process sees the message, issue the command to dump the internal tracing to the file system and turn off internal tracing.
The above use case would be helpful for when you have an application issue that does not happen very often, and you would like to collect tracing leading up to the application error.
Thanks,
Tim
To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html