| Author |
Message
|
| Esa |
 Posted: Mon Feb 14, 2011 6:40 am Post subject: Retained publication |
 |
|
Grand Master
Joined: 22 May 2008
Posts: 1387
Location: Finland
|
Is there a way to read a retained publication with an MQGet node? Or any other way to configure a flow to read one.
Please do not tell how to do it with JCN. I know it already. I am looking for an alternative. |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Mon Feb 14, 2011 10:04 am Post subject: Re: Retained publication |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| Esa wrote: |
Is there a way to read a retained publication with an MQGet node? Or any other way to configure a flow to read one.
Please do not tell how to do it with JCN. I know it already. I am looking for an alternative. |
Not with an MQGet node but it should be possible with a JMSInput node and set it to Topic... 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| Esa |
| Posted: Mon Feb 14, 2011 10:29 am Post subject: Re: Retained publication |
|
|
Grand Master
Joined: 22 May 2008
Posts: 1387
Location: Finland
|
| fjb_saper wrote: |
Not with an MQGet node but it should be possible with a JMSInput node and set it to Topic... |
I tried to check this before I posted my question. It does not seem to be so.
And, in my opinion, requesting a retained publication is not something you should do with any input node. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Mon Feb 14, 2011 10:44 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
At worst you should be able to construct an MQ PCF message that registers a new subscription to the queue read by the MQGET, and then send that to the command queue.
Assuming you're at MQ and Broker v7 and not using Broker pub/sub... ? |
|
| Back to top |
|
|
| Esa |
| Posted: Tue Feb 15, 2011 12:53 am Post subject: |
|
|
Grand Master
Joined: 22 May 2008
Posts: 1387
Location: Finland
|
| mqjeff wrote: |
At worst you should be able to construct an MQ PCF message that registers a new subscription to the queue read by the MQGET, and then send that to the command queue.
Assuming you're at MQ and Broker v7 and not using Broker pub/sub... ? |
That's not enough, I think. To make it work the way I want I would have to register a subsription with MQSO_PUBLICATIONS_ON_REQUEST. And if I do that, the messages cannot be read with MQGet.
I think Message Broker is clearly missing an MQSUBRQ node. That would be a simple, safe and standard way to access MQ-managed, persistent and highly available store of latest information.
That is what retained publications are ment for, if I have understood correctly. I could right away tell you several usefull ways to apply them in Message Broker.
Now that we have native publish/subscribe in MQ 7, why shouldn't we be able to take advantage of all it's features in Message Broker, too?
And don't try to give me that old "you should not try to use MQ as a database", it's so last version, don't you see... |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Feb 15, 2011 2:29 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
I agree that there isn't a sufficient level of support for MQ v7 pub/sub in shipping versions of Broker.
I'm not sure I understand your MQSO point, I'd thought that a retained publication always returned the last message on a new subscription?
So if you create a new subscription to the queue, using PCF to run a DEFINE SUB command, shouldn't it deliver the current publication to the queue? |
|
| Back to top |
|
|
| Esa |
| Posted: Tue Feb 15, 2011 2:36 am Post subject: |
|
|
Grand Master
Joined: 22 May 2008
Posts: 1387
Location: Finland
|
| mqjeff wrote: |
I'm not sure I understand your MQSO point, I'd thought that a retained publication always returned the last message on a new subscription?
|
No, Jeff. the idea of retained publications is that there can only be one retained publication per topic at a time. So if you publish a retained publication, it will replace the previous one.
Applications that request a retained publication with MQSUBRQ API call will always get the latest version. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Feb 15, 2011 3:13 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| Esa wrote: |
| mqjeff wrote: |
I'm not sure I understand your MQSO point, I'd thought that a retained publication always returned the last message on a new subscription?
|
No, Jeff. the idea of retained publications is that there can only be one retained publication per topic at a time. So if you publish a retained publication, it will replace the previous one.
Applications that request a retained publication with MQSUBRQ API call will always get the latest version. |
Yes, I know what a retained publication is. I'm not that far out of my depth.
I'm not suggesting you make a new publication.
I'm suggesting you make a new subscription object (a managed subscription, rather than an unmanaged subscription). Which should then get the latest publication, since it's a new subscription? |
|
| Back to top |
|
|
| Esa |
| Posted: Tue Feb 15, 2011 4:33 am Post subject: |
|
|
Grand Master
Joined: 22 May 2008
Posts: 1387
Location: Finland
|
| mqjeff wrote: |
I'm suggesting you make a new subscription object (a managed subscription, rather than an unmanaged subscription). Which should then get the latest publication, since it's a new subscription? |
I see what you mean. Besides that, you will have to delete the managed subsripction each time before you want to check the retained publication again. Seems to me like a lot of overhead.
An easier way to get nearly the same behavior is to write a message directly in a queue. Then in the flow read the queue empty with an MQGet node, use the information in the last message and write the message back into the queue. But you can never be 100 % sure that there will be a message in the queue.
I think I will test my JCN approach first, after all. I think there may be a way to make it work safely. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Feb 15, 2011 5:25 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Well, I didn't say it would be a BETTER solution than a JCN approach... just workable... 
You could modify your other message based idea by making sure you can identify the message you send to the queue. Mark it with an MQ Feedback flag or something. Then you will know if you got your same message back or if you're dealing with a data message. |
|
| Back to top |
|
|
| Esa |
| Posted: Tue Feb 15, 2011 5:36 am Post subject: |
|
|
Grand Master
Joined: 22 May 2008
Posts: 1387
Location: Finland
|
I'll make it work a way or another.
Let's see if the americans have something to add.
I will make a requirement to IBM about an MQSUBRQ node. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Feb 15, 2011 6:06 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| Esa wrote: |
| Let's see if the americans have something to add. |
I take that as a compliment.
Even though I *am* an American. |
|
| Back to top |
|
|
| Esa |
| Posted: Tue Feb 15, 2011 6:18 am Post subject: |
|
|
Grand Master
Joined: 22 May 2008
Posts: 1387
Location: Finland
|
Then you have been awake all night?
Well, I myself am just about to call it a day. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Feb 15, 2011 6:39 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| Esa wrote: |
Then you have been awake all night?
Well, I myself am just about to call it a day. |
Early to bed, early to rise... |
|
| Back to top |
|
|
| gerdd |
| Posted: Sun Mar 06, 2011 1:45 pm Post subject: MQ as database - not against it, but is a ret'd pub the way? |
|
|
Newbie
Joined: 04 Mar 2011
Posts: 8
|
| mqjeff wrote: |
| At worst you should be able to construct an MQ PCF message that registers a new subscription to the queue read by the MQGET, and then send that to the command queue. |
What's wrong with an RFH2 header? The book version of subscribing in MQ V6 technology. Subscribing the MQ V7 way is for later, it seems, in Broker.
But once you have registered a new subscription the retained pub message should be sent your way and you can get it via MQ Input or, if you insist, MQ Get.
| esa wrote: |
That's not enough, I think. To make it work the way I want I would have to register a subsription with MQSO_PUBLICATIONS_ON_REQUEST. And if I do that, the messages cannot be read with MQGet.
I think Message Broker is clearly missing an MQSUBRQ node. That would be a simple, safe and standard way to access MQ-managed, persistent and highly available store of latest information.
That is what retained publications are ment for, if I have understood correctly. I could right away tell you several usefull ways to apply them in Message Broker.
Now that we have native publish/subscribe in MQ 7, why shouldn't we be able to take advantage of all it's features in Message Broker, too?. |
Well, we don't have native MQ V7 pub/sub in Broker V7 yet, but I would expect that to be not too far away.
But I now see where you come from. "Highly available MQ managed persistent store of latest information." Okay ... well ... why not just put it into a queue and then allow all possible users to get this info in browse mode - that IS supported by MB V7. If you then want it available in very high performance mode you could look at how the "shared memory" sample in MB does it - if the shared ROW variable is empty your flow reads the messages and fills the ROW. Since you are only browsing the messages will be available even if the info is needed in more than one exe group. To update the info you have a flow that clears the old info from the queue, adds the new info in and then dispatches a small flow into each affected exe group to invalidate the row (or to put the new data in right away). Bingo . and no pub/sub, no retained publication, no subscribing. If you are interested in that info you just read the ROW variable at any point in time.
| esa wrote: |
| And don't try to give me that old "you should not try to use MQ as a database", it's so last version, don't you see... |
Agreed, it is, but I still have to say I've seen better indexing capabilities and better query syntax, especially if you need joins and the like, than MQ has to offer. But then, all my personal databases at home easily fit into memory nowadays and are thus more easily managed in my text editor. So, in many cases, who needs databases?  |
|
| Back to top |
|
|
|
|
