| Author |
Message
|
| varunraot |
 Posted: Sat Feb 18, 2017 8:53 am Post subject: Deleting the MFT monitor |
 |
|
Acolyte
Joined: 01 Jun 2011
Posts: 63
|
Is there any other way to delete monitor specific to an agent provided if below methods are already been tried and still monitors does not get deleted
1. fteDeleteMonitor
2.fteCleanAgent
3.fteDeleteAgent
Even after trying above methods, fteListAgents still shows the monitors associated with deleted monitor. |
|
| Back to top |
|
 |
| tomleend |
| Posted: Tue Feb 21, 2017 10:21 am Post subject: |
|
|
Acolyte
Joined: 24 Jan 2014
Posts: 51
|
Hi varunraot,
I assume you mean they are still listed via the fteListMonitors command (rather than the fteListAgents command)?
So, it is important to understand that the definition/configuration of an MFT Resource Monitor is held in two messages on SYSTEM.FTE.EVENT.<agent_name> queue for the MFT agent that was running the Resource Monitor. For example, if I had defined a Resource Monitor to run on an agent called "AGENT1", then there would be two messages on the SYSTEM.FTE.EVENT.AGENT1 queue (one to hold the Resource Monitor definition, and one to hold runtime/history information for that Resource Monitor - so it does not trigger on the same files twice, for example).
If those messages are deleted by the host agent, after running the fteDeleteMonitor command, or forcefully removed from the queue by the fteCleanAgent command, then the Resource Monitor will no longer be run by the agent on which it was defined.
The fteListMonitors command subscribes to the SYSTEM.FTE/monitors topic on the coordination queue manager to get information about Resource Monitors that have been defined in an MFT topology. Retained publications are used by MFT agents to report information about Resource Monitors they are running.
Now, if a Resource Monitor has been forcefully deleted (before manual removal of messages from the SYSTEM.FTE.EVENT queue) or a recreate of an agent's queue manager, then the state of resource monitor messages and their retained published status can become out-of-sync.
So, if you are in this case, you just need to do a bit of manual clean-up of the topic tree space on the coordination queue manager.
This can be done using an MQSC command, run against the coordination queue manager:
| Code: |
| CLEAR TOPICSTR('SYSTEM.FTE/monitors/#') CLRTYPE(RETAINED) |
This will clean the entire topic tree nodes of retained messages from 'SYSTEM.FTE/monitors’ down. If you only have a few deleted resource monitors that are still being displayed but have other non-deleted resource monitors displayed, then a more targeted MQSC command might be necessary. In which case, add the name of the resource monitor that was deleted:
| Code: |
| CLEAR TOPICSTR('SYSTEM.FTE/monitors/<MONITOR_NAME>/#') CLRTYPE(RETAINED) |
|
|
| Back to top |
|
|
| varunraot |
| Posted: Wed Feb 22, 2017 12:54 am Post subject: |
|
|
Acolyte
Joined: 01 Jun 2011
Posts: 63
|
Thanks. After executing the command CLEAR TOPICSTR('SYSTEM.FTE/monitors/#') CLRTYPE(RETAINED), I dont see any monitors getting listed when issued with
fteListMonitors -v -p <Coordination Queue Manager Name>
BFGCL0242W: No monitors exist that match the current selection criteria.
Monitors exist in the background as I could see file transfer happening. How do I bring back those invisible monitors to visibility? |
|
| Back to top |
|
|
| tomleend |
| Posted: Wed Feb 22, 2017 3:54 am Post subject: |
|
|
Acolyte
Joined: 24 Jan 2014
Posts: 51
|
| Agents hosting Resource Monitors will publish state about them when they are started and stopped. So, stopping and then starting your agents should result in a new trained message being published to the SYSTEM.FTE/monitors topic on the coordination queue manager that can then be picked up by the fteListMonitors command. |
|
| Back to top |
|
|
| Manuel |
| Posted: Fri Jun 09, 2017 4:37 am Post subject: |
|
|
Newbie
Joined: 09 Jun 2017
Posts: 3
|
Hi.
I'm having the same problem.
Deleted agent
Deleted queues
Deleted monitors
ftelistmonitors keep listing the delete monitor.
I already did the clear topicstr and the problem persists.
Any idea? |
|
| Back to top |
|
|
| Manuel |
| Posted: Fri Jun 09, 2017 4:38 am Post subject: |
|
|
Newbie
Joined: 09 Jun 2017
Posts: 3
|
|
| Back to top |
|
|
| Manuel |
| Posted: Tue Jul 04, 2017 3:11 am Post subject: |
|
|
Newbie
Joined: 09 Jun 2017
Posts: 3
|
|
| Back to top |
|
|
| varunraot |
| Posted: Sun May 06, 2018 10:06 pm Post subject: |
|
|
Acolyte
Joined: 01 Jun 2011
Posts: 63
|
I am "reinitiating" this thread as there is no evident solution to this MQ MFT annoying bug
Its unfortunate and annoying bug of MQ MFT where below first 3 methods of deleting the monitor just does not work ( applicable only in few cases and not always) and there is no mention of it in Info Center either and not been addressed with subsequent releases.
1.fteDeleteMonitor
2.fteCleanAgent
3.fteDeleteAgent
4.CLEAR TOPICSTR('SYSTEM.FTE/monitors/<MONITOR_NAME>/#') CLRTYPE(RETAINED)
The CLEAR TOPICSTR('SYSTEM.FTE/monitors/#') CLRTYPE(RETAINED) would work, however it would make all monitors to disappear from the MQ MFT Plug in in WebSphere MQ Explorer as well as in fteListMonitors command.
It would be dumb suggestion to restart agents to make it appear as this is not viable solution in production environment and if you have
1. Many agents under a coordination queue manager ( You can not keep restarting all agents in production environment)
2. If you would like to edit the monitor (How would you edit the monitor if its not rendered in MQ MFT plug in or in command line)
Any definite way of addressing this weird feature is highly appreciated. |
|
| Back to top |
|
|
|
|
