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 » General IBM MQ Support » Change SYSTEM.DEFAULT.SUB to be DURABLE(NO)?

Post new topic  Reply to topic
 Change SYSTEM.DEFAULT.SUB to be DURABLE(NO)? « View previous topic :: View next topic » 
Author Message
gbarber
PostPosted: Tue Mar 17, 2020 1:23 pm    Post subject: Change SYSTEM.DEFAULT.SUB to be DURABLE(NO)? Reply with quote

Novice

Joined: 16 Jan 2020
Posts: 10

I have a V9.1.0.2 MQ installation on RHEL with PUBSUB enabled in the QM
My V6 JMS client subscriptions show up as DURABLE(YES), but don't behave that way (as evidenced by kill -9 of the clients not leaving any subscriptions on the queue manager)
However C++ based client subscriptions do appear to leave behind orphans when the client application is killed abruptly, which is undesirable in my environnment.
I'm looking for a way to change the default subscription so that it does not show up as DURABLE(YES)
ALTER for a SUB doesn't seem to support changing the DURABLE attribute.
Back to top
View user's profile Send private message
hughson
PostPosted: Tue Mar 17, 2020 8:04 pm    Post subject: Re: Change SYSTEM.DEFAULT.SUB to be DURABLE(NO)? Reply with quote

Padawan

Joined: 09 May 2013
Posts: 1914
Location: Bay of Plenty, New Zealand

gbarber wrote:
I'm looking for a way to change the default subscription so that it does not show up as DURABLE(YES)
ALTER for a SUB doesn't seem to support changing the DURABLE attribute.

Are your subscriptions that are left behind administratively created or API created subscriptions?

You can do a DISPLAY SUB and look for the SUBTYPE attributes to see whether they are ADMIN or API.

Subscriptions that are made with the DEFINE SUB command (aka administrative subscriptions) can only be DURABLE - because there is nothing connected to them at the time they are made, and so if they were NONDURABLE they would immediately disappear again. This is why you cannot change the SYSTEM.DEFAULT.SUB to be non-durable.

Discover how your C++ applications are creating the subscriptions - use Application Activity Trace if you can't see the code.

Cheers,
Morag
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software
Back to top
View user's profile Send private message Visit poster's website
rhbroberg
PostPosted: Wed Mar 18, 2020 8:37 am    Post subject: our subscription code Reply with quote

Newbie

Joined: 18 Mar 2020
Posts: 1

(I work with gbarber, this is the same issue).

The durability, as far as I can tell, is not ADMIN based but API based. We are using the mqm C API for subscribing. Here is the snippet of code which does the subscription, pared down a fair amount (it was modified from original ibm sample code)

Code:

    RWCString subscriptionTopic = topic();
    ImqPutMessageOptions pmo;
    ImqMessage msg;
    MQLONG messageLength;
    PMQBYTE pMessageBlock = NULL;
    MQLONG CompCode = MQCC_FAILED;

    /*******************************************************************/
    /* Allocate a block of storage to hold the Command message. */
    /*******************************************************************/
    messageLength = getIntProperty(AMQ_DEFAULT_SENDING_SIZE);
    pMessageBlock = (PMQBYTE) new unsigned char[messageLength];
    MemoryGuard<unsigned char> g(pMessageBlock, true);

    /*****************************************************************/
    /* Define an MQRFH structure at the start of the allocated */
    /* storage, fill in the required fields and generate the */
    /* NameValueString that follows it. */
    /*****************************************************************/
    buildMQRFHeader(pMessageBlock
                    , &messageLength
                    , Command
                    , regOptions
                    , MQPUBO_NONE
                    , subscriptionTopic);
    /*****************************************************************/
    /* Send the command as a request so that a reply is returned to */
    /* us on completion at the broker. */
    /*****************************************************************/
    msg.setFormat(MQFMT_RF_HEADER);
    msg.setMessageType(MQMT_REQUEST);
    /*****************************************************************/
    /* Specify the subscriber's queue in the ReplyToQ of the MD. */
    /* We have not put the subscriber's queue in the MQRFH */
    /* NameValueString so the one in the ReplyToQ of the MD will be */
    /* used as the identity of the subscriber. */
    /*****************************************************************/
    msg.setReplyToQueueName(_session->_subscriberQName);
    MQLONG setOptions = MQPMO_NEW_MSG_ID;

    if (_session->_eventCorrelId.isNull())
    {
      setOptions += MQPMO_NEW_CORREL_ID;
    }
    else
    {
      msg.setCorrelationId(_session->_eventCorrelId);
    }
    pmo.setOptions(setOptions);

    /*****************************************************************/
    /* All commands sent use the correlId as part of their identity. */
    /*****************************************************************/
    msg.useFullBuffer((char *) pMessageBlock, messageLength);
    /*****************************************************************/
    /* Put the command message to the broker control queue. */
    /*****************************************************************/

    /* _session->_controlQ is an ImqQueue object */
    _session->_controlQ.put(msg, pmo);
