It's me again.... Did not think it was DNS issue. Ran my tests using DNS hostname resolution and IP address. The results are the same. The trace just shows about a 3-4 minute gap in time following the connect request.
Next step... Running "netstat -an" shows the connection in a SYN_SENT state Since the VIP is not active nothing is ever going to be returned Reviewing some further information it looks like the default "TIME_OUT" condition on Solaris is 4 minutes -- I think I've run across that value before in my DCE days. I guess my options are... o Reduce the SYN_SENT wait time to something lower. But this is probably a bad thing since supporting this on a a number of client boxes may not be scalable to support. Additionally, the value that requires changing probably will affect every connection. o Find a way to do it within the client application. Does MQCONNX have anything? Or I could fork/thread a timer event around the MQCONN[X] call? Any input would be nice? Thanks, -B Brian Bumpass Wachovia Bank Enterprise Infrastructure [EMAIL PROTECTED] Phone - (704) 590-5620 Pager - (800) 425-2613 -----Original Message----- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Heggie, Peter Sent: Friday, March 19, 2004 1:00 PM To: [EMAIL PROTECTED] Subject: Re: MQ Client Connections Good idea.. sorry! Peter Heggie -----Original Message----- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Paul Clarke Sent: Friday, March 19, 2004 12:35 PM To: [EMAIL PROTECTED] Subject: Re: MQ Client Connections Peter, I agree but what I'm saying is let's not guess. First find out exactly what we're waiting for and then work out how to tune it down. There are quite a number of areas in the client code where we 'could' spend some time; I've even seen pretty innocuous registry calls taking minutes to return. Cheers, P. Paul G Clarke WebSphere MQ Development IBM Hursley |---------+----------------------------> | | "Heggie, Peter" | | | <[EMAIL PROTECTED]| | | NGRID.COM> | | | Sent by: MQSeries| | | List | | | <[EMAIL PROTECTED]| | | N.AC.AT> | | | | | | | | | 19/03/2004 17:05 | | | Please respond to| | | MQSeries List | |---------+----------------------------> >----------------------------------------------------------------------- --------------------------------------------------| | | | To: [EMAIL PROTECTED] | | cc: | | Subject: Re: MQ Client Connections | | | | | >----------------------------------------------------------------------- --------------------------------------------------| I have seen a network request take 4 minutes or a little longer to look for an name that is no longer there. Depends on your DNS setup. Peter Heggie -----Original Message----- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Paul Clarke Sent: Friday, March 19, 2004 11:53 AM To: [EMAIL PROTECTED] Subject: Re: MQ Client Connections Brian, I think the first thing to do is find out exactly what the client is waiting for for 4 minutes (who would have thought there was a valid sentence with 'for' being used 3 times consecutively ?). I suggest you switch on MQ trace and try the connect again. Look at the tracefile and look at the timestamps to make sure it's the connect() verb and not some strange ldap or authority call that's delaying you. Cheers, P. Paul G Clarke WebSphere MQ Development |---------+----------------------------> | | "Bumpass, Brian" | | | <[EMAIL PROTECTED]| | | CHOVIA.COM> | | | Sent by: MQSeries| | | List | | | <[EMAIL PROTECTED]| | | N.AC.AT> | | | | | | | | | 19/03/2004 16:37 | | | Please respond to| | | MQSeries List | |---------+----------------------------> >----------------------------------------------------------------------- --------------------------------------------------| | | | To: [EMAIL PROTECTED] | | cc: | | Subject: Re: MQ Client Connections | | | | | >----------------------------------------------------------------------- --------------------------------------------------| I know this is an old thread but have an interesting corollary scenario. My QMgrs are backed by HA software, thus a QMgr's IP address(es) and Listener process(es) are linked to VIP address(es). If the QMgr is down there is a good chance the VIP address is not attached to a NIC and unknown within the network -- and all the stuff that means.... My problem is at the client level rather than the SVRCONN definition on the QMgr. My initial testing is with round-robin DNS. I am getting a 2059 -- as expected -- when the QMgr is unavailable. However, it is taking about about 4 minutes for the MQ Client MQCONN call to fail. My guess is the network is attempting to locate the VIP address? The question is there a way to tune this failure at the client to happen quicker. Additional Note... The cacheing of the IP/Hostname is disabled on the client. Thanks in advance, -B Brian Bumpass Wachovia Bank Enterprise Infrastructure [EMAIL PROTECTED] Phone - (704) 590-5620 Pager - (800) 425-2613 -----Original Message----- From: Potkay, Peter M (PLC, IT) [mailto:[EMAIL PROTECTED] Sent: Friday, April 18, 2003 5:01 PM To: [EMAIL PROTECTED] Subject: Re: MQ Client Connections Once the KeepAlive interval passes, the QM should realize that there in nobody home on the other end of the SRVRCONN channel, and the orphaned instance should go away. Make sure KeepAlive is turned on to a reasonable value at the server level (it effects all TCP/IP apps, not just MQ), and then set the KeepAlive parameter to on at the QM level. And like Darren said, make sure the app always MQCLOSEs and MQDISCs (check all those try/catch blocks!) Transaction Vision is a cool tool that allows you to see what apps are really doing. Lots of times I was able to prove the app was doing XYZ when they swear they were doing ABC by using this tool. (Among other things, it list all the MQ API calls any app executes, and gives the details on exactly how and when it did what MQ-wise) -----Original Message----- From: Darren Douch [mailto:[EMAIL PROTECTED] Sent: Friday, April 18, 2003 1:37 PM To: [EMAIL PROTECTED] Subject: Re: MQ Client Connections Rich I may be corrected, but I don't think there is a way to get MQ to terminate the channels automatically from the server side. re: the problem app... it may do a nice MQDISC when it terminates cleanly... but what if it doesn't terminate cleanly - the designer / coder may have neglected proper cleanup in the 'bad' scenarios. Regards Darren. ----- Original Message ----- From: Garcia Rich (SYS1RXG) To: [EMAIL PROTECTED] Sent: Thursday, April 17, 2003 3:11 PM Subject: MQ Client Connections I am currently seeing an issue with MAX channels on one of my systems OS is not important, I understand that the fix for this would be add the MAXACTIVECHANNEL into the QM.ini stanza and increase the connections to something higher than the default of 100. I have spoken to the application which is connecting via a JVM Server, via the MQ client on the same system to ensure that they are performing a MQDISC and they of course say that ' they are '. Question: Is there a portion in the QM.ini stanza that will disconnect MQ Client connections after being idle for a certain length of time. If the application connecting refuses to make changes to their application I would like to perform the disconnects at the MQ Layer. I am seeing the following to give a better idea 1. Connection to HTTPSRV is made from the web. 2. HTTPSRV makes an internal client connection on the same machine to Loopback 127.0.0.1 and spawns a AMQCRSTA job. B. The application states that they perfom a MQ Close and DISC disconnect but I still see AMQCRSTA jobs in idle for more than 60 hrs. Any help woould be appreciated. Thank You Rich This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return email and delete this communication and destroy all copies. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive This e-mail and any files transmitted with it, are confidential to National Grid and are intended solely for the use of the individual or entity to whom they are addressed. If you have received this e-mail in error, please reply to this message and let the sender know. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive