| Author |
Message
|
| sa2327mq |
 Posted: Mon Aug 01, 2005 6:51 am Post subject: publish and subscribe |
 |
|
Novice
Joined: 05 Jun 2005
Posts: 17
|
Hello folks,
let's see if my question make sense since I am lost my self. We have an existing Q that is being used by a process right now . A message being put and get on that Q by a process. Our app team is asking to use this existing Q to for putting different messages or same messages which will be handled by different process. So basically , two processes will be accessing the same Q . Is this possible ? or is it better to create a new Q for the other process ? can we set up publish and subscribe and get the data as it is being sent to the existing queue ? |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Mon Aug 01, 2005 7:05 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Pub/Sub has nothing really to do with sharing a queue.
You can share a queue between different applications, but why would you want to? Creating a new queue is cheap and fast and easy, and then you always know which application is having problems if the queue has messages piling up.
Tell your app team to post their design ideas and requirements here, and we will help them understand a good way to implement them.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| sa2327mq |
| Posted: Mon Aug 01, 2005 7:48 am Post subject: |
|
|
Novice
Joined: 05 Jun 2005
Posts: 17
|
What is it called then, I am thinking of something where you can put one message and it goes multiple places… distribution list?
Creating a new queue is cheap, but making application code changes to do the same thing twice is a bit tedious….
It may be the best solution for the app to do twice the work, but just want to make sure we are most efficient. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Mon Aug 01, 2005 8:01 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Yes, you could change the putting application to write to a distribution list instead of a single queue. Then more than one queue will get a copy of the message from one put statement.
You could also change the putting application to publish messages, then it wouldn't have to be changed when other applications need to get messages from it - the other applications wuold simply subscribe to the topics they were interested in.
You could also change the getting application to read from a different queue, and then use the mirrorq sample exit to copy messages from the putting applications output queue to any number of getting applications input queues.
But this comes down to fundamental application design philosophy and methods. If the app team is trying to do this, they are struggling with both the philosophy and the methods, and they should look for help sooner rather than later. It is fairly easy to design yourself into a quagmire of maintenance and performance troubles.
And if you go down the mirrorq route, then more and more of the application's processing burden will be put on your administrative shoulders and more and more of the performance and maintenance failures as well.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| sa2327mq |
| Posted: Mon Aug 01, 2005 10:47 am Post subject: |
|
|
Novice
Joined: 05 Jun 2005
Posts: 17
|
| What are the steps to implement this: We could change the putting application to write to a distribution list instead of a single queue. Then more than one queue will get a copy of the message from one put statement. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Mon Aug 01, 2005 10:55 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Distribution lists are application level objects.
You will have to change the code to create a distribution list, and populate it with different queue names.
The method to do this is different for different languages, but should be clearly defined in the documentation for the API being used.
One good idea is to use a namelist (which is a system object) to store the names of the queues to be put into the distribution list. Then the application will open the namelist, read all the names in it, and put them into a new distribution list. Then the queues that are being distributed to are kept in MQSeries where anyone with appropriate priviledges for the namelist can manage the contents.
Or you could put these names in a property file or a database table or something.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| wschutz |
| Posted: Mon Aug 01, 2005 10:59 am Post subject: |
|
|
Jedi Knight
Joined: 02 Jun 2005
Posts: 3316
Location: IBM (retired)
|
I always thought it would be neat to write a set of classes that allows you to "open" a namelist and then "put" messages to it. Under the covers, it would do what Jeff suggests.
_________________
-wayne |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Mon Aug 01, 2005 11:15 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
I always thought it would be neat if Distribution Lists were system objects, not application objects...
So you could just open one and put messages to it, and under the covers MQ would do what I meant.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| sa2327mq |
| Posted: Mon Aug 01, 2005 11:58 am Post subject: |
|
|
Novice
Joined: 05 Jun 2005
Posts: 17
|
| thanks Jeff , I guess the only way to do this is to have the application changed . The only issue we have is we are using a third party API that will do nothing but put one message to one queue and get message from one queue. Not sure if it would be easy to modify it to make it handle what we need. |
|
| Back to top |
|
|
|
|
