| Author |
Message
|
| kirani |
 Posted: Thu Dec 09, 2004 4:47 pm Post subject: MQ Event Messages |
 |
|
Jedi Knight
Joined: 05 Sep 2001
Posts: 3779
Location: Torrance, CA, USA
|
Is there any setting that can be changed to generate Persistent Event Messages by the queue manager?
_________________
Kiran
IBM Cert. Solution Designer & System Administrator - WBIMB V5
IBM Cert. Solutions Expert - WMQI
IBM Cert. Specialist - WMQI, MQSeries
IBM Cert. Developer - MQSeries
|
|
| Back to top |
|
 |
| EddieA |
| Posted: Thu Dec 09, 2004 5:16 pm Post subject: |
|
|
Jedi
Joined: 28 Jun 2001
Posts: 2453
Location: Los Angeles
|
Change the Queue attribute to be Persistent.
Cheers,
_________________
Eddie Atherton
IBM Certified Solution Developer - WebSphere Message Broker V6.1
IBM Certified Solution Developer - WebSphere Message Broker V7.0 |
|
| Back to top |
|
|
| kirani |
| Posted: Thu Dec 09, 2004 5:47 pm Post subject: |
|
|
Jedi Knight
Joined: 05 Sep 2001
Posts: 3779
Location: Torrance, CA, USA
|
That will work fine for local queues but I am planning on diverting Event messages from different queue managers to a central location. I still have small risk of loosing the message if there is any problems with the Channels.
_________________
Kiran
IBM Cert. Solution Designer & System Administrator - WBIMB V5
IBM Cert. Solutions Expert - WMQI
IBM Cert. Specialist - WMQI, MQSeries
IBM Cert. Developer - MQSeries
|
|
| Back to top |
|
|
| WannaBeInAParker |
| Posted: Thu Dec 09, 2004 7:00 pm Post subject: |
|
|
Voyager
Joined: 09 Dec 2003
Posts: 81
|
Never tried it, but possibly make the event queues remote queues specifying persistence yes. The remote queues simply point at your centralized queue manager.
Food for thought.
_________________
-WannaBe- |
|
| Back to top |
|
|
| csmith28 |
| Posted: Thu Dec 09, 2004 9:30 pm Post subject: |
|
|
Grand Master
Joined: 15 Jul 2003
Posts: 1196
Location: Arizona
|
or, modify your EVENT QLocals to DEFPSIST(YES) and set them up to TRIGGER sending the messages to a QRemote and make sure all the QRemotes, XMITQ's and Channels involved are DEFPSIST(YES).
_________________
Yes, I am an agent of Satan but my duties are largely ceremonial. |
|
| Back to top |
|
|
| EddieA |
| Posted: Thu Dec 09, 2004 10:46 pm Post subject: |
|
|
Jedi
Joined: 28 Jun 2001
Posts: 2453
Location: Los Angeles
|
| Quote: |
| make sure all the QRemotes, XMITQ's and Channels involved are DEFPSIST(YES) |
That won't have any effect. Once the message has been PUT, persistence is then an attribute of the message. No matter what the definition of any subsequent queues are, the mesage will still be persistent.
Take a look at the settings for the SYSTEM.CLUSTER.TRANSMIT.QUEUE. That's defined as non-persistent, but you can still send persistent messages without them becoming non-persistent.
It's as I stated at the outset. Change the Queue attribute, where the Event is written, to persistent.
Cheers,
_________________
Eddie Atherton
IBM Certified Solution Developer - WebSphere Message Broker V6.1
IBM Certified Solution Developer - WebSphere Message Broker V7.0 |
|
| Back to top |
|
|
| csmith28 |
| Posted: Sun Dec 12, 2004 5:24 pm Post subject: |
|
|
Grand Master
Joined: 15 Jul 2003
Posts: 1196
Location: Arizona
|
Indeed, so set DEFPSIST(YES) on the *.EVENT Queues. Then Set up Triggering to send the messages to the destination of your choice. Set DEFPSIST(YES) on the rest of the objects if it makes you feel better but apparently this is not needed.
I do not reccomend re-defining your *.EVENT Queue's to Queue Remotes.
_________________
Yes, I am an agent of Satan but my duties are largely ceremonial. |
|
| Back to top |
|
|
| EddieA |
| Posted: Sun Dec 12, 2004 6:47 pm Post subject: |
|
|
Jedi
Joined: 28 Jun 2001
Posts: 2453
Location: Los Angeles
|
| Quote: |
| I do not reccomend re-defining your *.EVENT Queue's to Queue Remotes. |
Just curious. Why.  It's just the same as any application writing to a Remote Q.
Cheers,
_________________
Eddie Atherton
IBM Certified Solution Developer - WebSphere Message Broker V6.1
IBM Certified Solution Developer - WebSphere Message Broker V7.0 |
|
| Back to top |
|
|
| csmith28 |
| Posted: Sun Dec 12, 2004 7:44 pm Post subject: |
|
|
Grand Master
Joined: 15 Jul 2003
Posts: 1196
Location: Arizona
|
| EddieA wrote: |
| Quote: |
| I do not reccomend re-defining your *.EVENT Queue's to Queue Remotes. |
Just curious. Why. It's just the same as any application writing to a Remote Q.
Cheers, |
No Eddie, it's not "the same as any application writing to a Remote Q" Applications should never put messages on the SYSTEM.*.EVENT Queues just like it is un-wise to allow applications use the SYSTEM.DEF.SVRCONN Channel.
Among other reasons, if one were to re-define all their *.EVENT Queue's as QRemotes and the local MQManager were to attempt to put an EVENT Message to that object when the Remote MQManager was not available the message would have to go to the local SYSTEM.DEAD.LETTER.QUEUE or the defined DLQ.
Then if kirani wanted to recover those messages he would have browse the messages locally or use runmqdlq to RETRY the messages instead of relying on the Trigger values that I suggested.
I have always been left with the impression that IBM prefers that one not modify System default objects. EVER!
With this impression I can only assume that IBM would prefer that altering the attributes of *.EVENT Qlocal Objects so they are Triggered would be preferable as apposed to deleting all the *.EVENT Qlocals and re-defining them as QRemotes.
Call me silly...
_________________
Yes, I am an agent of Satan but my duties are largely ceremonial. |
|
| Back to top |
|
|
| EddieA |
| Posted: Sun Dec 12, 2004 9:32 pm Post subject: |
|
|
Jedi
Joined: 28 Jun 2001
Posts: 2453
Location: Los Angeles
|
| Quote: |
| Applications should never put messages on the SYSTEM.*.EVENT Queues |
Naw, that's not what I meant. I was suggesting that there's no difference between an application putting to a Remote queue and the Event Processing in the Queue Manager (Hey, that's just another "application") putting to a Remote Queue. Actually, it's not. the "Event Processor" is smarter than that. If it can't write to the queue, it doesn't "barf". It just silently ignores the error.
| Quote: |
| if one were to re-define all their *.EVENT Queue's as QRemotes and the local MQManager were to attempt to put an EVENT Message to that object when the Remote MQManager was not available the message would have to go to the local SYSTEM.DEAD.LETTER.QUEUE |
Go read the Intercommunications manual.  The message would sit on the XMITQ waiting for the Remote QM to come avaialable. Just like any other message.
There's no difference between Event messages and any other data message that an application produces or consumes. They're just data that MQ moves from point A to point B.
Cheers,
_________________
Eddie Atherton
IBM Certified Solution Developer - WebSphere Message Broker V6.1
IBM Certified Solution Developer - WebSphere Message Broker V7.0 |
|
| Back to top |
|
|
| EddieA |
| Posted: Sun Dec 12, 2004 9:37 pm Post subject: |
|
|
Jedi
Joined: 28 Jun 2001
Posts: 2453
Location: Los Angeles
|
| Quote: |
| as apposed to deleting all the *.EVENT Qlocals and re-defining them as QRemotes |
From the Event Monitoring manual:
| Quote: |
| You can define event queues either as local queues, alias queues, or as local definitions of remote queues. If you define all your event queues as local definitions of the same remote queue on one queue manager, you can centralize your monitoring activities. |
Cheers,
_________________
Eddie Atherton
IBM Certified Solution Developer - WebSphere Message Broker V6.1
IBM Certified Solution Developer - WebSphere Message Broker V7.0 |
|
| Back to top |
|
|
| kirani |
| Posted: Sun Dec 12, 2004 10:12 pm Post subject: |
|
|
Jedi Knight
Joined: 05 Sep 2001
Posts: 3779
Location: Torrance, CA, USA
|
Thanks Guys!
I think defining DEFPSIST(YES) on remote queue should solve my problem.
_________________
Kiran
IBM Cert. Solution Designer & System Administrator - WBIMB V5
IBM Cert. Solutions Expert - WMQI
IBM Cert. Specialist - WMQI, MQSeries
IBM Cert. Developer - MQSeries
|
|
| Back to top |
|
|
|
|
