Author |
Message
|
krypton |
Posted: Tue Sep 04, 2018 7:01 am Post subject: Does Queue has parameter to specify expiry of messages? |
|
|
 Disciple
Joined: 14 Mar 2010 Posts: 186
|
Hi, we want to set message expiry period at MQ Local Queue level but I could not find any such parameter.
Is there any such way where as an admin I can set message coming to a particular queue to expire at a specified interval.
I don't want to give the control/dependency to the application putting the messages. _________________ Dreams are not something which you watch when you are asleep,it is something which doesn't let you sleep. |
|
Back to top |
|
 |
exerk |
Posted: Tue Sep 04, 2018 7:51 am Post subject: Re: Does Queue has parameter to specify expiry of messages? |
|
|
 Jedi Council
Joined: 02 Nov 2006 Posts: 6339
|
krypton wrote: |
Hi, we want to set message expiry period at MQ Local Queue level but I could not find any such parameter... |
Look harder...
krypton wrote: |
..Is there any such way where as an admin I can set message coming to a particular queue to expire at a specified interval... |
Yes, depending on MQ version...
krypton wrote: |
...I don't want to give the control/dependency to the application putting the messages. |
Why not? It's their data and you should not arbitrarily be expiring business messages. _________________ It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
Back to top |
|
 |
krypton |
Posted: Tue Sep 04, 2018 8:00 am Post subject: Re: Does Queue has parameter to specify expiry of messages? |
|
|
 Disciple
Joined: 14 Mar 2010 Posts: 186
|
exerk wrote: |
krypton wrote: |
Hi, we want to set message expiry period at MQ Local Queue level but I could not find any such parameter... |
Look harder...
Went through all the Queue parameters listed here, could not find.
https://www.ibm.com/support/knowledgecenter/en/SSFKSJ_7.5.0/com.ibm.mq.ref.adm.doc/q085690_.htm
Please help if you know of such parameter.
krypton wrote: |
..Is there any such way where as an admin I can set message coming to a particular queue to expire at a specified interval... |
Yes, depending on MQ version...
We are using version -: 8.0.0.2 and the OS is LINUX.
krypton wrote: |
...I don't want to give the control/dependency to the application putting the messages. |
Why not? It's their data and you should not arbitrarily be expiring business messages. |
They are reluctant to change their configuration/code and deploy again in production environment, so it is application team wish only that we control that parameter at MQ level. _________________ Dreams are not something which you watch when you are asleep,it is something which doesn't let you sleep. |
|
Back to top |
|
 |
exerk |
Posted: Tue Sep 04, 2018 8:12 am Post subject: Re: Does Queue has parameter to specify expiry of messages? |
|
|
 Jedi Council
Joined: 02 Nov 2006 Posts: 6339
|
krypton wrote: |
...They are reluctant to change their configuration/code and deploy again in production environment, so it is application team wish only that we control that parameter at MQ level. |
Get that 'business' requirement carved in stone, in triplicate, coped, and copied again, and archived in as many different places in the world that you can. That way, when the business comes for you because a very, very important message has been 'lost' because you've expired, maybe (just maybe) they'll not crucify you. _________________ It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
Back to top |
|
 |
krypton |
Posted: Tue Sep 04, 2018 9:04 am Post subject: Re: Does Queue has parameter to specify expiry of messages? |
|
|
 Disciple
Joined: 14 Mar 2010 Posts: 186
|
exerk wrote: |
krypton wrote: |
...They are reluctant to change their configuration/code and deploy again in production environment, so it is application team wish only that we control that parameter at MQ level. |
Get that 'business' requirement carved in stone, in triplicate, coped, and copied again, and archived in as many different places in the world that you can. That way, when the business comes for you because a very, very important message has been 'lost' because you've expired, maybe (just maybe) they'll not crucify you. |
Done!
Well, if you can also share how to expire messages at MQ level, then this is something we will have in our knowledge base. _________________ Dreams are not something which you watch when you are asleep,it is something which doesn't let you sleep. |
|
Back to top |
|
 |
krypton |
Posted: Tue Sep 04, 2018 9:12 am Post subject: Re: Does Queue has parameter to specify expiry of messages? |
|
|
 Disciple
Joined: 14 Mar 2010 Posts: 186
|
[quote="exerk"]
krypton wrote: |
Hi, we want to set message expiry period at MQ Local Queue level but I could not find any such parameter... |
Look harder...
Hi Exerk, you were right to advise to look harder. I found a parameter at this link
https://www.ibm.com/support/knowledgecenter/SSFKSJ_8.0.0/com.ibm.mq.ref.adm.doc/q085690_.htm
CAPEXPRY _________________ Dreams are not something which you watch when you are asleep,it is something which doesn't let you sleep. |
|
Back to top |
|
 |
krypton |
Posted: Tue Sep 04, 2018 10:12 am Post subject: |
|
|
 Disciple
Joined: 14 Mar 2010 Posts: 186
|
unfortunately the parameter didnt work.
Although we tried to change the Qlocal using MQSC command,and the mqsc returned a successful change message(AMQ8088) but the parameter didn't reflect. I was hoping all the NEW messages will be automatically deleted after 30 minutes, but that didn't happen.
ALTER QL(TINKER.TAILOR.SOLDER.QUEUE) CUSTOM('CAPEXPRY(18000)')
AMQ8008: WebSphere MQ queue changed.
could it be because this parameter is not compatible for the following version of MQ and Operating System?
Version: 8.0.0.2
O/S: Linux 2.6.32-754.2.1.el6.x86_64 _________________ Dreams are not something which you watch when you are asleep,it is something which doesn't let you sleep. |
|
Back to top |
|
 |
