| Author |
Message
|
| Tristan23 |
 Posted: Tue Jun 14, 2011 4:32 am Post subject: Sender / Receiver Channel |
 |
|
Newbie
Joined: 25 May 2011
Posts: 9
|
Hi there,
short question: What is the difference between a Sender and a Receiver Channel?
Regards,
Tristan |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Tue Jun 14, 2011 4:34 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Short answer - they have different names to reflect that they perform different tasks.
one sends.
one receives. |
|
| Back to top |
|
|
| Tristan23 |
| Posted: Tue Jun 14, 2011 5:37 am Post subject: |
|
|
Newbie
Joined: 25 May 2011
Posts: 9
|
I have a process that only sends - and another one that only ready.
Would it be advantageous give the Sender process a Sender Channel - and the reader process a Receiver Channel.
And if so - why? |
|
| Back to top |
|
|
| exerk |
| Posted: Tue Jun 14, 2011 5:41 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| Tristan23 wrote: |
I have a process that only sends - and another one that only ready.
Would it be advantageous give the Sender process a Sender Channel - and the reader process a Receiver Channel.
And if so - why? |
You seriously need to go and read the Intercommunication manual, and prior to that the WMQ Primer...
_________________
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. |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Jun 14, 2011 5:42 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Tristan23 wrote: |
| Would it be advantageous give the Sender process a Sender Channel - and the reader process a Receiver Channel. |
It would not because these channels are used by internal queue manager processes. Injecting any process of yours into one of these channels is going to cause distaster, in much the same way changing the oil in your car for screenwash will.
And actually asking this question demonstrates a dangerous lack of knowledge about WMQ. Review the Intercommunication manual for starters before going any further and blowing yourself up. WMQ is not a straightforward product and the changes to cause distaster accidentally are surprisingly high. Especially using objects in your applications because the name "seems relevant".
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Tristan23 |
| Posted: Tue Jun 14, 2011 6:05 am Post subject: |
|
|
Newbie
Joined: 25 May 2011
Posts: 9
|
Guys ... instead of being overly didactic - why not just give me some hints?
- several multithreaded sender processes
- one multithreaded reader process
- all written Java/JMS
- required throughput: 10.000 messages / second.
At the moment I get maybe 1/3 of that ... so the question is: where could I start to tune MQ? |
|
| Back to top |
|
|
| exerk |
| Posted: Tue Jun 14, 2011 6:20 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| Tristan23 wrote: |
Guys ... instead of being overly didactic - why not just give me some hints?
- several multithreaded sender processes
- one multithreaded reader process
- all written Java/JMS
- required throughput: 10.000 messages / second.
At the moment I get maybe 1/3 of that ... so the question is: where could I start to tune MQ? |
It's not a case of being overly didactic. You give a very clear impression of being not well versed in the operation and maintenance of WMQ (happy to be corrected and will be suitably apologetic if wrong), and giving advice on that basis may be more detrimental to your problem than good.
_________________
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. |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Jun 14, 2011 6:20 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Tristan23 wrote: |
| where could I start to tune MQ? |
You could start by demonstrating:
a) A knowledge of the product
b) What has led you to the conclusion it's WMQ that's the problem rather than (for instance) your application or the network.
In terms of hints, I gave you one common application howler that kills performance. Another poster's pointed you at documentation that will help.
There's no "performance change" - if there was the product would be delivered like that. There are a number of possible things you can do if it's the WMQ software that's the problem.
For instance - in another of your many posts you claimed sexy hardware. Is the queue manager equally sexy in it's configuration or straight out of the box?
(Didactic? Really?)
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
|
|