Back to top
View user's profile Send private message
gbarber
PostPosted: Wed Mar 18, 2020 8:46 am    Post subject: Re: Change SYSTEM.DEFAULT.SUB to be DURABLE(NO)? Reply with quote

Novice

Joined: 16 Jan 2020
Posts: 10

hughson wrote:
gbarber wrote:
I'm looking for a way to change the default subscription so that it does not show up as DURABLE(YES)
ALTER for a SUB doesn't seem to support changing the DURABLE attribute.

Are your subscriptions that are left behind administratively created or API created subscriptions?

You can do a DISPLAY SUB and look for the SUBTYPE attributes to see whether they are ADMIN or API.

Subscriptions that are made with the DEFINE SUB command (aka administrative subscriptions) can only be DURABLE - because there is nothing connected to them at the time they are made, and so if they were NONDURABLE they would immediately disappear again. This is why you cannot change the SYSTEM.DEFAULT.SUB to be non-durable.

Discover how your C++ applications are creating the subscriptions - use Application Activity Trace if you can't see the code.

Cheers,
Morag


You can see the details of how the C++ subscription is created in the reply from my colleague "rhbroberg"

Here is a subscription from a JMS app, which disappears as soon as the subscribing application is killed with the -9 option
AMQ8096I: IBM MQ subscription inquired.
SUBID(414D51205354524757303120202020205E6CCC5E21F56AE7)
SUB(STRGW01 SYSTEM.JMS.ND.DAWORKS.SUBSCRIBER.QUEUE 414D51205354524757303120202020205E6CCC5E22177908 IA*.IBM.DAWorks.ControlJobInformation)
TOPICSTR(IA*.ABC.DAWorks.ControlJobInformation)
TOPICOBJ(SYSTEM.BROKER.DEFAULT.STREAM)
DISTYPE(RESOLVED)
DEST(SYSTEM.JMS.ND.DAWORKS.SUBSCRIBER.QUEUE)
DESTQMGR(STRGW01) PUBAPPID( )
SELECTOR( ) SELTYPE(NONE)
USERDATA( )
PUBACCT(0000000000000000000000000000000000000000000000000000000000000000)
DESTCORL(414D51205354524757303120202020205E6CCC5E22177908)
DESTCLAS(PROVIDED) DURABLE(YES)
EXPIRY(UNLIMITED) PSPROP(COMPAT)
PUBPRTY(ASPUB) REQONLY(NO)
SUBSCOPE(ALL) SUBLEVEL(1)
SUBTYPE(API) VARUSER(FIXED)
WSCHEMA(CHAR) SUBUSER(daworks)
CRDATE(2020-03-16) CRTIME(13:12:59)
ALTDATE(2020-03-16) ALTTIME(13:12:59)

Here is a subscription from a C++ app, which continues to exist on the queue manager when the subscribing application is killed with the -9 option
AMQ8096I: IBM MQ subscription inquired.
SUBID(414D51205354524757303120202020205E6CCC5E2236212E)
SUB(STRGW01 SYSTEM.JMS.ND.NVS.SUBSCRIBER.QUEUE 616D71373531303435333336313230393132363334353534 IC07.NVS.ARGUS.ControlJobInformation)
TOPICSTR(IC07.NVS.ARGUS.ControlJobInformation)
TOPICOBJ(SYSTEM.BROKER.DEFAULT.STREAM)
DISTYPE(RESOLVED)
DEST(SYSTEM.JMS.ND.NVS.SUBSCRIBER.QUEUE)
DESTQMGR(STRGW01) PUBAPPID( )
SELECTOR( ) SELTYPE(NONE)
USERDATA( )
PUBACCT(0000000000000000000000000000000000000000000000000000000000000000)
DESTCORL(616D71373531303435333336313230393132363334353534)
DESTCLAS(PROVIDED) DURABLE(YES)
EXPIRY(UNLIMITED) PSPROP(COMPAT)
PUBPRTY(ASPUB) REQONLY(NO)
SUBSCOPE(ALL) SUBLEVEL(1)
SUBTYPE(API) VARUSER(FIXED)
WSCHEMA(CHAR) SUBUSER(argus)
CRDATE(2020-03-18) CRTIME(09:49:35)
ALTDATE(2020-03-18) ALTTIME(09:49:35)
Back to top
View user's profile Send private message
hughson
PostPosted: Wed Mar 18, 2020 6:47 pm    Post subject: Re: Change SYSTEM.DEFAULT.SUB to be DURABLE(NO)? Reply with quote

