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 IndexGeneral IBM MQ SupportWait time question and delay in getting messages

Post new topicReply to topic Goto page Previous  1, 2, 3, 4, 5
Wait time question and delay in getting messages View previous topic :: View next topic
Author Message
ucbus1
PostPosted: Tue Oct 09, 2018 11:04 am Post subject: Reply with quote

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
View user's profile Send private message Send e-mail
Vitor
PostPosted: Tue Oct 09, 2018 11:12 am Post subject: Reply with quote

Grand High Poobah

Joined: 11 Nov 2005
Posts: 25365
Location: Ohio, 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
View user's profile Send private message
ucbus1
PostPosted: Tue Oct 09, 2018 11:23 am Post subject: Reply with quote

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
View user's profile Send private message Send e-mail
bruce2359
PostPosted: Tue Oct 09, 2018 11:26 am Post subject: Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 8219
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>
_________________
There are two types of people in this world:
1) Those that can extrapolate from incomplete data
Back to top
View user's profile Send private message
Vitor
PostPosted: Tue Oct 09, 2018 11:40 am Post subject: Reply with quote

Grand High Poobah

Joined: 11 Nov 2005
Posts: 25365
Location: Ohio, 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
View user's profile Send private message
ucbus1
PostPosted: Tue Oct 09, 2018 12:01 pm Post subject: Reply with quote

Knight

Joined: 30 Jan 2002
Posts: 560

Thanks you Bruce and vitor
https://www.ibm.com/developerworks/websphere/library/techarticles/0605_mcnamara/0605_mcnamara.html
Back to top
View user's profile Send private message Send e-mail
Vitor
PostPosted: Tue Oct 09, 2018 12:05 pm Post subject: Reply with quote

Grand High Poobah

Joined: 11 Nov 2005
Posts: 25365
Location: Ohio, USA

ucbus1 wrote:
Thanks you Bruce and vitor
https://www.ibm.com/developerworks/websphere/library/techarticles/0605_mcnamara/0605_mcnamara.html


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
View user's profile Send private message
Display posts from previous:
Post new topicReply to topic Goto page Previous  1, 2, 3, 4, 5 Page 5 of 5

MQSeries.net Forum IndexGeneral IBM MQ SupportWait time question and delay in getting messages
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.