| Author |
Message
|
| RudeJude |
 Posted: Thu Oct 24, 2002 11:21 am Post subject: MQseries Q Persistence |
 |
|
Novice
Joined: 27 Jun 2002
Posts: 23
Location: Virginia
|
Our MQseries admins our looking at turning off default persistence for all Queues going forward and letting the programmer decide whether he wants to set persistence or not. My question is since with worklfow the application controls the puts to the UPES queues does that mean persistence will not be set from workflow? or is there a way to config workflow to tell it to put the UPES mesg on the Q and set the persistence.
Thanks
Rude |
|
| Back to top |
|
 |
| vedbhat |
| Posted: Thu Oct 24, 2002 5:05 pm Post subject: |
|
|
Disciple
Joined: 19 Mar 2002
Posts: 186
Location: Singapore
|
Hi,
When you install MQWF, by default some of the queues on the MQWF Queue Manager have Default Property value set to Persistent and some Non-Persistent.
Regarding UPES Queue, Generally the messages are put into a queue which needs to be created. So I guess your MQSeries Administrator when create the Queues, can set this property to Persistent/Non-Persistent.
Note: If there are messages in the Queue and your Queue Manager for some reason goes down then all the messages will be lost in case of Non-Persistent.
Regards
Ved
_________________
IBM Certified Solutions Expert - MQSeries Workflow
IBM Certified Specialist - MQSeries |
|
| Back to top |
|
|
| jmac |
| Posted: Fri Oct 25, 2002 4:49 am Post subject: |
|
|
Jedi Knight
Joined: 27 Jun 2001
Posts: 3081
Location: EmeriCon, LLC
|
I always make my UPES queues persistent to ensure delivery of the messages. MQWF does not define these queues, the developer does.
I would not change the persistence of any MQWF queue, note that some are persistent and some non-persistent.
_________________
John McDonald
RETIRED |
|
| Back to top |
|
|
| RudeJude |
| Posted: Fri Oct 25, 2002 5:50 pm Post subject: re: persistence |
|
|
Novice
Joined: 27 Jun 2002
Posts: 23
Location: Virginia
|
Funny enough I ran a couple of tests with my UPES Q's and if you turn off default persistence on the UPES Q's workflow submits the mesg regardless of default settings with the persistence option set for the message submit. So I guess if my mqadmin turns off persistence for performance reasons workflow will set it anyways. I guess its one of those undocumented features!  Thanks for the replies.
Rude |
|
| Back to top |
|
|
| jmac |
| Posted: Sat Oct 26, 2002 5:05 am Post subject: |
|
|
Jedi Knight
Joined: 27 Jun 2001
Posts: 3081
Location: EmeriCon, LLC
|
Rude:
Not knowing much about MQSeries myself, Do you know if this is a possible option on the MQ Send? I.E. Can you set the persistence when you send the message?
Thanks
_________________
John McDonald
RETIRED |
|
| Back to top |
|
|
| RudeJude |
| Posted: Sat Oct 26, 2002 10:23 am Post subject: re: persistence |
|
|
Novice
Joined: 27 Jun 2002
Posts: 23
Location: Virginia
|
Yes there are numerous values that can be controlled by an application/programmmer via code. The MQadmin has the option to set
default persistence to yes or no. If they set it to no than its up to the application/person submitting the message whether they want a message to have persistence. Its possible to have persistent and non persistent mesgs on the same Q. |
|
| Back to top |
|
|
| RudeJude |
| Posted: Sat Oct 26, 2002 11:06 am Post subject: re: persistence |
|
|
Novice
Joined: 27 Jun 2002
Posts: 23
Location: Virginia
|
John,
Here is an example of setting persistence for a single put to a queue using JMS... This uses application specific symbolic naming ie. DeliveryMode.NON_PERSISTENT would not be portable if we wanted to use another jms provider... You might use something like JMSC.MQJMS_PER_PER. I have been using MQSeries for a few years now but only recently have I actually plunged in to the guts and seen the options available to a programmer. You can do quite a lot of neat little tricks if you put some thought in to how you want to do things.
com.ibm.mq.jms.MQQueue q1 = new com.ibm.mq.jms.MQQueue();
q1.setBaseQueueManagerName("HOST1.QM1");
q1.setBaseQueueName("Q1");
q1.setPersistence(DeliveryMode.NON_PERSISTENT);
q1.setPriority(5); |
|
| Back to top |
|
|
| vedbhat |
| Posted: Sun Oct 27, 2002 5:31 pm Post subject: |
|
|
Disciple
Joined: 19 Mar 2002
Posts: 186
Location: Singapore
|
Hi,
Persistence can be set either at Queue Level or Message Level.
If the Persistence is set at the Queue Level, then the administrator can toggle the Default Persistent property to Persistent or Non-Persistent.
If the Persistent is set at the Message level then it is already part of Message. In this case, the Persistent cannot be changed. I guess Workflow sets this field under MQMD to persistent.
Regards
Ved
_________________
IBM Certified Solutions Expert - MQSeries Workflow
IBM Certified Specialist - MQSeries |
|
| Back to top |
|
|
| john_sharp |
| Posted: Fri Mar 26, 2004 9:19 am Post subject: Is MQSW override on UPES queue persistency configurable? |
|
|
Newbie
Joined: 17 Mar 2004
Posts: 2
Location: Edinburgh, Scotland
|
As with initial post, I'd like UPES designer to decide persistency of UPES queues, according to what benefit is gained. But setting a default at queue level won't mean much if MQSW always overrides this at message level. As with Rude Jude post on Oct25 2002, I've found an example of a non-persistent default at queue level being overriden by MQSW when it sends UPES requests.
So the question I have is whether MQSW simply ALWAYS does this for UPES requests; or whether I just haven't spotted how this can be configured.
In this respect, there is not a lot in the WMQW 3.4 manuals, and not much explanation of what is there. Doing a search on “persistent” or “persistency” turned up several references relating to object handling in program APIs, but only one which looked potentially relevant to queue definitions.
Namely, the “Getting Started with Buildtime” manual, in “Chapter 7. FDL Definitions”, page 86 allows definition of something called OPERATION_MODE. The context of this is:
Topology -> System -> TopologySetting -> Operation -> OperationSetting -> OPERATION_MODE.
OPERATION_MODE can be set to ROBUST or OPTIMISTIC or PERSISTENT.
Unfortunately, since there is no explanation at all, I can't say confidently whether it even applies to a queue or not. (The word "robust" might suggest relevance to queue, but then "optimistic" is more suggestive of database / locking.)
Has anyone else been over this ground for queue persistency, or found out what OPERATION_MODE controls?
_________________
John S Sharp |
|
| Back to top |
|
|
| kevinf2349 |
| Posted: Fri Mar 26, 2004 10:53 am Post subject: |
|
|
Grand Master
Joined: 28 Feb 2003
Posts: 1311
Location: USA
|
John (Mc)
I am a little intrigued by your statement:
| Quote: |
| I would not change the persistence of any MQWF queue, note that some are persistent and some non-persistent. |
We were sent the following by a member of your company
| Quote: |
Persistence in the production environment is a given - We DO NOT want to lose messages especially the from the instantiation queue. For all other environments, it should be a decision made by the developers and Systems personnel. With every customer I have been with we have had persistence defined across all environments.
|
I tried to argue that persistence wasn't "a given" but was shot down.
Now I am confused.......which is it best to do leave them as defined at installation...or set them all to persistent in production?
 |
