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

Reply via email to