ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum Index » IBM MQ Java / JMS » Orphaned JMS Durable Subscribers w/WMQI broker

Post new topic  Reply to topic
 Orphaned JMS Durable Subscribers w/WMQI broker « View previous topic :: View next topic » 
Author Message
clinch
PostPosted: Wed Nov 12, 2003 1:24 pm    Post subject: Orphaned JMS Durable Subscribers w/WMQI broker Reply with quote

Newbie

Joined: 12 Nov 2003
Posts: 2

I'm wondering if anyone can offer insights into durable subscription administration. We've recently activated WMQI as the JMS pub/sub broker. We had a few problems with durable subscribers not being able to reconnect topics after an app restart. Some developers changed clientId and subscriberId and found they could reconnect. Overtime they created many durable subscriptions without unsubscribing previous ones. Now a single publication message can generate 70+ messages to the SYSTEM.JMS.D.SUBSCRIBER.QUEUE. The problem is we can't figure out how to get rid of the subscriptions thereby stopping the undesired publication messages. We've run Cleanup. We've manually purged the SYSTEM.JMS.ADMIN.QUEUE. We've even deleted entries via the WMQI Command Center Subscriptions dialogue. We're stumped!

Can anyone elaborate on an administrative procedure to properly manage the removal of durable subscriptions?

Thanks!
Back to top
View user's profile Send private message
bower5932
PostPosted: Thu Nov 13, 2003 7:20 am    Post subject: Reply with quote

Jedi Knight

Joined: 27 Aug 2001
Posts: 3023
Location: Dallas, TX, USA

I would have thought the WMQI management of the subscribers would have worked. I don't think the cleanup utility will do anything for your durable subscribers. Technically, these can't be orphaned since they have a valid registration. The non-durable subscribers can orphan themselves by leaving without deregistering and this is what the cleanup is designed to fix. I'd be careful purging the queues. There can be multiple references across various queues and you could end up with a qmgr/broker that doesn't work.
Back to top
View user's profile Send private message Send e-mail Visit poster's website AIM Address Yahoo Messenger
clinch
PostPosted: Thu Nov 13, 2003 12:24 pm    Post subject: Reply with quote

Newbie

Joined: 12 Nov 2003
Posts: 2

Thanks for your feedback.

We aren't too worried about deleting entries from development queue managers/brokers but we are concerned about the long term administration of JMS durable subscribers in production. We don't seem to be able to clear out unwanted durable subscriptions that originated from JMS apps. (Not to mention our puzzlement over figuring out who the JMS subscriptions belong to?)

The key point here is the JMS durable subscribers are registered automagically via the JMS application. They do appear on the WMQI subscriptions tab but WMQI doesn't seem to control them.

If anyone knows defnitively how this is supposed to work we real interested. Do we have a bug, installation/configuration problem etc. The manuals and redbooks always stop short of the fine details.


Thanks again!
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic  Reply to topic Page 1 of 1

MQSeries.net Forum Index » IBM MQ Java / JMS » Orphaned JMS Durable Subscribers w/WMQI broker
Jump to:  



You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
Protected by Anti-Spam ACP
 
 


Theme by Dustin Baccetti
Powered by phpBB © 2001, 2002 phpBB Group

Copyright © MQSeries.net. All rights reserved.