| Author |
Message
|
| yetanothersteve |
 Posted: Mon Sep 25, 2006 8:35 am Post subject: Moving message to 2nd queue using MQ Client without Get/Put |
 |
|
Newbie
Joined: 25 Sep 2006
Posts: 3
|
I was wondering if it was possible to move a message from one local queue to another on a queue manager using the MQClient from a machine other than the queue manager.
I am trying to avoid getting the message across the network and then putting it, again using the network, into a secondary queue.
Background:-
1. Client A puts a message on local queue QMain.
2. Client B gets message off QMain, determines the message belongs to Client C and puts the message on local queue QClientC
3. Client C gets message off QClientC and performs work accordingly
Client B is a fan out or routing program running MQ53CSD08 on Solaris 2.8. Considering java for the programming language to avoid recompiling C code when we move to Solaris 9 or 10. Client B, due to my firm's policy, is not allowed to run on the queue manager, nor is a trigger monitor or any program I write allowed to run on the queue manager.
In step 2., I want to avoid the network traffic in getting the message to Client B's server and putting it back on QClientC at the queue manager from Client B's server.
The messages will have an average size of 1.2mb with a maximum size of 20mb. The 20mb maximum will require about 1 second to transmit at our network average of 20mb/s. I have a 5 second service level agreement to meet and shaving off 2 seconds would help a lot.
From googling and reading through the MQ Application Programming Guide, there does not appear to be anything like an MQMOVE command. |
|
| Back to top |
|
 |
