| Author |
Message
|
| kayoumt |
 Posted: Sun May 31, 2009 8:34 am Post subject: XMS : Temporary Subscription vs Temporay Topic |
 |
|
Voyager
Joined: 18 Sep 2007
Posts: 81
|
Hi,
My first XMS code is simple Publisher and Subscriber. Subscriptions are supposed to be non-persistent.
I want to know why the topic names I created for NON-DURABLE subscriptions (dynamically, by programming) are not removed from MQ when my applications stop running ? I see them on MQ Explorer when I click on Topics and Status.
Thanks for any help.
See some representative C++ code below.
-- Subscriber :
sess = conn.createSession(xmsFALSE, XMSC_AUTO_ACKNOWLEDGE);
dest = Destination(XMS_DESTINATION_TYPE_TOPIC, "CADS6/TEST");
consumer = sess.createConsumer(dest);
consumer.setMessageListener(&sub_listener);
-- Publisher :
sess = conn.createSession(xmsFALSE, XMSC_AUTO_ACKNOWLEDGE);
dest = Destination(XMS_DESTINATION_TYPE_TOPIC, "CADS6/TEST");
producer = sess.createProducer(dest); |
|
| Back to top |
|
 |
| shashikanth_in |
| Posted: Sun Jun 07, 2009 7:55 am Post subject: |
|
|
Centurion
Joined: 26 Feb 2009
Posts: 123
|
I think the same question was answered in mq newsgroup.
Yes, I have also seen this behavior. It's not specific to XMS, happens with MQ samples also. Topics created dynamically are retained in topic tree till the queue manager is shutdown.
I think the reason for the above behavior is:
It's possible that a subscriber may subscribe many times to the same topic. So the queue manager retains the topic in the topic tree. When a another subscription is made to the same topic next time, the queue manager will just re-use the existing topic node, instead of creating a new one.
HTH |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Sun Jun 07, 2009 8:26 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
|
| Back to top |
|
|
| kayoumt |
| Posted: Sun Jun 07, 2009 8:37 am Post subject: |
|
|
Voyager
Joined: 18 Sep 2007
Posts: 81
|
shashikanth_in,
That feature (Temporary Dynamic topics owned by the Subscriber) was working with RFH pub/sub on WMQ 6 broker. As far as I know that MQ pub/sub broker has been implemented as a supportpac since MQ 5.3.
Below, I show the key options to set in FRH to make that feature work in WMQ 6.
Subscriber :
MQPSCommand RegSub
MQPSRegOpts NoReg
Publisher :
MQPSCommand Publish
MQPSPubOpts NonPers
Is the feature missing in XMS or in WMQ 7.0 ? |
|
| Back to top |
|
|
| kayoumt |
| Posted: Sun Jun 07, 2009 8:54 am Post subject: |
|
|
Voyager
Joined: 18 Sep 2007
Posts: 81
|
My mistake ! Option NoReg goes with Publisher and NonPers with Subscriber.
Subscriber :
MQPSCommand RegSub
MQPSRegOpts NonPers
Publisher :
MQPSCommand Publish
MQPSPubOpts NoReg
|
|
| Back to top |
|
|
| kayoumt |
| Posted: Sun Jun 07, 2009 9:38 am Post subject: |
|
|
Voyager
Joined: 18 Sep 2007
Posts: 81
|
| Quote: |
| http://www.ibm.com/developerworks/websphere/library/techarticles/0710_titheridge/0710_titheridge.html |
That article is interesting and could help me solve my problem. But ; it seems it is relevant mainly for WMQ 6.0. I searched the amqspsd command in my WMQ 7 installation ; I do not find it. Does someone know a similar command ?
| Quote: |
RegistrationOptions: 17 : MQREGO_CORREL_ID_AS_IDENTITY
MQREGO_NEW_PUBLICATIONS_ONLY
|
| Quote: |
RegistrationOptions: 1049601 : MQREGO_CORREL_ID_AS_IDENTITY
MQREGO_NON_PERSISTENT
MQREGO_VARIABLE_USER_ID
|
These options (in the amqspsd output in the article) are similar to my RFH options. If I'm able to generate something similar with XMS, I think it will help me me a lot. |
|
| Back to top |
|
|
| kayoumt |
| Posted: Sun Jun 14, 2009 7:41 pm Post subject: |
|
|
Voyager
Joined: 18 Sep 2007
Posts: 81
|
I have some information about that issue. That information could be hints for solving the issue :
1) In "Session" object, there's a method called UnSubscribe. I did not try that method ; but, it could be a method for making the application UnSubscribe from a topic.
2) If I restart the queue manager, my "orphan" topics disappear. May be those topics are items in a system queue and that queue is cleaned by queue manager on Stop or Start.
Having more information on these two points and implementing them as mechanism which run before queue manager stops will probably solve my problem. |
|
| Back to top |
|
|
|
|
