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
