| Author |
Message
|
| sairam |
 Posted: Wed Apr 13, 2005 6:26 am Post subject: Channel Definitions |
 |
|
Centurion
Joined: 07 Mar 2005
Posts: 120
|
I have a question.
I have 3 QM's A, B and C[let they be Queue Managers here] on 3 separate boxes. There are 2 channels between A and B ; another 2 between A and C.
I have the XMITQ 'A' for channel going from B to A (the name of the XMITQ is the name of the remote queue manager is A). I have another XMITQ with same name 'A' for channel going from C to A (since this channel too goes to the Queue Manager A and I have to give the XMITQ name as the name of the remote queue manager). Would this pose any problems to my set up ??? The channels work well with few msgs but fail for large msgs and unable to isolate whether it is an app issue or MQ issue. The channels are running but apps put msgs, they fail.
I started a listener "runmqlsr -t tcp -p 1414 -m QMGR", but when i do a "ps -ef|grep runmqlsr", in the output it displays the Queue Manager name as "QM" only, any reason why this happens. I am sure i have started the listener with "QMGR". |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Wed Apr 13, 2005 6:57 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
How do you know they "fail"?
What does "fail" mean?
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| sairam |
| Posted: Wed Apr 13, 2005 7:10 am Post subject: |
|
|
Centurion
Joined: 07 Mar 2005
Posts: 120
|
| well there are no errors in the logs...and when the applications are brought up, the messages fail to transmit on some queues after passing the msgs for a while. The primary and secondary log files and sizes were increased on qm.ini for all QMGRs. |
|
| Back to top |
|
|
| JT |
| Posted: Wed Apr 13, 2005 7:14 am Post subject: |
|
|
Padawan
Joined: 27 Mar 2003
Posts: 1564
Location: Hartford, CT.
|
| Quote: |
| The channels work well with few msgs but fail for large msgs |
Large volume of messages or large size of message?. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Apr 13, 2005 7:19 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Again, what do you mean "fail to transmit"?
Stay in the transmit queue? Move to the dead letter queue on one side or another? Fail to appear in the destination queue?
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| sairam |
| Posted: Wed Apr 13, 2005 8:02 am Post subject: |
|
|
Centurion
Joined: 07 Mar 2005
Posts: 120
|
The messages are put at the sending end, they go for some time through the XMITQ on the sender and get to the Receiver local queue. But after a certain period of time, they keep piling up on the sender XMITQ and and up no where (do not reach the destination local queue).
The channels keep running , the messages do not end up in the Dead Letter Queues on the SDR or the RCVR. The messages are around 100kb size and sometimes the UNCOM atttribute is marked as 'YES' on the XMITQ of the sender when i do a "dis qs(XMITQ)" on the SDR. i guess the Batch Size is set to 50 and we have no transactions involved in this scenario, simple messages from one end to another end. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Apr 13, 2005 8:22 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
The sending application is not committing them.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| sairam |
| Posted: Wed Apr 13, 2005 11:04 am Post subject: |
|
|
Centurion
Joined: 07 Mar 2005
Posts: 120
|
There are no transactions involved but i guess you are talking about the syncpoint. Maybe the putting rate of msgs is far higher than what the XMITQ can handle? is there any limit to the XMITQ capability to hold msgs.
What could be done or altered to cope up with the put rate of msgs so that there is an immediate flow to the receiving end. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Apr 13, 2005 11:17 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Yes, I meant syncpoint.
If the sending app isn't committing the messages, then there's nothing you can do.
It is possible that the messages are in an uncommitted state because the MCA hasn't been able to put them.
Then there is some chance you can resolve this by adjusting the channel parameters.
But the MCA should be logging reasons for the messages not flowing on one end or another.
You can increase the speed of messages passing through the channel, in some respects, by decreasing the channel batch size.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| sairam |
| Posted: Wed Apr 13, 2005 12:14 pm Post subject: |
|
|
Centurion
Joined: 07 Mar 2005
Posts: 120
|
| Sounds good. Any other alterations to the channel that could process the messages without XMITQ being overloaded. Can we increase the NPMSPEED attribute? |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Apr 13, 2005 1:25 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
The speed of the channel has nothing to do with how fast the messages move.
If the messages are big, realize it takes some time to move them across the channel. What is happening on the RCVR side? Is the RCVR channel going into its message retry exit, because it can't put the messages? If yes, the RCVR will be in a PAUSED stateand the SNDR will still say RUNNING, as it waits for the RCVR to put another messages.
I don't think fiddling with the BATCH aparamters will have any effect on the XMITQ dropping. I doubt the channel is waiting a long time for the batch to commit.
"is there any limit to the XMITQ capability to hold msgs. "
Max Queue Depth, up to the amount of disk space on your server.
It is possible your app is putting the messages faster than the channel can move them. Not likely, but possible. Maybe your network is cheesy, and can't move the data fast enough from point a to point b.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| sairam |
| Posted: Wed Apr 13, 2005 2:12 pm Post subject: |
|
|
Centurion
Joined: 07 Mar 2005
Posts: 120
|
The RCVR is also in RUNNING state, i guess till the DISCINT comes and the channel stops.
The BATCHINT is set to '0', should i increase that ? i am going through the channel attributes section of manual and thinking of this.BATCHSZ is at 50.Maybe i can reduce that attribute value !!
Can the app be improved to slow down the rate of msgs puts??i guess our network too is cheesy as you say. i guess there are 100mgs /min around 10MB per min, which is huge...
Last edited by sairam on Wed Apr 13, 2005 2:21 pm; edited 1 time in total |
|
| Back to top |
|
|
| csmith28 |
| Posted: Wed Apr 13, 2005 2:16 pm Post subject: |
|
|
Grand Master
Joined: 15 Jul 2003
Posts: 1196
Location: Arizona
|
| sairam wrote: |
| BATCHSZ is at 50.Maybe i can reduce that attribute value !! |
No no, don't do that.
_________________
Yes, I am an agent of Satan but my duties are largely ceremonial. |
|
| Back to top |
|
|
| JT |
| Posted: Wed Apr 13, 2005 5:17 pm Post subject: |
|
|
Padawan
Joined: 27 Mar 2003
Posts: 1564
Location: Hartford, CT.
|
| Quote: |
| But after a certain period of time, they keep piling up on the sender XMITQ and and up no where (do not reach the destination local queue). |
Couldn't tell from your statements.........does the XMITQ eventually empty, given enough time? |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Apr 13, 2005 6:42 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
My guess is the app is running some kind of batch in syncpoint. Now if the xmitq does not have the max depth setting to handle the batch you're in trouble whichever way you look. No message will be moved through the channel as long as its not committed but it will show up in the queue depth.
Enjoy  |
|
| Back to top |
|
|
|
|
