| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| remote queue |
« View previous topic :: View next topic » |
| Author |
Message
|
| Chrislsh |
 Posted: Wed Mar 03, 2010 11:09 pm Post subject: remote queue |
 |
|
Newbie
Joined: 03 Mar 2010
Posts: 3
|
I have successfully installed MQ server and MQ client on 2 WinXp PCs.
Does each PC with MQ client runing should have unique pair (request/reply) of queue in MQ server? That means 10 PCs each with MQ client then have 10 pair of queue in MQ server.
What will happen if 10 programs running simultaneously on one PC with MQ client, 10 pair of queue or 1 pair for 10 programs?
Thanks in advance for all your helps.
Chris |
|
| Back to top |
|
 |
| Mr Butcher |
| Posted: Thu Mar 04, 2010 12:20 am Post subject: |
|
|
Padawan
Joined: 23 May 2005
Posts: 1716
|
that depends on your application design, security requirements and other stuff. both solutions may work, or may fail depending on how your application works and how the data is organized.
e.g. if you have only 1 queue accessed by 10 programs, you msut make sure that every program only picks it's own replies, and not the replies of others.
or - if these 10 programs represent 10 different customers, i would not allow them access to the same queue. using a different application may allow them to get messages that are destigned for other customers.
so it depends, and with that little information about your application it is not possible to give you a good advice.
_________________
Regards, Butcher |
|
| Back to top |
|
|
| Chrislsh |
| Posted: Thu Mar 04, 2010 12:38 am Post subject: |
|
|
Newbie
Joined: 03 Mar 2010
Posts: 3
|
Glad to receive your reply.
I found that once I use MQGET the data from q, data will be deleted. How can I check the data in q before I pick it up? Is there any command for checking? The alternative way I can think of is first use MQGET, then check the data. If data is not for my program, then use MQPUT to put it back to reply q. Am I correct?
Thanks again for all your helps.
Best regards,
Chris. |
|
| Back to top |
|
|
| Mr Butcher |
| Posted: Thu Mar 04, 2010 12:43 am Post subject: |
|
|
Padawan
Joined: 23 May 2005
Posts: 1716
|
No you are not correct. this is not the way MQ programs are designed in a request / reply scenario. And - to be honest - they are not designed like this in any other scenario 
From what you ask, and how you ask it your MQ knowledge seems to be very, very basic. So do some reading of the MQseries manuals first before starting to design applications without knowledge. Start with primer manuals, and system administration, and the programmers guide and programmers reference. intercommunication is a good one too. read them all to get a better understanding, then start to design your application and to post questions.
_________________
Regards, Butcher |
|
| Back to top |
|
|
| exerk |
| Posted: Thu Mar 04, 2010 12:51 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| Chrislsh wrote: |
| ...I found that once I use MQGET the data from q, data will be deleted... |
Working as advertised.
| Chrislsh wrote: |
| ...How can I check the data in q before I pick it up? Is there any command for checking?... |
You could have the applications browse the messages, identify theirs by content, then issue a GET - all within syncpoint of course so other applications can't do a destructive read - but it's not efficient.
| Chrislsh wrote: |
| ...The alternative way I can think of is first use MQGET, then check the data. If data is not for my program, then use MQPUT to put it back to reply q. Am I correct?... |
No, and it's about as efficient as my previous tongue-in-cheek statement.
Do as Mr Butcher suggests and allocate a queue per application, or if the messages are truly message type request/reply, the applications will be retrieving only the message that meets correlid anyway, so an application should only get the reply messages that correlate to it, and a single queue could be used (note the emphasis).
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys.
Last edited by exerk on Fri Mar 05, 2010 12:53 am; edited 2 times in total |
|
| Back to top |
|
|
| mvic |
| Posted: Thu Mar 04, 2010 3:42 am Post subject: |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| Chrislsh wrote: |
| How can I check the data in q before I pick it up? Is there any command for checking? The alternative way I can think of is first use MQGET, then check the data. If data is not for my program, then use MQPUT to put it back to reply q. Am I correct? |
A phrase you will probably read / hear many times talking to MQ people about app design is "don't treat MQ like a database". Or a variation: "MQ is not a database".
If you analyse the data access technique you just described, it is very like a database lookup/retrieve, where your app knows what it is looking for in terms of data content, goes looking for it, and retrieves it (possibly also removing it).
MQ is *messaging* software. It moves things from Application A to Application B via queues and possibly channels. Yes it can store things awhile to cope with short-term putter/getter speed mismatches. But it is not as good as a database when it comes to storing large amounts of data for later retrieval. If you allow a queue to get very deep with messages, MQ does not provide quick access to the data based on the content of the message.
So, in short, an ideal MQ app should get from one queue, should always get the next message available, and not be fussy about the data content.
This then implies that you should NOT have multiple different apps with different input requirements all getting from the same queue.
It also implies your putter applications should only put messages on this queue which will be readable/understandable by the getter.
Hopefully it is possible to design your apps this way. You may of course have to make compromises with the "pure" approach I described, but remember all the time what MQ is actually doing for you in your system - it's a message transport not a database.
Hope this helps. |
|
| Back to top |
|
|
| Chrislsh |
| Posted: Thu Mar 04, 2010 3:57 am Post subject: |
|
|
Newbie
Joined: 03 Mar 2010
Posts: 3
|
Thanks Butcher, ererk and mvic advise.
In fact, I just follow the installation plus intercom manual to setup my MQ environment. That's why I ask some silly questions like get, check then put it back.
At least, you let me know I should try one application one queue approach.
Thanks again for all your help.
Best regards,
Chris. |
|
| Back to top |
|
|
| zpat |
| Posted: Thu Mar 04, 2010 5:13 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
I once had 5000 MQ clients using the same two queues, one for requests and one for replies.
The request messages are unconditionally read by the server application (and indeed several of them can run at once on the same queues).
The reply messages are retreived by correlid, which the server app has copied from the request message msgid to the reply message correlid.
The requestor know it's own request msgid and so can select the response by correlid matching.
Replies should be set to expire after a time in case they are not retreived (the requestor has failed or timed out on the MQGET). |
|
| Back to top |
|
|
| gbaddeley |
| Posted: Thu Mar 04, 2010 5:13 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
This question was also posted on the MQ forum at developerWorks
https://www.ibm.com/developerworks/forums/thread.jspa?threadID=320800&tstart=0
and I replied thus:
| Quote: |
| Does each PC with MQ client runing should have unique pair (request/reply) of queue in MQ server? That means 10 PCs each with MQ client then have 10 pair of queue in MQ server. |
No, not necessarily. The most simple solution is for each app on a MQ client PC to open and put request messages into one common queue and get replies from one common queue.
A back-end consumer application would have the request queue open and will get messages from it, process them and put reply messages on the reply queue. Meanwhile, the MQ Client PC app would have opened the reply queue, and be waiting to get the reply message that is matched on a unique Correlation Id. The Correlation Id is the Message Id that was returned by MQ when the original request message was put.
Does that make sense? There are several variations of this design theme, depending on volume and message size.
_________________
Glenn |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Mar 04, 2010 8:22 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
Here's a more concrete example of the usual request-reply model: a payroll time-card application.
Employees at each site run the payroll time-card creation application (an MQ client app).
The application MQCONNects to the PAYROLL queue manager, MQOPENs the TIMECARDQUEUE for output, and MQPUTS a time-card message into the queue. Just before the MQPUT, the app creates (MQOPENs) a reply-to-queue, and places the reply-to-queue's name in the MQMD (MQ Message Descriptor. The MQMD is part of each message put and gotten from a queue. The client app then MQGETs with WAIT for the reply message from the server application that does the time-card processing.
One (or more) time-card processing applications (server apps) have been started (by automation or triggering). The time-card processing application MQCONNects to the PAYROLL queue manager, MQOPENs the TIMECARDQUEUE for input, and gets a time-card.
The app does the payroll processing (calculate hours * hourly-rate, etc.), prints a pay-check, and MQPUTs a reply message (acknowledging the transaction or invalidating the transaction, whatever is appropriate) to the reply-to-queue named in the MQMD.
The client app has been waiting for the reply message. It MQGETs the reply message, and completes the interaction with the employee.
This is the request-reply model.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
