| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| Wait time question and delay in getting messages |
« View previous topic :: View next topic » |
| Author |
Message
|
| ucbus1 |
 Posted: Tue Oct 09, 2018 11:04 am Post subject: |
 |
|
Knight
Joined: 30 Jan 2002
Posts: 560
|
| Vitor wrote: |
| ucbus1 wrote: |
I find the messages are put with persistence on.
...
The PUT application is putting the message correctly
|
If you're implying by "the application put the message correctly", it put the message as not persistent and it's ending up on the queue as persistent then this is false. Persistence is totally under the control of the application (unless you have an exit installed someplace which is highly unlikely) and the application has 3 options:
- persistent
- not persistent
- whatever, I don't care that much one way or the other
There will now follow a flame war where the 2 sides of the debate (application sets persistence v application takes default) fight it out but if the message is ending up on the queue as persistent then the application either specified it needed to be persistent or the application allowed the persistence to be whatever the default setting is on the queue and that default is persistent.
| ucbus1 wrote: |
| If I understand correctly persistence increases the processing time. |
Yes. Much more I/O activity. Don't forget persistent messages are always written to the queue file as well as the log file; non-persistent messages are only written to the queue file if the available buffer space fills.
| ucbus1 wrote: |
| But MQ is taking more time to write the message to logs due to persistence ( which could be killing us due to high I/O, hence the delay) and is not available for GET application till MQ is done writing the logs. |
The message won't be available to be read off until it's successfully arrived. Until it's been written safely to both locations. |
Thanks. The application is not setting the persistence. If I am correct, in case if the PUT application does not set persistence, then the persistence behavior is inherited from the queue definition. If the queue is defined as persist messages, then all messages put on the queue will take the behavior from the queue setting. Right? |
|
| Back to top |
|
 |
| Vitor |
| Posted: Tue Oct 09, 2018 11:12 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| ucbus1 wrote: |
| Thanks. The application is not setting the persistence. If I am correct |
You're not entirely correct. The application must set a persistence option, but that option can be "whatever's defined on the queue".
| ucbus1 wrote: |
| the persistence behavior is inherited from the queue definition. If the queue is defined as persist messages, then all messages put on the queue will take the behavior from the queue setting. Right? |
Right, but it's not inherited, the application makes a specific coding choice to take the queue default.
I may be splitting hairs here a little, but "inheritance" implies that the persistence option came from the queue because the application didn't specify anything. The application has to specifically code to use the queue's default; if it specifies no persistence option the PUT will fail.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| ucbus1 |
| Posted: Tue Oct 09, 2018 11:23 am Post subject: |
|
|
Knight
Joined: 30 Jan 2002
Posts: 560
|
| Vitor wrote: |
| ucbus1 wrote: |
| Thanks. The application is not setting the persistence. If I am correct |
You're not entirely correct. The application must set a persistence option, but that option can be "whatever's defined on the queue".
| ucbus1 wrote: |
| the persistence behavior is inherited from the queue definition. If the queue is defined as persist messages, then all messages put on the queue will take the behavior from the queue setting. Right? |
Right, but it's not inherited, the application makes a specific coding choice to take the queue default.
I may be splitting hairs here a little, but "inheritance" implies that the persistence option came from the queue because the application didn't specify anything. The application has to specifically code to use the queue's default; if it specifies no persistence option the PUT will fail. |
Thanks. Here is what I read.
| Quote: |
| There is no such thing as a persistent or non-persistent queue. A default persistence queue setting DEFPSIST is defined at the queue level, but persistence is set at the message level. The programs doing the MQPUT call set the message descriptor field Persistence to persistent or non-persistent, or use the default persistence setting of the queue. If the option is not specified, the default persistence setting for the queue is used. |
|
|
| Back to top |
|
|
| bruce2359 |
| Posted: Tue Oct 09, 2018 11:26 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
<rant>
The programmer sets the MQMD MQPER_ field to one of three values:
1. This message is to be persistent, or
2. This message is to be non-persistent, or
3. Message persistence will be taken from the persistence-as-q-def attribtue (not default) value of the queue. This does NOT override if the programmer has specified 1. or 2. above.
</rant>
_________________
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 |
|
|
| Vitor |
| Posted: Tue Oct 09, 2018 11:40 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| ucbus1 wrote: |
Thanks. Here is what I read.
| Code: |
| There is no such thing as a persistent or non-persistent queue. A default persistence queue setting DEFPSIST is defined at the queue level, but persistence is set at the message level. The programs doing the MQPUT call set the message descriptor field Persistence to persistent or non-persistent, or use the default persistence setting of the queue. [b]If the option is not specified, the default persistence setting for the queue is used[/b]. |
|
Ok, let's take that hair and shave it thin.
IF you're using a language like C or C++ and you choose to initialize the MQPMO structure with an IBM supplied language construct then it's possible that the MQPER value will be set to zero (persistence as queue default). If you roll your own code to set up the MQPMO that sets the structure to the language specific neutral value you could again set it to zero without specifically setting it.
I again refuse to call that "inheriting" the value. The application coder in the examples I've specified has simply taken "whatever, I don't care" up to "I can't even be bothered to think" and set whatever value came with the constructer they were using. If someone had modified the IBM supplied construct (and I know admins who do this) the option would come out as persistent or not persistent.
Persistence is the responsibility of the application. If the application abrogates that responsibility, that doesn't change the fact of the responsibility. It's the same as not releaseing memory in Java; if you don't bother because the garbage collection will automatically figure it out, it's still your responsibiity when the JVM runs out of memory because the gc interval is too high.
The only thing that affects this is an API exit. You should know if you have one of those as an MQ admin. I'd be more likely to believe you have a pet unicorn.
Nothing can change the persistence of a message once it's delivered to the queue.
Next time you post a quote, post the URL you sourced it from so future readers can judge the source.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| ucbus1 |
| Posted: Tue Oct 09, 2018 12:01 pm Post subject: |
|
|
Knight
Joined: 30 Jan 2002
Posts: 560
|
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Oct 09, 2018 12:05 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
Thank you in return for adding the link.
While not directly relevant to this topic, be wary of taking advice from 12 year old posts (the link you reference was published in May 2006). While setting persistence has not changed, many other things have. For example, advice on cluster topologies was very different back then due to updates in post-2006 versions of the software.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
|
|
|
|
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
|
|
|
|
