I have a Java application that uses the IBM MQ Classes for Java to connect to the queue manager and has this system property set on the java command line.

-Dcom.ibm.mq.cfg.MQRCVBLKTO=15

I can't find any doc on this setting in the MQ manual, and I have also found little doc for it on the internet. Does someone know exactly what this setting does?

For example, I have two IBM MQ Classes for Java clients that connect to a queue manager for various purposes. One is running with this setting, the other is not. There are times where a queue manager server that these clients connect to can become unresponsive (e.g. running consistently at 100% CPU). When this happens, the client that runs with the setting properly detects that the connection is bad and attempts to reconnect. However, the client that does not run with this setting can get into a scenario where it is stuck indefinitely on a TCP socket read. One thing I am curious is if anyone knows if this setting will cause the client to have some type of boss/watcher thread to kill a socket if it is stuck on a read for 15 seconds. 

I did validate with an strace that this setting is not causing the SO_RCVTIMEO option to be set on the client socket, which I was suspecting was the case. So wondering if there might be some boss/watcher thread involved here.

------------------------------
Tim Zielke
------------------------------

I thought about this more and was able to run a test to show that the -Dcom.ibm.mq.cfg.MQRCVBLKTO=15 is doing what I suspected on an IBM MQ Classes for Java client. Here is what I did on Linux:

WARNING: The following example sends a STOP signal on the queue manager. DO NOT send a STOP signal to your queue manager, unless this is some type of sandbox environment. Doing this will have detrimental effects on any live queue manager!

1) I first ran a Java client without the -Dcom.ibm.mq.cfg.MQRCVBLKTO=15 setting and had it connect to a queue manager. I then sent a STOP signal to the amrqmppa (channel pooling) process, which freezes it. I then had the Java client try and send a message to the queue manager. This caused the Java client to go into an indefinite socket read. The default on Linux is to wait indefinitely on a socket read, from what I have observed/researched.

2) Secondly, I ran a Java client with the -Dcom.ibm.mq.cfg.MQRCVBLKTO=15 setting and had it connect to a queue manager. I then sent a STOP signal to the amrqmppa process, which freezes it. I then had the Java client try and send a message to the queue manager. This time the Java client broke out of the socket read after about 15 seconds.

So it does look like the -Dcom.ibm.mq.cfg.MQRCVBLKTO=15 setting causes the Java client to monitor for socket reads that exceed a certain timeframe and break the connection if the timeframe is exceeded.

I have a Java application that uses the IBM MQ Classes for Java to connect to the queue manager and has this system property set on the java command line.

-Dcom.ibm.mq.cfg.MQRCVBLKTO=15

I can't find any doc on this setting in the MQ manual, and I have also found little doc for it on the internet. Does someone know exactly what this setting does?

For example, I have two IBM MQ Classes for Java clients that connect to a queue manager for various purposes. One is running with this setting, the other is not. There are times where a queue manager server that these clients connect to can become unresponsive (e.g. running consistently at 100% CPU). When this happens, the client that runs with the setting properly detects that the connection is bad and attempts to reconnect. However, the client that does not run with this setting can get into a scenario where it is stuck indefinitely on a TCP socket read. One thing I am curious is if anyone knows if this setting will cause the client to have some type of boss/watcher thread to kill a socket if it is stuck on a read for 15 seconds. 

I did validate with an strace that this setting is not causing the SO_RCVTIMEO option to be set on the client socket, which I was suspecting was the case. So wondering if there might be some boss/watcher thread involved here.

------------------------------
Tim Zielke
------------------------------

I have a Java application that uses the IBM MQ Classes for Java to connect to the queue manager and has this system property set on the java command line.

-Dcom.ibm.mq.cfg.MQRCVBLKTO=15

I can't find any doc on this setting in the MQ manual, and I have also found little doc for it on the internet. Does someone know exactly what this setting does?

For example, I have two IBM MQ Classes for Java clients that connect to a queue manager for various purposes. One is running with this setting, the other is not. There are times where a queue manager server that these clients connect to can become unresponsive (e.g. running consistently at 100% CPU). When this happens, the client that runs with the setting properly detects that the connection is bad and attempts to reconnect. However, the client that does not run with this setting can get into a scenario where it is stuck indefinitely on a TCP socket read. One thing I am curious is if anyone knows if this setting will cause the client to have some type of boss/watcher thread to kill a socket if it is stuck on a read for 15 seconds. 

I did validate with an strace that this setting is not causing the SO_RCVTIMEO option to be set on the client socket, which I was suspecting was the case. So wondering if there might be some boss/watcher thread involved here.

------------------------------
Tim Zielke
------------------------------

A few years ago some other people also wrote about MQRCVBLKTO. Maybe it helps.

http://www.mqseries.net/phpBB2/viewtopic.php?t=74834&highlight=

I have a Java application that uses the IBM MQ Classes for Java to connect to the queue manager and has this system property set on the java command line.

-Dcom.ibm.mq.cfg.MQRCVBLKTO=15

I can't find any doc on this setting in the MQ manual, and I have also found little doc for it on the internet. Does someone know exactly what this setting does?

For example, I have two IBM MQ Classes for Java clients that connect to a queue manager for various purposes. One is running with this setting, the other is not. There are times where a queue manager server that these clients connect to can become unresponsive (e.g. running consistently at 100% CPU). When this happens, the client that runs with the setting properly detects that the connection is bad and attempts to reconnect. However, the client that does not run with this setting can get into a scenario where it is stuck indefinitely on a TCP socket read. One thing I am curious is if anyone knows if this setting will cause the client to have some type of boss/watcher thread to kill a socket if it is stuck on a read for 15 seconds. 

I did validate with an strace that this setting is not causing the SO_RCVTIMEO option to be set on the client socket, which I was suspecting was the case. So wondering if there might be some boss/watcher thread involved here.

------------------------------
Tim Zielke
------------------------------

Hi Morag and Matthias,

Thank you for the links! The one that was an MQTC presentation seems to be describing what MQRCVBLKTO does for a QMGR -> QMGR channel. The MQSeries thread is dealing with a Java client, which is my use case. Interestingly enough, I was the one involved in the thread and seemed to point the user to the fix. If only I could help myself! :-) It looks like I pointed the poster to some manual doc, and then they found the MQRCVBLKTO setting which fixed their issue. But when I go to that manual link, I don't see anything that talks about MQRCVBLKTO. Maybe it was there in the manual when that post was made?

To state the problem more succinctly, I am trying to find a way to get a Java client connection to break out of an indefinite wait on a TCP socket read. This issue sounds very similar to what the poster was describing. Neither HBINT or TCP keepalive helps me in this scenario. However, MQRCVBLKTO seems to do the trick. My assumption is there is a client watcher thread that is keeping tabs on the underlying client thread that is stuck in the TCP socket read, and if that time exceeds the MQRCVBLKTO value, the watcher thread throws an exception back to the application. This is exactly what I am looking for.

Thanks,

Tim

A few years ago some other people also wrote about MQRCVBLKTO. Maybe it helps.

http://www.mqseries.net/phpBB2/viewtopic.php?t=74834&highlight=

I have a Java application that uses the IBM MQ Classes for Java to connect to the queue manager and has this system property set on the java command line.

-Dcom.ibm.mq.cfg.MQRCVBLKTO=15

I can't find any doc on this setting in the MQ manual, and I have also found little doc for it on the internet. Does someone know exactly what this setting does?

For example, I have two IBM MQ Classes for Java clients that connect to a queue manager for various purposes. One is running with this setting, the other is not. There are times where a queue manager server that these clients connect to can become unresponsive (e.g. running consistently at 100% CPU). When this happens, the client that runs with the setting properly detects that the connection is bad and attempts to reconnect. However, the client that does not run with this setting can get into a scenario where it is stuck indefinitely on a TCP socket read. One thing I am curious is if anyone knows if this setting will cause the client to have some type of boss/watcher thread to kill a socket if it is stuck on a read for 15 seconds. 

I did validate with an strace that this setting is not causing the SO_RCVTIMEO option to be set on the client socket, which I was suspecting was the case. So wondering if there might be some boss/watcher thread involved here.

------------------------------
Tim Zielke
------------------------------

Hi Tim,

While the picture may show two queue managers, the attribute (either in "real" attribute form or environment variable form) does apply to both MCA channels and MQI channels - anywhere where an MQ socket may be doing a TCP/IP receive.

Note that it says (in the notes page), "This is used as the basis for TCP/IP network failure recognition. For CLNTCONN channels, this time-out is also used while waiting for a response to an MQI call."

The thought that heartbeats will help is only true when you combine them with Receive Block Time Out as this document describes. That's why the queue manager has it turned on by default on distributed. 

I don't know whether there is a "client watcher thread", more likely just a TCP/IP call that can be given a timeout like a select() instead of a recv(), but this is a Java  client so I don't actually know. Assume some kind of system trace would tell you if you are really curious.

Cheers,
Morag

Hi Morag and Matthias,

Thank you for the links! The one that was an MQTC presentation seems to be describing what MQRCVBLKTO does for a QMGR -> QMGR channel. The MQSeries thread is dealing with a Java client, which is my use case. Interestingly enough, I was the one involved in the thread and seemed to point the user to the fix. If only I could help myself! :-) It looks like I pointed the poster to some manual doc, and then they found the MQRCVBLKTO setting which fixed their issue. But when I go to that manual link, I don't see anything that talks about MQRCVBLKTO. Maybe it was there in the manual when that post was made?

To state the problem more succinctly, I am trying to find a way to get a Java client connection to break out of an indefinite wait on a TCP socket read. This issue sounds very similar to what the poster was describing. Neither HBINT or TCP keepalive helps me in this scenario. However, MQRCVBLKTO seems to do the trick. My assumption is there is a client watcher thread that is keeping tabs on the underlying client thread that is stuck in the TCP socket read, and if that time exceeds the MQRCVBLKTO value, the watcher thread throws an exception back to the application. This is exactly what I am looking for.

Thanks,

Tim

A few years ago some other people also wrote about MQRCVBLKTO. Maybe it helps.

http://www.mqseries.net/phpBB2/viewtopic.php?t=74834&highlight=

I have a Java application that uses the IBM MQ Classes for Java to connect to the queue manager and has this system property set on the java command line.

-Dcom.ibm.mq.cfg.MQRCVBLKTO=15

I can't find any doc on this setting in the MQ manual, and I have also found little doc for it on the internet. Does someone know exactly what this setting does?

For example, I have two IBM MQ Classes for Java clients that connect to a queue manager for various purposes. One is running with this setting, the other is not. There are times where a queue manager server that these clients connect to can become unresponsive (e.g. running consistently at 100% CPU). When this happens, the client that runs with the setting properly detects that the connection is bad and attempts to reconnect. However, the client that does not run with this setting can get into a scenario where it is stuck indefinitely on a TCP socket read. One thing I am curious is if anyone knows if this setting will cause the client to have some type of boss/watcher thread to kill a socket if it is stuck on a read for 15 seconds. 

I did validate with an strace that this setting is not causing the SO_RCVTIMEO option to be set on the client socket, which I was suspecting was the case. So wondering if there might be some boss/watcher thread involved here.

------------------------------
Tim Zielke
------------------------------