krypton |
Posted: Tue Sep 04, 2018 10:18 am Post subject: |
|
|
 Disciple
Joined: 14 Mar 2010 Posts: 186
|
looks like this parameter was implemented only in V8.0.0.4 and above.
CUSTOM ( string )
The custom attribute for new features.
[V8.0.0.4 Oct 2015]This attribute contains the values of attributes, as pairs of attribute name and value, separated by at least one space. The attribute name and value pairs have the form NAME(VALUE). Single quotation marks must be escaped with another single quotation mark.
CAPEXPRY ( integer )
The maximum time, expressed in tenths of a second, until a message put using an object handle with this object in the resolution path, becomes eligible for expiry processing.
For more information on message expiry processing, see Enforcing lower expiration times.
integer
The value must be in the range one through to 999 999 999.
NOLIMIT
There is no limit on the expiry time of messages put using this object. This is the default value.
Specifying a value for CAPEXPRY that is not valid, does not cause the command to fail. Instead the default value is used.
Note that existing messages in the queue, prior to a change in CAPEXPRY, are not affected by the change (that is, their expiry time remains intact). Only new messages that are put into the queue after the change in CAPEXPRY have the new expiry time. _________________ Dreams are not something which you watch when you are asleep,it is something which doesn't let you sleep. |
|
Back to top |
|
 |
zpat |
Posted: Tue Sep 04, 2018 11:16 am Post subject: |
|
|
 Jedi Council
Joined: 19 May 2001 Posts: 5866 Location: UK
|
A very useful feature - well done the person who raised the RFE..  _________________ Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error. |
|
Back to top |
|
 |
exerk |
Posted: Tue Sep 04, 2018 1:46 pm Post subject: |
|
|
 Jedi Council
Joined: 02 Nov 2006 Posts: 6339
|
krypton wrote: |
...Note that existing messages in the queue, prior to a change in CAPEXPRY, are not affected by the change (that is, their expiry time remains intact). Only new messages that are put into the queue after the change in CAPEXPRY have the new expiry time. |
Note the above. _________________ It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
Back to top |
|
 |
k_usa |
Posted: Mon Mar 04, 2019 2:52 pm Post subject: |
|
|
Apprentice
Joined: 14 Aug 2006 Posts: 42 Location: NewJersey
|
zpat wrote: |
A very useful feature - well done the person who raised the RFE..  |
Be careful with using this feature on cluster transmit queues. Someone at my place accidentally set this for XMIT queues also, which caused the cluster objects expire frequently. IBM L3 said they need to fix the MQ code to handle this issue |
|
Back to top |
|
 |
vicks_mq |
Posted: Sun Apr 07, 2019 7:35 am Post subject: |
|
|
Disciple
Joined: 03 Oct 2017 Posts: 162
|
exerk wrote: |
krypton wrote: |
...Note that existing messages in the queue, prior to a change in CAPEXPRY, are not affected by the change (that is, their expiry time remains intact). Only new messages that are put into the queue after the change in CAPEXPRY have the new expiry time. |
Note the above. |
I have come across a different problem here, earlier I was using CAPEXPRY parameter to forcefully expire message of an application, now we have another application (which sends the request) which has message expiring in 30 mins and the application which processes the message from REQUEST Q is having a downtime.
So I have been asked to save those request messages from expiring. (The sending application has set the expire interval as 30 mins).
So I went ahead and changed the CAPEXPIRY to 10 hours(600 mins) but it is not reflected for new messages. What could be the reason?
ALTER QL(ABC.REQ.QUEUE) CUSTOM('CAPEXPRY(360000)') |
|
Back to top |
|
 |
exerk |
Posted: Sun Apr 07, 2019 9:37 am Post subject: |
|
|
 Jedi Council
Joined: 02 Nov 2006 Posts: 6339
|
The reason is that the expiry set on the messages is lower than that set on the queue, therefore the lower expiry time will be honoured. From the KC:
Quote: |
...An expiry time specified in the Expiry field of the MQMD, by an application, which is greater than the CAPEXPRY value specified in the CUSTOM attribute on the queue or topic will be replaced by that CAPEXPRY value. An expiry time specified by an application, which is lower than the CAPEXPRY value, will be used... |
All the information is there, should you care to read it. _________________ It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
Back to top |
|
 |
bruce2359 |
Posted: Sun Apr 07, 2019 9:47 am Post subject: |
|
|
 Poobah
Joined: 05 Jan 2008 Posts: 9469 Location: US: west coast, almost. Otherwise, enroute.
|
What expiry does the app specify in the MQMD? An expiry time specified by an application, which is lower than the CAPEXPRY value, the application value will be used. If object definitions (QRemote, QAlias, Topic) set the expiry, the lower value will be used. _________________ I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
Back to top |
|
 |
vicks_mq |
Posted: Mon Apr 08, 2019 4:28 am Post subject: |
|
|
Disciple
Joined: 03 Oct 2017 Posts: 162
|
exerk wrote: |
The reason is that the expiry set on the messages is lower than that set on the queue, therefore the lower expiry time will be honoured. From the KC:
Quote: |
...An expiry time specified in the Expiry field of the MQMD, by an application, which is greater than the CAPEXPRY value specified in the CUSTOM attribute on the queue or topic will be replaced by that CAPEXPRY value. An expiry time specified by an application, which is lower than the CAPEXPRY value, will be used... |
All the information is there, should you care to read it. |
Thank you for providing this useful piece of information.
Our Application is specifying the time in MQMD.Expiry as 18000,
and I changed the CAPEXPIRY at queue level to 360000.
because the application value is lower so it will take that value. |
|
Back to top |
|
 |
|