| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| ADOPTNEWMCA and TCP KEEPALIVE parameters |
« View previous topic :: View next topic » |
| Author |
Message
|
| TCV |
 Posted: Wed Nov 03, 2004 6:59 am Post subject: ADOPTNEWMCA and TCP KEEPALIVE parameters |
 |
|
Apprentice
Joined: 21 Aug 2003
Posts: 48
|
Hi ,
If any one have used ADOPTNEWMCA and TCP KEEPALIVE parameters in the QM.ini file to keep TCP alive, could you please post the exact lines from the .ini file here. I have used it in the file but doesnt work.
Thanks
TC |
|
| Back to top |
|
 |
| vmcgloin |
| Posted: Wed Nov 03, 2004 7:10 am Post subject: |
|
|
Knight
Joined: 04 Apr 2002
Posts: 560
Location: Scotland
|
TCP:
KeepAlive=YES
CHANNELS:
AdoptNewMCA=ALL ; Adopt all channel types, except fastpath
AdoptNewMCACheck=ALL ; Check qmgr name, ip address & channel name
It's fairly straight-forward. What problems are you having and what entries are you using? |
|
| Back to top |
|
|
| csmith28 |
| Posted: Wed Nov 03, 2004 7:17 pm Post subject: |
|
|
Grand Master
Joined: 15 Jul 2003
Posts: 1196
Location: Arizona
|
Hmm....
MQ5.3.0.6
AIX5.1.0.0
Occasionally I encounter an issue in which, for reasons * that are not apparent, one of my MQManager Servers that services roughly 20 remote 5.3.0.0 ** Client applications using mostly WebSpherer Application Server 4.0.0.6 Java and JMS to connect will drop off the network for a couple of minutes. 
When this happens the stdout.logs for these application begin to fill very rapidly with "2009 MQ Connection Broken" errors. Historically these application instances have to be bounced to restore service but my SDR/RCVR channels to remote MainFrame, AS/400 and Tandem MQManagers pick right up where they left of when the network connection is restored. Just as they should. 
What I am wondering is, if I set:
| Code: |
AdoptNewMCA=ALL
AdoptNewMCACheck=ALL |
in my qm.ini file will that allow these Client applications to reconnect to my MQManager without having to be bounced?  Could it be that easy?
KeepAlive is already set to YES.
*No .FDC files are generated, errpt -a | more shows no hardware failures regarding the NIC or software failure regarding inetd or TCP/IP. My /var/mqm/qmgrs/MQMGR/errors/AMQERR01.LOG only shows AMQ9999 channel ended abnormally for my SDR/RCVR Channels and gank load of TCP/IP Connection reset by peer entries. I got the Network Group to put a Sniffer on the MQ Server for about three weeks once. The problem re-occured once while the Sniffer was in place but buy the time we got some one from the Network group to join the Bridge, service had been restored and the Sniffer Buffer was already full of normal traffic having pushed out any information from the "Network Napp" that the server took.
** Yeah I know. I am working on upgrading the Clients to 5.3.0.6 right now. It's a whole nother story.
Oddly enough, historically this only seems to happen to the Production MQManager Server. It never happens in the DEV, IntTest or QA environments.
_________________
Yes, I am an agent of Satan but my duties are largely ceremonial. |
|
| Back to top |
|
|
| TCV |
| Posted: Thu Nov 18, 2004 12:26 pm Post subject: AdoptNewMCATimeout |
|
|
Apprentice
Joined: 21 Aug 2003
Posts: 48
|
| Is AdoptNewMCATimeout important to set?? How much time needs to be set if needed. |
|
| Back to top |
|
|
| csmith28 |
| Posted: Thu Nov 18, 2004 1:51 pm Post subject: |
|
|
Grand Master
Joined: 15 Jul 2003
Posts: 1196
Location: Arizona
|
yes it is for non SRVCONN channel types. Especailly if the network is somewhat unreliable or you habitually unplug your NIC cable to test connectivity.
_________________
Yes, I am an agent of Satan but my duties are largely ceremonial. |
|
| 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
|
|
|
|
