Stuart
Correct me if I'm wrong. Your server application (whose connection is not
in question) is actively sitting on an MQGET waiting for work (as server
applications do). Your client application is going through the firewall
with a CLNTCONN/SVRCONN connection that is being broken. This client
application has already connected and has opened/created a reply queue, but
is doing no MQ work because it is waiting for an operator initiated
transaction. Correct?
It doesn't sound like a Heartbeat issue, has heartbeat cannot help your
idle CLNTCONN/SVRCONN connection for the reason Neil and Paul mention
(specifically that it will only help while your client application is in a
get with wait so that there is an active MQI call that can respond to the
heartbeat). Doesn't sound like a bug to me.
How do you fix this? I'm not sure. Maybe KeepAlive can help (I've never
fully understood Keepalive), maybe changes to your design. Certainly the
application should be prepared to deal with broken connections as Emile
suggests, but keeping it from breaking or maintaining the connection
through idle times may require additional tactics.
Rick
|---------+--------------------------------------->
| | Neil Casey |
| | <[EMAIL PROTECTED]> |
| | |
| | Sent by: MQSeries List |
| | <[EMAIL PROTECTED]> |
| | |
| | |
| | |
| | Wednesday September 10, 2003 01:11 |
| | AM |
| | Please respond to MQSeries List |
| | |
|---------+--------------------------------------->
>----------------------------------------------------------------------------------------------------|
|
|
| To: [EMAIL PROTECTED]
|
| cc:
|
| Subject: Re: Heartbeat, Keepalive and Client Connection Timeouts
|
>----------------------------------------------------------------------------------------------------|
It's a nice solution that only applies with Queue manager to Queue manager
channels. You can't do this sort of thing with a server connection channel,
because there is no queue manager at the other end (also no transmission
queue etc etc). It also shouldn't be necessary to do this to keep a
firewall open. Heartbeat should be able to achieve this.
Unfortunately, you look like you are having problems with Client
connections. I would have expected that you should be able to define the
HBINT on the Client connection channel and the server connection channel.
The manual says:
For channels with a channel type (CHLTYPE) of SVRCONN or
CLNTCONN, this is the time, in seconds, between heartbeat flows
passed from the server MCA when that MCA has issued an MQGET
with WAIT on behalf of a client application. This allows the
server to handle situations where the client connection fails
during an MQGET with WAIT. This type of heartbeat is valid only
for AIX, Compaq OpenVMS, HP-UX, Linux, OS/2 Warp, OS/400,
Solaris, and Windows.
So you only get heartbeats when your application is in a MQGET with wait
condition.
This is exactly what you describe for your application, so it is possible
that you are experiencing a bug (shock, horror), for which you would need
to go to IBM for support.
Regards,
Neil Casey.
|---------+---------------------------->
| | [EMAIL PROTECTED]|
| | .AU |
| | Sent by: MQSeries|
| | List |
| | <[EMAIL PROTECTED]|
| | n.AC.AT> |
| | |
| | |
| | 10/09/2003 13:24 |
| | Please respond to|
| | MQSeries List |
| | |
|---------+---------------------------->
>
--------------------------------------------------------------------------------------------------------------|
|
|
| To: [EMAIL PROTECTED]
|
| cc:
|
| Subject: Re: Heartbeat, Keepalive and Client Connection Timeouts
|
>
--------------------------------------------------------------------------------------------------------------|
Nice solution.
Sid
-----Original Message-----
From: McCarty, Brian [mailto:[EMAIL PROTECTED]
Sent: Wednesday, 10 September 2003 12:24 PM
To: [EMAIL PROTECTED]
Subject: Re: Heartbeat, Keepalive and Client Connection Timeouts
Is there a reply q back to your local queue manager? If so, just create a
remote q definition on your server that points to a queue on the remote
server that does not actually exist. Make the message a request message
with the discard option set asking for a report message. The report
message
will keep their/sender - your/receiver running. If that's not needed, just
take off the report message option. In Java it would look like this:
message = new MQMessage();
pmo.options = MQC.MQPMO_FAIL_IF_QUIESCING
| MQC.MQPER_NOT_PERSISTENT;
byte b[] = new byte[24];
Random r = new Random();
r.nextBytes(b);
message.correlationId = (b);
message.expiry = 5;
message.report = MQC.MQRO_EXCEPTION_WITH_FULL_DATA
| MQC.MQRO_PASS_MSG_ID
| MQC.MQRO_PASS_CORREL_ID
| MQC.MQRO_DISCARD_MSG; message.replyToQueueManagerName =
"SOME_OTHER_QUEUE_MANAGER"; message.replyToQueueName = "SOME_OTHER_QUEUE";
message.messageType = MQC.MQMT_REQUEST; try {
request_queue.put(message, pmo);
}
If you want to route the report message elsewhere, just set the
replyToQueue* fields also.
B
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Tuesday, September 09, 2003 9:00 PM
To: [EMAIL PROTECTED]
Subject: Re: Heartbeat, Keepalive and Cleint Connection Timeouts
Pump data to another queue and have a process to drop it somewhere.
Sid
-----Original Message-----
From: Stuart Bourne [mailto:[EMAIL PROTECTED]
Sent: Wednesday, 10 September 2003 11:53 AM
To: [EMAIL PROTECTED]
Subject: Heartbeat, Keepalive and Cleint Connection Timeouts
Hello all,
I am running MQ 5.3 on HP-UX 11i. A VB/MQ client front end on NT
communicates with the qmgr via a Server Connection channel to a permanent
local queue while replies to the client are via temporary dynamic queues. A
process on the server sits and waits for a message with an MQGET after
establishing a connection to the qmgr and opening the local queue. The
client process establishes a connection to the qmgr, opens a dynamic reply
queue and will then sit and wait for the operator to initiate a
transaction.
At this point there is no application generated traffic between client and
server. The HBINT on the channel is defaulted to 300 and I have included
the
TCP:, KeepAlive=Yes section in the qmgr's qm.ini file. There is a firewall
between the client and the server and this firewall has a one hour timeout
on idle connections. Client connections are being killed by the firewall
after this one hour timeout period. I do not want these sessions to be
killed and thought that the HBINT and KeepAlive settings would generate
traffic between client and server that would prevent the connections being
deemed idle by the firewall. The comms people have put a trace on traffic
between client and server and tell me that there is none. Obviously my
understanding of HBINT and KeepAlive is incorrect. Can anyone first of all
tell me how I can prevent my idle connections being terminated by the
firewall and secondly explain exactly what HBINT and KeepAlive parameters
achieve. Thanks in advance. MQ newbie. Stuart Bourne. Hansen Technologies.
Australia.
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
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