|
| Back to top |
|
|
| hos |
| Posted: Fri Mar 26, 2004 1:14 pm Post subject: |
|
|
Chevalier
Joined: 03 Feb 2002
Posts: 470
|
Hi,
I think that MQWF puts UPES messages always persistent to the queue.
Why? Because - opposed to the PEA - the UPES takes part of the MQWF server's transaction. MQWF guarantees, that no messages get lost. |
|
| Back to top |
|
|
| jmac |
| Posted: Fri Mar 26, 2004 4:24 pm Post subject: |
|
|
Jedi Knight
Joined: 27 Jun 2001
Posts: 3081
Location: EmeriCon, LLC
|
| kevinf2349 wrote: |
Now I am confused.......which is it best to do leave them as defined at installation...or set them all to persistent in production?
|
I can explain my statement further, but that's about it. What I meant was that when I look at a brand new MQWF system, using MQ Explorer, it shows some of the queues defined as Persistent and some as Non-perssistent. My statement refers to these queues, and I am simply saying that I assume that the developers knew best and set the persistence of these queues to the value that they wanted and I would never change them. When I define a UPES Queue I generally define it as Persistent.
Of course, I should tell you that my knowledge of MQ Series is very limited, so I could very well be incorrect.
_________________
John McDonald
RETIRED |
|
| Back to top |
|
|
| vennela |
| Posted: Mon Mar 29, 2004 10:39 am Post subject: |
|
|
Jedi Knight
Joined: 11 Aug 2002
Posts: 4055
Location: Hyderabad, India
|
From:
| Quote: |
I think that MQWF puts UPES messages always persistent to the queue.
Why? Because - opposed to the PEA - the UPES takes part of the MQWF server's transaction. MQWF guarantees, that no messages get lost. |
John:
| Quote: |
When I define a UPES Queue I generally define it as Persistent.
|
Shouldn't matter whether you define it as persistent or non persistent because if the message attribute is persistent, it would take precedence over what the queue attribute is.
So always the UPES messages are PERSISTENT. |
|
| Back to top |
|
|
| kevinf2349 |
| Posted: Tue Mar 30, 2004 12:33 pm Post subject: |
|
|
Grand Master
Joined: 28 Feb 2003
Posts: 1311
Location: USA
|
JMac.
That was my thinking too, but it was when I suggested the same thing that I got that reply that I posted from the SYSCOM person. I still don't see the problem with leaving the queues as they come 'out of the box' myself either so I was just trying to see if there was any definitive SYSCOM answer. I still think we got misled somewhat when we installed workflow.  |
|
| Back to top |
|
|
| sshaker |
| Posted: Tue Mar 30, 2004 12:39 pm Post subject: |
|
|
Disciple
Joined: 20 Sep 2002
Posts: 185
|
workflow decided what messages are important and need to be persistent and otherwise. for example, a reply message may not be important and workflow may decide (designed) to send the message with no persistency.. but users may override that with queue level persistency .. but not otherwise !
_________________
shaker |
|
| Back to top |
|
|
|
|
