| Author |
Message
|
| tkaravind |
 Posted: Tue Nov 18, 2003 10:05 pm Post subject: Sender Channel retrying for large messages !!! |
 |
|
Acolyte
Joined: 24 Jul 2001
Posts: 61
|
Hi Everybody,
I am facing this problem with transmitting large messages (~ 1 MB) in our MQSeries network. The sender channel goes into RETRYing state and remains so whenever it encounters such messages thus halting transmission of subsequent (smaller) messages. (Receiver side is still running)
The solution we resort to is to manually remove this large message and restart the channel and get the smaller messages across. And then at the end we put this large message back to the Xmit queue and this time around it goes !!!
This has caused considerable confusion and delays in our production environment.
We strongly suspect that some temporary network glitch is causing this whenever a large message arrives and once this happens the sender channel abnormally terminates and retries connection to a receiver end already running which then rejects the connection.
Can anyone please advise me an automatic solution to this problem ?
By some alteration to the channel properties etc.
I checked the message length parameter on the Channel/Qmanager/Queue side. All carry the default of 4MB. So no problem there.
Many thanks in advance.
Aravind
IBM MQ Series / MQSI Support
Standard Chartered Bank
INDIA |
|
| Back to top |
|
 |
| xxx |
| Posted: Wed Nov 19, 2003 12:11 am Post subject: |
|
|
Centurion
Joined: 13 Oct 2003
Posts: 137
|
one solution is to create a new sender channel for the large messaes,
and new qr to route the large messages |
|
| Back to top |
|
|
| tkaravind |
| Posted: Wed Nov 19, 2003 12:34 am Post subject: |
|
|
Acolyte
Joined: 24 Jul 2001
Posts: 61
|
Hi,
Thanks. But I am afraid creating a new QMgr will involve a lot more changes to the client applications which are common and hence cannot be touched.
We are trying to look at fixing this issue at the MQSeries server side by tuning any parameter possible. |
|
| Back to top |
|
|
| xxx |
| Posted: Wed Nov 19, 2003 12:53 am Post subject: |
|
|
Centurion
Joined: 13 Oct 2003
Posts: 137
|
Not creating a new qmanger , I said to create a new channel, a qmanger can hold any number of channles
if you create a new channel , it will good to direct lagre messages
Or you can try segementation of the message ,
what r the qmanger logs indicating when the channel goes into retry state ? |
|
| Back to top |
|
|
| tkaravind |
| Posted: Wed Nov 19, 2003 2:04 am Post subject: |
|
|
Acolyte
Joined: 24 Jul 2001
Posts: 61
|
Hi,
The Sender Queue manager log indicates the "Channel ended abnormally".
It could be due to communications failure.
I guess a new channel also would face the same problem although it could get pave way for the other messages. |
|
| Back to top |
|
|
| Carla Viragh |
| Posted: Wed Nov 19, 2003 4:57 am Post subject: |
|
|
Voyager
Joined: 31 Oct 2003
Posts: 92
Location: São Paulo - Brasil
|
Sure, when channel is running and something happens, not the same time both ends of channels know that the connection was terminated. Sender tries to reconnect but the receiver rejects the new connection because it´s already running. You can configure the QM to force the new connection, to accept new connections!
The parameters:
AdoptNewMCACheck=ALL
AdoptNewMCATimeout=60
AdoptNewMCA=ALL
You don´t need to be afraid of if others untrusted channles will connect your QM, the receiver only will accept a new connection with the same name as the old sender. But, this is only safe is you check ALL to these options.
If you don´t know how to configure it, say the plataform, I will inform you.
_________________
Carla Viragh |
|
| Back to top |
|
|
| tkaravind |
| Posted: Wed Nov 19, 2003 9:17 pm Post subject: |
|
|
Acolyte
Joined: 24 Jul 2001
Posts: 61
|
Hi Carla,
Many thanks. We are using the Windows NT server and I have already made these changes to the parameters you mentioned on the receiver end. Only I will have to wait and see when it takes effect since (I presume) the Qmanager has to be restarted.
(Would it help if I gave a lesser value to the Timeout option say 1 sec so the new channel instance is created instantly)
Also, can you please advise me on the root cause of this problem.
I mean why should the channel terminate like this in the event of a large message. Is there anyway how we can avoid this ?
The reason I am asking it happens only in one network whereas we are using the same MQSeries parameters across other networks too and we never had problems there ! If I can touch upon the root cause I can possibly eliminate this altogether.
Thanks & Regards,
Aravind |
|
| Back to top |
|
|
| Carla Viragh |
| Posted: Thu Nov 20, 2003 5:04 am Post subject: |
|
|
Voyager
Joined: 31 Oct 2003
Posts: 92
Location: São Paulo - Brasil
|
Note, AdoptNewMCATimeout purpose is the time that the new process (channel instance, as you mentioned) will wait to old process to end, not the time new process will take to load, be careful, don´t set this value too small, if the old process don´t unload quickly, you may have problems. This is the greater value in seconds that the process will wait, but old process terminating, the new one assume instantly.
The other question is about your network, (performance):
Facing network performance problems, you can set Retry options on senders.
It´s dificult to know waht is going on, but I suggest a manual, it can help you to find a solution.
http://www-3.ibm.com/software/integration/support/supportpacs/individual/md0c.html
Good Luck! 
_________________
Carla Viragh |
|
| Back to top |
|
|
| tkaravind |
| Posted: Fri Nov 21, 2003 5:42 am Post subject: |
|
|
Acolyte
Joined: 24 Jul 2001
Posts: 61
|
Many Thanks Carla.
I tried downloading the manual.(This site speaks of "WebSphere MQ - Keeping Channels Up and Running")
It looks difficult from over here. Timed out twice !
Will definitely try to go thru it thorughly. What is happening currently is mysterious to us !!!
Rgds 
Aravind |
|
| Back to top |
|
|
| ping master |
| Posted: Sun Nov 23, 2003 7:12 pm Post subject: |
|
|
Centurion
Joined: 20 Sep 2002
Posts: 116
Location: USA
|
there is a simple solution to your problem..
the 'transaction' logs are set a the default size and cannot handle the msgs.
when creating your qmgr, specify larger sizes and more of the primary/secondary..
I was banging my head on this same exact problem, but it was fixed as soon I as did this. good luck |
|
| Back to top |
|
|
| tkaravind |
| Posted: Mon Nov 24, 2003 4:14 am Post subject: |
|
|
Acolyte
Joined: 24 Jul 2001
Posts: 61
|
Hi "ping master",
Yes. We explored on this System log possibility too (IBM documentation clearly states that RETRYing state happens mainly due to problems with resources) .
However we found it to be high enough on the receiving queue manager side. In fact we have the same logsize setting for other networks where we see much larger messages which go through smoothly.
Btw ... do the persisitent messages remain in the logs even after they are removed from the local queues OR are they cleaned up and space free for subsequent messages ??? I would presume the latter happens unless IBM thought otherwise for some reason 
Regards,
Aravind |
|
| Back to top |
|
|
| mrlinux |
| Posted: Mon Nov 24, 2003 5:41 am Post subject: |
|
|
Grand Master
Joined: 14 Feb 2002
Posts: 1261
Location: Detroit,MI USA
|
Well there is another possibilty, do you have DEAD Letter queue defined ??? If not maybe the receiving queue is not valid or unable to hold the big message .
_________________
Jeff
IBM Certified Developer MQSeries
IBM Certified Specialist MQSeries
IBM Certified Solutions Expert MQSeries |
|
| Back to top |
|
|
| Neysa |
| Posted: Wed Dec 03, 2003 2:55 am Post subject: |
|
|
Newbie
Joined: 28 Nov 2002
Posts: 7
Location: Netherlands
|
This is normal behaviour when the receiving queuemanager can't handle the message.
Make sure your recieving queue, queuemanager and deadletterqueue are all able to hold messages of that size. Also make sure your channel can handle them. |
|
| Back to top |
|
|
| ping master |
| Posted: Mon Dec 08, 2003 1:02 pm Post subject: |
|
|
Centurion
Joined: 20 Sep 2002
Posts: 116
Location: USA
|
exactly.
Our app was spilling everything over to DLQ & because they were persistent, it would not throw them away thus piling up and the QMGR was was getting the resource errora and our channel was stuck in retrying.
we then changed the default "transaction" log size (not error logs)
to:
crtmqm -c "My Queue Manager" -d DEFAULT.XMITQ -lc -lf 4095 -lp 4 -ls 3 -u SYSTEM.DEAD.LETTER.QUEUE -q -x 5000 %QMGR% 1>>%MQLOG% 2>>&1
it handled everything smoothly afterwards.. |
|
| Back to top |
|
|
| leongor |
| Posted: Tue Dec 09, 2003 12:56 am Post subject: |
|
|
Master
Joined: 13 May 2002
Posts: 264
Location: Israel
|
There is a parameter in sender/receiver channel : "Batch Size" that by default is 50.
When you have unreliable network it's recommended to set it to some lower value.
For example, if network failure occurs in 49's message a sender channel will rollback the whole batch ( 50 messages ) and will start again.
Also if you don't have message affinity you can use threading on sender channel ( maximum 2 threads ).
It can help when when you have one large message and a lot of small ones.
_________________
Regards.
Leonid.
IBM Certified MQSeries Specialist. |
|
| Back to top |
|
|
|
|
