| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| MQ / JMS / Remote GETS |
« View previous topic :: View next topic » |
| Author |
Message
|
| sick1 |
 Posted: Thu Oct 17, 2002 3:01 pm Post subject: MQ / JMS / Remote GETS |
 |
|
Newbie
Joined: 17 Oct 2002
Posts: 3
|
Hi All,
I'm new to MQ but not to JMS. I have been charged with evaluating a MQ/JMS based application and am having a little distress. I've been told that:
MQ Series does not support remote gets, i.e. you cannot recieve from a queue on a remote machine
and would like to know:
Is this true? As that's not the way it has been with other JMS providers that I've seen.
If true, why? I'd guess something about ensuring delivery but have no idea.
Is there a way around this? Can I use some applet level code that doesn't require a local queue for a get? Is this safe? Is there a better way around this?
Finally, any pointers to resources that would help me better understand this issue would be greatly appreciated, even in the form of some google terms that will work better than 'MQSeries remote get'.
Thanks in advance,
Mike Sick |
|
| Back to top |
|
 |
| mfeenstra |
| Posted: Thu Oct 17, 2002 6:42 pm Post subject: |
|
|
Novice
Joined: 03 Jul 2002
Posts: 12
|
If "remote gets" means the application is on a remote machine from the queue manager..
MQSeries does support remote gets with the JMS interface, provided you are:
1) Using the com.ibm.mqjms.jar
2) Using a valid TCF/QCF (Topic/Queue Connection Factory)
3) Using a valid T/Q (Topic/Queue)
The application does a "remote get" by using the QCF/TCF and a Q/T object retrieved from a JNDI namespace. You create the objects with the JMSAdmin tool provided with Websphere MQ 5.3 or the MA88 support pak for MQ 5.2 and below. WMQ 5.3 and MA88 also include the com.ibm.mqjms.jar.
_________________
Matt Feenstra
IBM Certified Specialist - MQSeries |
|
| Back to top |
|
|
| sick1 |
| Posted: Fri Oct 18, 2002 6:49 am Post subject: Does Transport Count? |
|
|
Newbie
Joined: 17 Oct 2002
Posts: 3
|
Hi Matt,
Thanks! and yes, that's what I mean by remote. You have your queue manager and queue on Machine A and you have your receiver(s) on Machine B doing gets from the queue on A.
Is your answer changed by the transport mode selected? The organization has a preference for transport(SERVER) over transport(CLIENT). If this remote gets require use of client vs server, what (if any) are the drawbacks and/or consequences?
Thanks much,
Mike Sick |
|
| Back to top |
|
|
| bower5932 |
| Posted: Fri Oct 18, 2002 8:43 am Post subject: |
|
|
Jedi Knight
Joined: 27 Aug 2001
Posts: 3023
Location: Dallas, TX, USA
|
When discussing MQSeries, I would say that it doesn't allow remote gets. You can only get messages from your local Qmgr. However, your application doesn't have to be on the same machine as the Qmgr. If it is, it is termed bindings mode. If you run your application on a different machine from your qmgr, then you are using client mode. In order to do do client mode, you would define your TCF/QCF to have a transport of CLIENT instead of a transport of BIND.
As far as drawbacks are concerned, the CLIENT transport requires that you have a synchronous network connection to the Qmgr. The BIND transport will connect in via interprocess communication. There are also some drawbacks regarding what the client can/can't do in the XA environment. I'd have to do some digging to get the specifics.
Hope this helps. |
|
| Back to top |
|
|
| sick1 |
| Posted: Fri Oct 18, 2002 9:53 am Post subject: I get it -- so how do you scale that? |
|
|
Newbie
Joined: 17 Oct 2002
Posts: 3
|
Hi,
Thanks again! I wanted to make sure I understand what you said and see if anyone had any ideas on helping with system design. Using local gets implies some issues that I haven't had to address using other JMS providers.
From what you said, I can do either of the following:
1) Run in transport(BIND) and run an instance of MQ and a Qmgr locally and do local gets.
2) Run in transport(CLIENT) and use a Qmgr on a remote machine to do remote gets. Running in client mode is probably a little slower and degrades transactionality (now that I have some more key words to consider I'm going to go do more reading).
------------------------------------------------------------------------
The issue with local gets concerns me for the following reasons and I was curious if you had any observations on system issues. The application that I'm starting work on is using MQ in a request response fashion, where our JMS code is doing the work to make the async processing feel like it's sync.
This has led to a setup that looks like the following:
Machine-A has Qmgr-A with Queue-Response
Machine-B has Qmgr-B with Queue-Request
A request comes into Machine-A and is put to the remote Request queue on Machine-B via a JMS client. Server JMS code on Machine-B does a local get from the Request queue, processes it and does a remote put onto the Response queue on Machine-A.
So FINALLY, the questions! If we use the local-get/transport(BIND) mechanism:
1) It appears that we MUST have an MQ instance running on both client and server to achieve this type of request/response functionality. Is taht so? Is there a better way to set this up?
2) If the Qmgr on Machine-A is down, there seems to be no way to get a message back to Machine-A and the application is effectivly down. Is there a way to get around this?
3) To add more server side processing, we have to add more machines like Machine-B and distribute requests to them. This is not much of a problem except that each machine will need to run MQ rather than just running the server code. Is this how you typically scale MQ?
I guess all of this is a little surprising to me as I've typically viewed the JMS provider as more of a cloud than MQ or at least this setup of MQ suggests. Just because you put a message in a queue on Machine B, there was NO suggestion that the processing was going to be done on Machine B and in fact this was viewed as undesirable Machine B was the MOM machine as was kept clean and isolated much like one keeps a database server. Server processing was done on 1-N machines that were doing remote gets from Machine B and the addition of a new message processor was 100% transparent to all clients. Additionally, responses were put back in the Queue on Machine B and clients did remote gets from it. That way the server processing code had NO knowledge of where the client was.
This all seemed good as there was very little admin of the MOM/JMS provider, service resorces could be added easily, and your MOM was better protected.
I guess my final question would be is there any way to get the above benefits using MQ and if not does anyone have any ideas references to setups that improve on what I described above.
Thanks, I think this gets the award for my longest post and I hope as I learn MQ I can be a little more to the point.
Thanks,
Mike |
|
| 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
|
|
|
|
