| Author | Message | 
		
		  | salvador.wbi | 
			  
				|  Posted: Fri Jul 10, 2009 9:07 pm    Post subject: Message flows deleted still appears on mqsilist command |   |  | 
		
		  |  Novice
 
 
 Joined: 10 Jul 2009Posts: 18
 Location: Monterrey, Mexico
 
 | 
			  
				| Hi buddies, 
 i've got a huge problem with a message flow in the websphere message broker 6.0
 
 Let me explain you what's going on.
 
 We have a broker in a AIX 5.2 system, there we have 6 execution groups and finally there we have a lot of message flows.
 
 So, the problem is, we don't know exactly when a determined message flow was deployed, that message flow appeared to be stopped on the toolkit(administrator perspective) and when we want to deleted it we use toolkit to do it, it works on toolkit but misteriously the services still was working, i mean, the user told us the service was answering his request, we look up into the broker using the mqsilist command and discover there was the message flow deleted in the execution group where it used to be. We tried using the mqsideploy command  but it says the message flow doesn't exist, then we deployed the same message flow and two message flows with the same name appeared in the execution group(that was using mqsilist command,on the toolkit only appeared once) we use then the mqsideploy command in order to delete the message flow but it only deleted one(we think the last one).
 
 If there's something important to consider that is that it is in a production environment, we only can restart the message broker, the configurator manager and its queue manager and db2, we are not allowed to restart the message broker's queue manager. So how can we delete the ghost message flow that only appear with the mqsilist command and seems to be answering other request?
 |  | 
		
		  | Back to top |  | 
		
		  |  | 
		
		  | fjb_saper | 
			  
				|  Posted: Fri Jul 10, 2009 9:42 pm    Post subject: |   |  | 
		
		  |  Grand High Poobah
 
 
 Joined: 18 Nov 2003Posts: 20767
 Location: LI,NY
 
 | 
			  
				| You need to take an outage During that outage you will have the broker running but
 
 You need to delete all children of the eg