Padawan

Joined: 09 May 2013
Posts: 1914
Location: Bay of Plenty, New Zealand

gbarber wrote:
Here is a subscription from a JMS app, which disappears as soon as the subscribing application is killed with the -9 option
AMQ8096I: IBM MQ subscription inquired.
SUBID(414D51205354524757303120202020205E6CCC5E21F56AE7)
SUB(STRGW01 SYSTEM.JMS.ND.DAWORKS.SUBSCRIBER.QUEUE 414D51205354524757303120202020205E6CCC5E22177908 IA*.IBM.DAWorks.ControlJobInformation)
TOPICSTR(IA*.ABC.DAWorks.ControlJobInformation)
TOPICOBJ(SYSTEM.BROKER.DEFAULT.STREAM)
DESTCLAS(PROVIDED) DURABLE(YES)

Here is a subscription from a C++ app, which continues to exist on the queue manager when the subscribing application is killed with the -9 option
AMQ8096I: IBM MQ subscription inquired.
SUBID(414D51205354524757303120202020205E6CCC5E2236212E)
SUB(STRGW01 SYSTEM.JMS.ND.NVS.SUBSCRIBER.QUEUE 616D71373531303435333336313230393132363334353534 IC07.NVS.ARGUS.ControlJobInformation)
TOPICSTR(IC07.NVS.ARGUS.ControlJobInformation)
TOPICOBJ(SYSTEM.BROKER.DEFAULT.STREAM)
DESTCLAS(PROVIDED) DURABLE(YES)

Both of these subscriptions are DURABLE. So it is not the queue manager that is removing them. Something is un-subscribing them.

I see from the earlier reply that these are Queued Pub/Sub subscriptions and not MQSUB subscriptions.

If memory serves there is some special internal interface that JMS used back in these Queued Pub/Sub days, called something like "last will and testament" where a message was put to the side to be delivered should the connection terminate. This message would be an unsubscribe command. I have no idea whether C++ had the same.

Has this behaviour changed going from V6 to V9.1? If so, you should raise a PMR to IBM to put back what has been lost.

If the behaviour hasn't changed, I doubt any additions would be made to the Queued Pub/Sub interface now. Using MQSUB would be the way forward.

Cheers,
Morag
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software
Back to top
View user's profile Send private message Visit poster's website
gbarber
PostPosted: Thu Mar 19, 2020 11:39 am    Post subject: Re: Change SYSTEM.DEFAULT.SUB to be DURABLE(NO)? Reply with quote

Novice

Joined: 16 Jan 2020
Posts: 10

hughson wrote:
gbarber wrote:
Here is a subscription from a JMS app, which disappears as soon as the subscribing application is killed with the -9 option
AMQ8096I: IBM MQ subscription inquired.
SUBID(414D51205354524757303120202020205E6CCC5E21F56AE7)
SUB(STRGW01 SYSTEM.JMS.ND.DAWORKS.SUBSCRIBER.QUEUE 414D51205354524757303120202020205E6CCC5E22177908 IA*.IBM.DAWorks.ControlJobInformation)
TOPICSTR(IA*.ABC.DAWorks.ControlJobInformation)
TOPICOBJ(SYSTEM.BROKER.DEFAULT.STREAM)
DESTCLAS(PROVIDED) DURABLE(YES)

Here is a subscription from a C++ app, which continues to exist on the queue manager when the subscribing application is killed with the -9 option
AMQ8096I: IBM MQ subscription inquired.
SUBID(414D51205354524757303120202020205E6CCC5E2236212E)
SUB(STRGW01 SYSTEM.JMS.ND.NVS.SUBSCRIBER.QUEUE 616D71373531303435333336313230393132363334353534 IC07.NVS.ARGUS.ControlJobInformation)
TOPICSTR(IC07.NVS.ARGUS.ControlJobInformation)
TOPICOBJ(SYSTEM.BROKER.DEFAULT.STREAM)
DESTCLAS(PROVIDED) DURABLE(YES)

