| Author |
Message
|
| EddieA |
 Posted: Mon Jun 06, 2005 11:32 am Post subject: |
 |
|
Jedi
Joined: 28 Jun 2001
Posts: 2453
Location: Los Angeles
|
| jefflowrey wrote: |
| If the application is explicitly setting Persistance to Non-Persistant, there is nothing you can do to correct this. |
Cheers,
_________________
Eddie Atherton
IBM Certified Solution Developer - WebSphere Message Broker V6.1
IBM Certified Solution Developer - WebSphere Message Broker V7.0 |
|
| Back to top |
|
 |
| voyager |
| Posted: Mon Jun 06, 2005 11:36 am Post subject: |
|
|
Centurion
Joined: 28 Dec 2004
Posts: 127
|
Sorry! folks!
I browsed on the production server instead of the development server where
the remote Queus on AS/400 are set as PERSISTENT.
Seems like the messages in WMQ are also showing 'PERSISTENT' after setting the Remote Queues on AS/400 'PERSISTENT'.
Thank you very much for your suggestions!
_________________
voyager |
|
| Back to top |
|
|
| voyager |
| Posted: Wed Jun 08, 2005 9:57 am Post subject: |
|
|
Centurion
Joined: 28 Dec 2004
Posts: 127
|
All,
Sorry! for the confusion. I was looking at the production server where as the development server
has these changes made. I posted about this before and I was wondering that I could not see my reply here.
Anyway, thank you very much for your valuable time and comments in helping me!
Voyager
_________________
voyager |
|
| Back to top |
|
|
| LuisFer |
| Posted: Wed Jun 08, 2005 10:19 am Post subject: |
|
|
Partisan
Joined: 17 Aug 2002
Posts: 302
|
| You can change the MD persistence with a Channel Message Exit |
|
| Back to top |
|
|
| Mr Butcher |
| Posted: Wed Jun 08, 2005 10:28 pm Post subject: |
|
|
Padawan
Joined: 23 May 2005
Posts: 1716
|
what will happen in this case if the channel has npmspeed(fast)? will the sender wait for an ack because it send persistent, and will the receiver not send an ack because it received non persistent because you changed the persistence in the exit?
_________________
Regards, Butcher |
|
| Back to top |
|
|
| bower5932 |
| Posted: Thu Jun 09, 2005 2:01 am Post subject: |
|
|
Jedi Knight
Joined: 27 Aug 2001
Posts: 3023
Location: Dallas, TX, USA
|
| I don't know what will happen. However, if the message should really be persistent, you should take care of it at the source. If something were to happen before the channel exit 'fixed' it, you could end up 'losing' your message. |
|
| Back to top |
|
|
| Nigelg |
| Posted: Thu Jun 09, 2005 6:08 am Post subject: |
|
|
Grand Master
Joined: 02 Aug 2004
Posts: 1046
|
| If you change the persistence in the MD in the channel msg exit, that dos not change the persistence in the msg BEFORE it was passed to the exit, so the qmgr will already have noted its actual persistence, and opened a UoW when the msg was retrieved from the xmitq. The channel will also act as it would if the persistence was not changed, for the same reason. |
|
| Back to top |
|
|
| LuisFer |
| Posted: Thu Jun 09, 2005 12:03 pm Post subject: |
|
|
Partisan
Joined: 17 Aug 2002
Posts: 302
|
Ok, ok, while the msg is not teatred for the MCA this one is not persistent. I know it, but i can do "something" , no "nothing to do". 
Sorry, sorry, sorry.
My answer is for this:
I had an app. that required persistence, running in 2 z/OS Lpars, but the messages goes to another QMgr. The persistence have un cost in Cpu, Logging, performance. Persistence in origin(cost) , persistence in destiny(cost). Now if i make the persistence in destiny , saves the origin cost, and how much time takes a msg (4Kb) from QM1 to QM2??. In this case cents of second. Really the posibility (in this case) to lost a msg is next to 0.
Too, the aplication is not critical.
Newly sorry |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Jun 09, 2005 12:42 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20763
Location: LI,NY
|
Not a good design.
To get the right level of service and quality, the persistence of the message should never change once it hit MQ.
So you won't have to deal with scenarios like: I sent the message as non persistent and at reception I make it persistent but I cannot find the message....
Well was the qmgr it was on restarted before the message was made persistent ????
Murphy's law: If it ain't persistent and it should be you will lose messages at the most inconvenient time.
enjoy  |
|
| Back to top |
|
|
| LuisFer |
| Posted: Thu Jun 09, 2005 12:54 pm Post subject: |
|
|
Partisan
Joined: 17 Aug 2002
Posts: 302
|
You have reason. But in the case of destiny QMgr down, always can copy the Xmitq contents, changing the MD & reput.
Really the app. puts "AS_Q_DEF" in a QAlias, and we change the "default persistence" as necesary.
Is not a good solution but , was this one or buy a new z/Series. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Jun 09, 2005 1:10 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20763
Location: LI,NY
|
Why change as necessary. You can have the application specify the persistence. This will supersede the persistence specified in the Alias Queue....
If you cannot change the APP what is the problem in making all messages persistent ??
Enjoy  |
|
| Back to top |
|
|
| LuisFer |
| Posted: Fri Jun 10, 2005 12:10 am Post subject: |
|
|
Partisan
Joined: 17 Aug 2002
Posts: 302
|
Hi fjb_saper:
The cpu use over 100 Msgs/Sec with persistence. The QMgrMstr Address Space uses 10-15% Cpu.
Really is a app. logging from an IMS Tx under SyncPoint.
Regards. |
|
| Back to top |
|
|
| kevinf2349 |
| Posted: Fri Jun 10, 2005 6:47 am Post subject: |
|
|
Grand Master
Joined: 28 Feb 2003
Posts: 1311
Location: USA
|
LuisFer
In my opinion Persistency should be determined by the business needs of the application. If the business has determined that persitstency is appropriate for an application's messages then I believe it is totally wrong for administrators to change this during the lifecycle of a message.
If the application revisits its need for persistency (again based on business decisions) then the best place to change this is in the application code itself.
To place the burden of deciding and controlling persistency onto the administrators is, again in my opinion, totally wrong (but all too common).
I believe much of the 'confusion' over persistency comes because there are different mechanisms that can be used to set persistency (and all have their place). Persistency should be considered at application design time, but all too often the mindset is to cop out and say...development=non persistent, production=persistent.
Just my two cents worth  |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Fri Jun 10, 2005 8:00 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20763
Location: LI,NY
|
| LuisFer wrote: |
Hi fjb_saper:
The cpu use over 100 Msgs/Sec with persistence. The QMgrMstr Address Space uses 10-15% Cpu.
Really is a app. logging from an IMS Tx under SyncPoint.
Regards. |
This is not a persistency consideration but a business and infrastructure consideration. If your messages need to be persistent you will take the cpu and time hit. If you cannot maybe it's time to get a bigger box or another box to run in parallel ???
Enjoy |
|
| Back to top |
|
|
| Vijay Kumar P |
| Posted: Tue Jun 14, 2005 9:25 pm Post subject: Persistency |
|
|
Novice
Joined: 24 Jan 2005
Posts: 10
|
Hello,
Which platform and version of MQ Series are you using.
I have checked in Windows Platform with MQ Series 5.3
When the Queue is Not Persistent the messages are lost after reboot if the Messages in the queue are Non-Persistent else it stays in the queue even if the Queue property is Not persistent.
When the Queue is Persistent the messages are in the queue irrespective of the message's persistency.
Regards,
Vijay. |
|
| Back to top |
|
|
|
|