you need to verify with mqsilist that all children have been removed
you need to redeploy the legitimate flows to the eg
 You can then restore service.
 
 BTW I haven't seen this type of behavior since 6.0.0.4
 
 Have fun
  _________________
 MQ & Broker admin
 |  | 
		
		  | Back to top |  | 
		
		  |  | 
		
		  | smdavies99 | 
			  
				|  Posted: Fri Jul 10, 2009 10:55 pm    Post subject: |   |  | 
		
		  |  Jedi Council
 
 
 Joined: 10 Feb 2003Posts: 6076
 Location: Somewhere over the Rainbow this side of Never-never land.
 
 | 
			  
				| You can also check the ipprocs of the WMQ Input Queue for the rogue flow to see if it is indeed running and accepting messages. If it doesn't use WMQ for its message input then with a little effort, you can check the HTTP etc etc for the same effect.
 
 If the rogue flow is not accepting input AND you are not going to deploy a new copy then IMHO, the pressure is off a little bit and you can schedule an outage period to clean things up as was previously indicated.
 _________________
 WMQ User since 1999
 MQSI/WBI/WMB/'Thingy' User since 2002
 Linux user since 1995
 
 Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions.
 |  | 
		
		  | Back to top |  | 
		
		  |  | 
		
		  | broker_new | 
			  
				|  Posted: Sat Jul 11, 2009 2:10 pm    Post subject: |   |  | 
		
		  |  Yatiri
 
 
 Joined: 30 Nov 2006Posts: 614
 Location: Washington DC
 
 | 
			  
				| Not sure but give it a try.. 
 DELETING THE MESSAGE FLOW VIA A MESSAGE
 Now that you have the message flow UUID that you want to remove, there are two ways to remove the message flow from the broker database. The first is to manually send a deployment message to the Broker, whilst the second is to manually delete the message flow row from the broker database.
 
 It is possible to manually send a deployment message to the SYSTEM.BROKER.ADMIN.QUEUE of the Broker's queue manager with the following message data:
 
 <Broker label="LHPIEV5" uuid="BrokerUUID" version="1">
 <Change>
 <ExecutionGroup label="EgLabel" uuid="EgUUID"/>
 </Change>
 <ExecutionGroup label="EgLabel" uuid="EgUUID">
 <Delete>
 <MessageFlow uuid="MsgFlowUUID"/>
 </Delete>
 </ExecutionGroup>
 </Broker>
 
 Replacing "BrokerUUID", "EgLabel", "EgUUID" and "MsgFlowUUID" with the real values. For example:
 
 Source for fields
 § BrokerUUID from CBROKER table
 0a05f373-fe00-0000-0080-e55d770dfbbd
 
 § EgUUID from CEG table (or ps –elf | grep DataFlowEngine)
 a58c7b7e-0c01-0000-0080-f73e95d6d3d6
 
 § MsgFlowUUID from mqsireportproperties (or CMSGFLOW table)
 888bac3d-0d01-0000-0080-a3c36930ad4d
 
 
 <Broker label="FADWBID1" uuid="0a05f373-fe00-0000-0080-e55d770dfbbd" version="1">
 <Change>
 <ExecutionGroup label="CS_FLOWS" uuid=" a58c7b7e-0c01-0000-0080-f73e95d6d3d6"/>
 </Change>
 <ExecutionGroup label=" CS_FLOWS" uuid=" a58c7b7e-0c01-0000-0080-f73e95d6d3d6">
 <Delete>
 <MessageFlow uuid="888bac3d-0d01-0000-0080-a3c36930ad4d"/>
 </Delete>
 </ExecutionGroup>
 </Broker>
 
 The message must have:
 § MQMessageFormat = MQSTR
 § MsgType of Request in the MQMD
 § Specify the ReplyQmgr and ReplyQ (which can be any queue).
 
 This will safely remove the message flow from the database as would a normal deployment from the configuration manager.
 
 The ReplyToQ can be checked to see the result of the configuration change request.
 _________________
 IBM ->Let's build a smarter planet
 |  | 
		
		  | Back to top |  | 
		
		  |  | 
		
		  | harish_td | 
			  
				|  Posted: Sun Jul 12, 2009 6:44 am    Post subject: |   |  | 
		
		  | Master
 
 
 Joined: 13 Feb 2006Posts: 236
 
 
 | 
			  
				| 
   
	| fjb_saper wrote: |  
	| BTW I haven't seen this type of behavior since 6.0.0.4
 
 |  
 We have seen this happen on a 6.0.0.6 Broker running on AIX 5.2. Luckily this was a Test box and so we were at liberty to delete all the entries matching this EXECGROUPUUID from the Broker Database. We then re-created the EG from the toolkit
 
 
 
   
	| broker_new wrote: |  
	| DELETING THE MESSAGE FLOW VIA A MESSAGE
 
 |  Although this worked on my windows broker, certainly not something i would try on PROD.
 |  | 
		
		  | Back to top |  | 
		
		  |  | 
		
		  | salvador.wbi | 
			  
				|  Posted: Mon Jul 13, 2009 11:53 am    Post subject: EG won't be deleted |   |  | 
		
		  |  Novice
 
 
 Joined: 10 Jul 2009Posts: 18
 Location: Monterrey, Mexico
 
 | 
			  
				| tnks for yours replies! 
 We're looking for a solution where we don't have to delete the eg because for the moment that's not possible, in this moment it'd better not to delete it, we have read about deleting the references of the message flow in the broker database, could anybody explain more about what we should do in the database? I mean, what tables do we have to change? how exactly can we get the MsgFlowUUID of the message flow? what do we have to do in order to  delete the references of the message flow in the broker database?
 |  | 
		
		  | Back to top |  | 
		
		  |  | 
		
		  | TonyD | 
			  
				|  Posted: Mon Jul 13, 2009 4:02 pm    Post subject: |   |  | 
		
		  | Knight
 
 
 Joined: 15 May 2001Posts: 540
 Location: New Zealand
 
 | 
			  
				| I tackled this problem a couple of years ago but cannot exactly what I did to get over it unfortunately.  You can find out details of the flow's UUID etc by using the Configuration Manager Proxy API Exerciser (WebSphere Message Brokers 6.1/ Java Programming APIs/ Configuration Manager Proxy API Exerciser). |  | 
		
		  | Back to top |  | 
		
		  |  | 
		
		  | mqjeff | 
			  
				|  Posted: Tue Jul 14, 2009 5:10 am    Post subject: |   |  | 
		
		  | Grand Master
 
 
 Joined: 25 Jun 2008Posts: 17447
 
 
 | 
			  
				| Anything that involves manual manipulation of the Broker database or ConfigMgr repository should only be performed under the aegis of a PMR. 
 There's absolutely no reason you can't delete the flows, without taking an outage.
 
 Just redeploy them to a brand new EG first, and then delete the old one.
 
 You will almost certainly have to stop and start the Broker no matter what method you end up using.
 |  | 
		
		  | Back to top |  | 
		
		  |  | 
		
		  | salvador.wbi | 
			  
				|  Posted: Tue Jul 14, 2009 8:54 am    Post subject: deleting eg complications. |   |  | 
		
		  |  Novice
 
 
 Joined: 10 Jul 2009Posts: 18
 Location: Monterrey, Mexico
 
 | 
			  
				| Ok, It seems to be that an outage and delete the objects or /and the eg is the best solution, we were looking for a solution where we hadn't have to delete the other message flows meanly because the source code seems not to be updated, of course, maybe it works perfectly but we recently have problems because we deployed a message flow taken from the production repository and we discover that was not the last version and you know what happens in that situations. We're paying for that mistake but if anyone knows how to avoid of deleting the message flows and /or the eg please tell us. 
 tnks for your replies!
 |  | 
		
		  | Back to top |  | 
		
		  |  | 
		
		  | salvador.wbi | 
			  
				|  Posted: Tue Sep 29, 2009 3:33 pm    Post subject: Problem resolved |   |  | 
		
		  |  Novice
 
 
 Joined: 10 Jul 2009Posts: 18
 Location: Monterrey, Mexico
 
 | 
			  
				| Hi guys, 
 Sorry if i didn't tell u before but we resolve the problem deleting the eg from the broker db
 
 tnks for your replies.
 |  | 
		
		  | Back to top |  | 
		
		  |  | 
		
		  |  |