Both of these subscriptions are DURABLE. So it is not the queue manager that is removing them. Something is un-subscribing them.

I see from the earlier reply that these are Queued Pub/Sub subscriptions and not MQSUB subscriptions.

If memory serves there is some special internal interface that JMS used back in these Queued Pub/Sub days, called something like "last will and testament" where a message was put to the side to be delivered should the connection terminate. This message would be an unsubscribe command. I have no idea whether C++ had the same.

Has this behaviour changed going from V6 to V9.1? If so, you should raise a PMR to IBM to put back what has been lost.

If the behaviour hasn't changed, I doubt any additions would be made to the Queued Pub/Sub interface now. Using MQSUB would be the way forward.

Cheers,
Morag


V9 JMS client subscriptions dont show up as DURABLE so there is no risk of leaving orphans there. When you mention that a message is put to the side to be delivered if the connection terminates, do you mean by the broker? or by the client?
If it's the broker that would explain the behavior.
Another observation is that, when the java application that is using the V6 JARs is reconfigured to use the V9.1 JMS JAR, the subscriptions show up as DURABLE(NO). And there are some other differences also... Here is the MQ explorer subscription export for a V6 and a V9 subscription. These were made with the same application with only the JMS jar version changed. Things to note are that the Wildcard format is different, the Durable value is different, and the destination queue is different even though the Broker sub queue is specified as SYSTEM.JMS.ND.PSC.SUBSCRIBER.QUEUE in both cases.
Do you know why the subscriptions would look so different with just a JMS version change?

Subscription name,Topic name,Topic string,Wildcard usage,Scope,Destination class,Destination queue manager,Destination name,Durable,Type,Properties,User data,Selector,Selector type,Variable user ID,User,App identity data,Accounting token,Publish priority,Correlation identifier,Subscription ID,Expiry,Request only,Subscription level,Creation date,Creation time,Alteration date,Alteration time
INTBRK01 SYSTEM.JMS.ND.PSC.SUBSCRIBER.QUEUE 414D5120494E5442524B3031202020205E68F8EE21852808 V6.test,SYSTEM.BROKER.DEFAULT.STREAM,V6.test,Character level wildcard,All,Provided,INTBRK01,SYSTEM.JMS.ND.PSC.SUBSCRIBER.QUEUE,Yes,API,Compatibility,,,None,Fixed,mqm,,0,As published,414D5120494E5442524B3031202020205E68F8EE21852808,414D5120494E5442524B3031202020205E68F8EE21819010,Unlimited,All,1,16-Mar-20,3:02:22 PM,16-Mar-20,3:02:22 PM
,,V9.test2,Topic level wildcard,All,Managed,INTBRK01,SYSTEM.MANAGED.NDURABLE.5E68F8EE21850403,No,API,Message properties,,,None,Fixed,notify,,0,As published,414D5120494E5442524B3031202020205E68F8EE21850404,414D5120494E5442524B3031202020205E68F8EE21850404,Unlimited,All,1,16-Mar-20,2:42:30 PM,16-Mar-20,2:42:30 PM
Back to top
View user's profile Send private message
hughson
PostPosted: Thu Mar 19, 2020 7:22 pm    Post subject: Re: Change SYSTEM.DEFAULT.SUB to be DURABLE(NO)? Reply with quote

Padawan

Joined: 09 May 2013
Posts: 1914
Location: Bay of Plenty, New Zealand

gbarber wrote:
V9 JMS client subscriptions dont show up as DURABLE so there is no risk of leaving orphans there.

The JMS Client at V9 will use MQSUB - unless you deliberately tell it to use the back-level ProviderVersion=6. So this is not a surprise. With the introduction of native Pub/Sub in the MQ queue manager at V7, the concept of durability (or not) was understood natively by the queue manager where it wasn't in V6 and earlier.

gbarber wrote:
When you mention that a message is put to the side to be delivered if the connection terminates, do you mean by the broker? or by the client?
If it's the broker that would explain the behavior.

I think it was the JMS layer itself that did it. When I said to check whether you had lost something moving from V6 to V9, I meant the C++ application which was using the queued interface directly. Did it get unsubscribed at V6 if you killed the application?