| tleichen |
| Posted: Mon Sep 25, 2006 9:25 am Post subject: Re: Moving message to 2nd queue using MQ Client without Get/ |
|
|
Yatiri
Joined: 11 Apr 2005
Posts: 663
Location: Center of the USA
|
| yetanothersteve wrote: |
| …I am trying to avoid getting the message across the network and then putting it, again using the network, into a secondary queue. |
Why? 
| yetanothersteve wrote: |
Background:-
1. Client A puts a message on local queue QMain.
2. Client B gets message off QMain, determines the message belongs to Client C and puts the message on local queue QClientC
3. Client C gets message off QClientC and performs work accordingly
Client B is a fan out or routing program running MQ53CSD08 on Solaris 2.8. Considering java for the programming language to avoid recompiling C code when we move to Solaris 9 or 10. Client B, due to my firm's policy, is not allowed to run on the queue manager, nor is a trigger monitor or any program I write allowed to run on the queue manager. |
If I get this straight, your company has made policies that keep the tool they purchased (MQ) from working the way it was designed to?!? 
| yetanothersteve wrote: |
| In step 2., I want to avoid the network traffic in getting the message to Client B's server and putting it back on QClientC at the queue manager from Client B's server. |
So…. From the MQ client, you want to orchestrate data flow to/from MQSeries queues without using MQSeries gets and puts?!? I think you would need a magic wand! 
_________________
IBM Certified MQSeries Specialist
IBM Certified MQSeries Developer |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Mon Sep 25, 2006 9:35 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
You should not use an MQ Client to move messages between two queue managers. You should use MQ networking - i.e. sender/receiver channels.
You can't do anything with a message without either GETing or PUTing it to a queue.
Your design is not unreasonable, in that you have what seems to be a normal routing program that sits between several applications. It is also not uncommon for businesses to decide to use only client connections. But if they are also unwilling to accept the performance impact of using client connections, then they are being unreasonable.
There's no way you can use an MQClient connection that will avoid streaming the full message data across the client channel in both directions.
Well. Okay. You could do funny thing with API Exits, or perhaps reference messages. But that's an extraordinary waste of time and resources.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| yetanothersteve |
| Posted: Mon Sep 25, 2006 10:31 am Post subject: |
|
|
Newbie
Joined: 25 Sep 2006
Posts: 3
|
Thank you for the quick response.
I did not think it was possible, but I wanted to check with some experts before I let everyone know there was a potential performance hit to using client based routing.
By keeping developer written programs off of their queue managers, the admins maintain their stellar uptime statistics.
If the performance does suffer due to the network traffic, this might just be the argument I was looking for to get a queue manager dedicated to this new application that would be allowed to host the routing or triggering program. I.e., if the queue manager belongs to my area and we are the only ones using it and it breaks, no damage to anybody else's queues availability. |
|
| Back to top |
|
|
| kevinf2349 |
| Posted: Mon Sep 25, 2006 1:21 pm Post subject: |
|
|
Grand Master
Joined: 28 Feb 2003
Posts: 1311
Location: USA
|
| Quote: |
| By keeping developer written programs off of their queue managers, the admins maintain their stellar uptime statistics. |
Yeah we could all do that for every system if we stopped people from actually doing useful work on it. 
btw....MQ has steller uptime even with developer written applications using the queue managers on the same box at our shop.  |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Mon Sep 25, 2006 2:13 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| kevinf2349 wrote: |
| MQ has steller uptime even with developer written applications using the queue managers on the same box at our shop. |
You've trained your developers not to tell Management that "MQ is broken!" everytime something goes wrong with their code?
I'm impressed.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| tleichen |
| Posted: Mon Sep 25, 2006 4:15 pm Post subject: |
|
|
Yatiri
Joined: 11 Apr 2005
Posts: 663
Location: Center of the USA
|
| jefflowrey wrote: |
| kevinf2349 wrote: |
| MQ has steller uptime even with developer written applications using the queue managers on the same box at our shop. |
You've trained your developers not to tell Management that "MQ is broken!" everytime something goes wrong with their code?
I'm impressed. |
Me too! It seems to me that the industry norm has become whenever there is a problem with an application, and it uses MQSeries, then the MQ support group is the first one that gets called, regardless of what the symptom is!
_________________
IBM Certified MQSeries Specialist
IBM Certified MQSeries Developer |
|
| Back to top |
|
|
| kevinf2349 |
| Posted: Tue Sep 26, 2006 4:44 am Post subject: |
|
|
Grand Master
Joined: 28 Feb 2003
Posts: 1311
Location: USA
|
| Quote: |
It seems to me that the industry norm has become whenever there is a problem with an application, and it uses MQSeries, then the MQ support group is the first one that gets called, regardless of what the symptom is!
|
Oh trust me it wasn't easy, but they eventually got message (if you pardon the pun) |
|
| Back to top |
|
|
| tleichen |
| Posted: Tue Sep 26, 2006 8:17 am Post subject: |
|
|
Yatiri
Joined: 11 Apr 2005
Posts: 663
Location: Center of the USA
|
| kevinf2349 wrote: |
| Oh trust me it wasn't easy, but they eventually got message (if you pardon the pun) |
Ohh, brother!....
_________________
IBM Certified MQSeries Specialist
IBM Certified MQSeries Developer |
|
| Back to top |
|
|
| HubertKleinmanns |
| Posted: Tue Sep 26, 2006 10:05 am Post subject: |
|
|
Shaman
Joined: 24 Feb 2004
Posts: 732
Location: Germany
|
| tleichen wrote: |
| jefflowrey wrote: |
| kevinf2349 wrote: |
| MQ has steller uptime even with developer written applications using the queue managers on the same box at our shop. |
You've trained your developers not to tell Management that "MQ is broken!" everytime something goes wrong with their code?
I'm impressed. |
Me too! It seems to me that the industry norm has become whenever there is a problem with an application, and it uses MQSeries, then the MQ support group is the first one that gets called, regardless of what the symptom is! |
That's life !
But back to the question. I would design a small program, which gets messages off QMain, determines the message belongs to client B or client C and puts the message on local queues QClientB or QClientC respectively. Client B gets messages off QClientB and client C gets messages off QClientC.
This program should run local on the QMgr with server bindings and so would not use any channel connections.
_________________
Regards
Hubert |
|
| Back to top |
|
|
|
|
