| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| how to read "raw" msg and redirect |
« View previous topic :: View next topic » |
| Author |
Message
|
| bfzhou |
 Posted: Tue Mar 28, 2006 5:37 pm Post subject: how to read "raw" msg and redirect |
 |
|
Apprentice
Joined: 07 Aug 2003
Posts: 38
Location: Springfield, VA
|
I need to write a C program to redirect the whole msg, including whatever header, to a different queue without caring about the format, it could be written by a MQJava, JMS application, or just another C program as FORMAT_STRING.
Can anyone who has writen similar C program share some insight? Any idea would be greatly appreciated. |
|
| Back to top |
|
 |
| wschutz |
| Posted: Tue Mar 28, 2006 5:55 pm Post subject: |
|
|
Jedi Knight
Joined: 02 Jun 2005
Posts: 3316
Location: IBM (retired)
|
If you don't specify MQGMO_CONVERT when you get the message, then the format of the message isn't important. Issue an MQGET to get the message into a buffer and MQPUT the message to a new queue using the same buffer. If you want the MQMD to be EXACTLY the same, you need to open the output queue and put the message using the MQxx_SET_ALL_CONTEXT flags.
_________________
-wayne |
|
| Back to top |
|
|
| bfzhou |
| Posted: Tue Mar 28, 2006 6:11 pm Post subject: |
|
|
Apprentice
Joined: 07 Aug 2003
Posts: 38
Location: Springfield, VA
|
| thanks for the insight. will other headers also be maintained, inclluding RFH2? |
|
| Back to top |
|
|
| mvic |
| Posted: Tue Mar 28, 2006 11:32 pm Post subject: |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| bfzhou wrote: |
| thanks for the insight. will other headers also be maintained, inclluding RFH2? |
If MQGMO_CONVERT is absent from the Options when you get the message, then nothing after the MD will be touched. |
|
| Back to top |
|
|
| bfzhou |
| Posted: Wed Mar 29, 2006 9:12 am Post subject: |
|
|
Apprentice
Joined: 07 Aug 2003
Posts: 38
Location: Springfield, VA
|
You're right. I tested my round-robbin raw_msg_redirector with rfhutil.
it works great! |
|
| Back to top |
|
|
| kevinf2349 |
| Posted: Wed Mar 29, 2006 10:18 am Post subject: |
|
|
Grand Master
Joined: 28 Feb 2003
Posts: 1311
Location: USA
|
I have just one question ...why do you want to do it? I have been trying to think of why you would need to do this and I can't think of a reason. I am not saying that you don't have a good reason, just that I can't think of it.  |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Mar 29, 2006 10:37 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
The round-robin part I don't get. There are better ways to do it than manually. On the other hand, doing it manually has some benefits for visibility.
The "redirect" part could be a few different things. It could be a design pattern to provide a single input location for a subsystem, that then hides the internal details of the subsystem from the larger system. It could be a simple filter pattern or a more complicated router pattern. It could even be a one to many design pattern - like a distribution list.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| bfzhou |
| Posted: Wed Mar 29, 2006 6:06 pm Post subject: |
|
|
Apprentice
Joined: 07 Aug 2003
Posts: 38
Location: Springfield, VA
|
Jeff is right. Although the round-robin capability in a MQ cluster is generally better choice for load balancing, and to certain degree failover, applications have no control over how it is distributed, and I have to have one extra gateway qmgr.
I my case, I want to distribute the load to servers based on their currently deployed applications and overall saturation of CPU and memory, and it should adjustable at run-time. Here's the basic idea behind my design:
Suppose I have 4 servers, A,B,C,D, where four instances of the same application were deployed, each get a msg from the same-named queue on a qmgr with different names - QMA, QMB, QMC, and QMD.
QMA hosts the entry queue Q0, an arriving msg will trigger my raw_msg_redirector, to pick it up and redirect to four aliasQs that eventually point to the queue on A, B, C, and D server. it has a relatively long wait interval for get so it doesn't come down too often.
It uses round-robin to decide which queue to send the msg. I arrange the recipient queues in an array contained in the trigger msg in such a manner: A,A,A,B,B,B,B,C,C,D (just for easy reading, I would scramble them). This layout represents a distribution of
30% - 40% - 20% - 10% among the four servers.
I'm sure there is better way of doing this, but this design came to my mind first, and is very easy to implement in a tiny C program, and it is magnitude faster than a MQJava program. This is at a time when a major j2ee application couldn't nearly meet basic performance requirement and we have to spread the load to several servers in a way that doesn't saturate any single one of them.
Remember the equivalent Hopson Syndron? No matter how fast computers become, it resouce will be fully consumed by dirtier and dirtier, fatter and fatter code, frameworks, implementations. I can only dream the days when a complete DOS6 level OS version was implemented by a tiny Geek team in just 35k, in assembler. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Mar 29, 2006 6:46 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Implement MQ v6 and the need for a gateway qmgr goes away - the workload balancing can be changed away from localPreferred.
_________________
I am *not* the model of the modern major general. |
|
| 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
|
|
|
|