gbarber wrote:
Another observation is that, when the java application that is using the V6 JARs is reconfigured to use the V9.1 JMS JAR, the subscriptions show up as DURABLE(NO). And there are some other differences also... Here is the MQ explorer subscription export for a V6 and a V9 subscription. These were made with the same application with only the JMS jar version changed. Things to note are that the Wildcard format is different, the Durable value is different, and the destination queue is different even though the Broker sub queue is specified as SYSTEM.JMS.ND.PSC.SUBSCRIBER.QUEUE in both cases.
Do you know why the subscriptions would look so different with just a JMS version change?


It'll be because you are now utilising a completely different interface - you are now using MQSUB instead of the queued pub/sub interface. If you want them to look more similar you could tell the JMS interface to use the ProviderVersion=6 interface to continue using the queued pub/sub interface.

Cheers,
Morag
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software
Back to top
View user's profile Send private message Visit poster's website
gbarber
PostPosted: Fri Mar 20, 2020 6:47 am    Post subject: Re: Change SYSTEM.DEFAULT.SUB to be DURABLE(NO)? Reply with quote

Novice

Joined: 16 Jan 2020
Posts: 10

hughson wrote:
gbarber wrote:
V9 JMS client subscriptions dont show up as DURABLE so there is no risk of leaving orphans there.

The JMS Client at V9 will use MQSUB - unless you deliberately tell it to use the back-level ProviderVersion=6. So this is not a surprise. With the introduction of native Pub/Sub in the MQ queue manager at V7, the concept of durability (or not) was understood natively by the queue manager where it wasn't in V6 and earlier.

gbarber wrote:
When you mention that a message is put to the side to be delivered if the connection terminates, do you mean by the broker? or by the client?
If it's the broker that would explain the behavior.

I think it was the JMS layer itself that did it. When I said to check whether you had lost something moving from V6 to V9, I meant the C++ application which was using the queued interface directly. Did it get unsubscribed at V6 if you killed the application?


gbarber wrote:
Another observation is that, when the java application that is using the V6 JARs is reconfigured to use the V9.1 JMS JAR, the subscriptions show up as DURABLE(NO). And there are some other differences also... Here is the MQ explorer subscription export for a V6 and a V9 subscription. These were made with the same application with only the JMS jar version changed. Things to note are that the Wildcard format is different, the Durable value is different, and the destination queue is different even though the Broker sub queue is specified as SYSTEM.JMS.ND.PSC.SUBSCRIBER.QUEUE in both cases.
Do you know why the subscriptions would look so different with just a JMS version change?


It'll be because you are now utilising a completely different interface - you are now using MQSUB instead of the queued pub/sub interface. If you want them to look more similar you could tell the JMS interface to use the ProviderVersion=6 interface to continue using the queued pub/sub interface.

Cheers,
Morag


Thanks Morag! That all makes sense. I think that the C++ apps subscriptions did used to get automatically unsubscribed. I'll discuss that some more with the folks who were more involved with it before we upgraded our servers to MQ 9.1
Back to top
View user's profile Send private message
fjb_saper
PostPosted: Sun Mar 22, 2020 9:18 pm    Post subject: Reply with quote

Grand High Poobah

Joined: 18 Nov 2003
Posts: 20696
Location: LI,NY

Also why is a DURABLE subscription on the SYSTEM.JMS.ND.* queue ? Do they not have any of the SYSTEM.JMS.D.* queues defined for durable subscriptions?
_________________
MQ & Broker admin
Back to top
View user's profile Send private message Send e-mail
gbarber
PostPosted: Mon Mar 23, 2020 8:20 am    Post subject: Reply with quote

Novice

Joined: 16 Jan 2020
Posts: 10

fjb_saper wrote:
Also why is a DURABLE subscription on the SYSTEM.JMS.ND.* queue ? Do they not have any of the SYSTEM.JMS.D.* queues defined for durable subscriptions?


Right, that's one of the puzzling things here. The client isn't asking the broker to set the subscription up as durable, hence the use of the SYSTEM.JMS.ND.* queues. Sounds like with the new (> V7.0) broker behavior is that an old (< V7.5) client's subscription can't be anything other than Durable, but that it's supposed to manage them in a way that the subscriptions don't really linger after the connection is closed, which the broker seems to be doing correctly for the older JMS client connections, but not for the older C++ client connections.
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 » General IBM MQ Support » Change SYSTEM.DEFAULT.SUB to be DURABLE(NO)?
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.