| Author |
Message
|
| PeterPotkay |
 Posted: Mon Apr 08, 2019 5:11 am Post subject: |
 |
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
It may not translate obviously to languages other than English, but the clue is in the name of the parameter, "CAPEXPRY". The "CAP" indicates its the top, the upper limit.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
 |
| vicks_mq |
| Posted: Mon Apr 08, 2019 6:40 am Post subject: |
|
|
Disciple
Joined: 03 Oct 2017
Posts: 162
|
| PeterPotkay wrote: |
| It may not translate obviously to languages other than English, but the clue is in the name of the parameter, "CAPEXPRY". The "CAP" indicates its the top, the upper limit. |
Hi Peter, Thank you for replying. I think just like IBM has added this parameter to CAP the expiry, there should also be a parameter which can increase the interval of expiry.
Do you know where can I raise a RFE to request IBM to do this change? |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Apr 08, 2019 7:07 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| vicks_mq wrote: |
| Do you know where can I raise a RFE to request IBM to do this change? |
See here
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Apr 08, 2019 7:10 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| vicks_mq wrote: |
| there should also be a parameter which can increase the interval of expiry. |
Do you mean that the expiry of a given message (and remember expiry is a message property not a queue property) should be not less than a given value (i.e. FLOOREXPIRY) or that the value in all messages put to the queue should be increased by the value of the property?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| vicks_mq |
| Posted: Mon Apr 08, 2019 7:32 am Post subject: |
|
|
Disciple
Joined: 03 Oct 2017
Posts: 162
|
| Vitor wrote: |
| vicks_mq wrote: |
| there should also be a parameter which can increase the interval of expiry. |
Do you mean that the expiry of a given message (and remember expiry is a message property not a queue property) should be not less than a given value (i.e. FLOOREXPIRY) or that the value in all messages put to the queue should be increased by the value of the property? |
I am looking for "the value in all messages put to the queue should be increased by the value of the property".
Consider a production scenario, an application which send update message has set expiry to 30 mins and the receiving application is down and they are working to bring it up, but in the meantime the Sending application messages start getting expired in 30 mins one by one, we would not want that scenario.
So we need that at will we can save from expiry atleast all the new update messages coming so that we don't lose them. |
|
| Back to top |
|
|
| exerk |
| Posted: Mon Apr 08, 2019 7:37 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| vicks_mq wrote: |
| ...Consider a production scenario, an application which send update message has set expiry to 30 mins and the receiving application is down and they are working to bring it up, but in the meantime the Sending application messages start getting expired in 30 mins one by one, we would not want that scenario... |
Even though, perhaps, the application is setting 30 minutes because the messages have no validity past that time?
_________________
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 |
|
|
| Vitor |
| Posted: Mon Apr 08, 2019 7:41 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| vicks_mq wrote: |
| Vitor wrote: |
| vicks_mq wrote: |
| there should also be a parameter which can increase the interval of expiry. |
Do you mean that the expiry of a given message (and remember expiry is a message property not a queue property) should be not less than a given value (i.e. FLOOREXPIRY) or that the value in all messages put to the queue should be increased by the value of the property? |
I am looking for "the value in all messages put to the queue should be increased by the value of the property".
Consider a production scenario, an application which send update message has set expiry to 30 mins and the receiving application is down and they are working to bring it up, but in the meantime the Sending application messages start getting expired in 30 mins one by one, we would not want that scenario.
So we need that at will we can save from expiry atleast all the new update messages coming so that we don't lose them. |
a) Raise your RFE and I wish you all good fortune
b) I understand entirely the use case you outline
c) Be aware that this would be a significant change to the way the queue properties work; currently they're applied as the messages are put to the queue and don't act on messages already on the queue (like CAPEXIRY or DEFPSIST). I wonder (though I do not know nor have I ever worked for the IBM MQ team) how quickly such a major change would be implemented.
As an interim you may want to consider using QLOAD or similar to pull the messages off which the production outage is in effect, edit the expiry and reload them when it's all fixed.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Apr 08, 2019 7:43 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| exerk wrote: |
| vicks_mq wrote: |
| ...Consider a production scenario, an application which send update message has set expiry to 30 mins and the receiving application is down and they are working to bring it up, but in the meantime the Sending application messages start getting expired in 30 mins one by one, we would not want that scenario... |
Even though, perhaps, the application is setting 30 minutes because the messages have no validity past that time? |
It's a good point, but the sending application could be using "report on expiry" for tracking SLA or similar so they mean "30 minutes of processing time".
You wouldn't to just apply it without reference to the sender, as you correctly point out.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| vicks_mq |
| Posted: Mon Apr 08, 2019 8:31 am Post subject: |
|
|
Disciple
Joined: 03 Oct 2017
Posts: 162
|
| Vitor wrote: |
| exerk wrote: |
| vicks_mq wrote: |
| ...Consider a production scenario, an application which send update message has set expiry to 30 mins and the receiving application is down and they are working to bring it up, but in the meantime the Sending application messages start getting expired in 30 mins one by one, we would not want that scenario... |
Even though, perhaps, the application is setting 30 minutes because the messages have no validity past that time? |
It's a good point, but the sending application could be using "report on expiry" for tracking SLA or similar so they mean "30 minutes of processing time".
You wouldn't to just apply it without reference to the sender, as you correctly point out. |
As is the case with most things in our job, They did setup it up by mistake. |
|
| Back to top |
|
|
| vicks_mq |
| Posted: Mon Apr 08, 2019 9:26 am Post subject: |
|
|
Disciple
Joined: 03 Oct 2017
Posts: 162
|
| Vitor wrote: |
| vicks_mq wrote: |
| Vitor wrote: |
| vicks_mq wrote: |
| there should also be a parameter which can increase the interval of expiry. |
Do you mean that the expiry of a given message (and remember expiry is a message property not a queue property) should be not less than a given value (i.e. FLOOREXPIRY) or that the value in all messages put to the queue should be increased by the value of the property? |
I am looking for "the value in all messages put to the queue should be increased by the value of the property".
Consider a production scenario, an application which send update message has set expiry to 30 mins and the receiving application is down and they are working to bring it up, but in the meantime the Sending application messages start getting expired in 30 mins one by one, we would not want that scenario.
So we need that at will we can save from expiry atleast all the new update messages coming so that we don't lose them. |
a) Raise your RFE and I wish you all good fortune
b) I understand entirely the use case you outline
c) Be aware that this would be a significant change to the way the queue properties work; currently they're applied as the messages are put to the queue and don't act on messages already on the queue (like CAPEXIRY or DEFPSIST). I wonder (though I do not know nor have I ever worked for the IBM MQ team) how quickly such a major change would be implemented.
As an interim you may want to consider using QLOAD or similar to pull the messages off which the production outage is in effect, edit the expiry and reload them when it's all fixed. |
Can I just edit the expiry value in notepad after downloading the messages from Queue using Qload, wouldn't that corrupt the messages ? I was under the impression that you are not supposed to change anything in Qload message if you want to put it back in MQ Queue without any issue. |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Apr 08, 2019 11:07 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| vicks_mq wrote: |
| Can I just edit the expiry value in notepad after downloading the messages from Queue using Qload, wouldn't that corrupt the messages ? I was under the impression that you are not supposed to change anything in Qload message if you want to put it back in MQ Queue without any issue. |
Where did you get that impression?
If you unload them and edit them carefully so that neither the format nor the content is invalid, why wouldn't that work? How will QLOAD know there's been editing? There's no checksum in play.
Try it in Dev. If it doesn't work / doesn't meet your needs / offends the Great Pumpkin then how much worse off will you be?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Apr 08, 2019 11:12 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
And of course, if you don't mind a little effort, you can easily write a small utility that reads the messages off the queue, maintains the context (msg id et al) and puts them back on the queue with an expiry value calculated as you choose.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Apr 08, 2019 11:22 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
In addition, of course, to the RFE you mentioned.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| vicks_mq |
| Posted: Mon Apr 08, 2019 11:31 am Post subject: |
|
|
Disciple
Joined: 03 Oct 2017
Posts: 162
|
| Vitor wrote: |
| And of course, if you don't mind a little effort, you can easily write a small utility that reads the messages off the queue, maintains the context (msg id et al) and puts them back on the queue with an expiry value calculated as you choose. |
Right on it.. |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Apr 08, 2019 11:45 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| vicks_mq wrote: |
| Vitor wrote: |
| And of course, if you don't mind a little effort, you can easily write a small utility that reads the messages off the queue, maintains the context (msg id et al) and puts them back on the queue with an expiry value calculated as you choose. |
Right on it.. |
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
|
|
