We have an issue doing multi message PCF inquiries over slow connections, which leads to timing up of the inquiry.
Here is a scenario. Doing a MQCMD_INQUIRE_Q inquiry, specifying * for queue name. The queue manager is in US, the testing client application is in UK. When using default 5s response_wait_interval set on PCFExecute, the application times out getting all responses from PCF reply queue (no more messages).
If we increase response_wait_interval, then we can get attributes of all queues after about 22s.
Here is what is happening. When sending out PCF command, the code calculated expiry for its message based on response_wait_interval (multiplied by 3, which gives us 15 seconds).
We get each each individual reply message in time, well under 5 seconds. Hoever, as we have a long list of queue and attributes of each queue come as a separte message, it takes a lot of time to get each individual message. As a result, after 15 seconds the PCF command message expires and queue manager stops processing PCF inquiry and does not send any more reply messages. Then client waits for another 5 seconds, which is response_wait_interval, and then times out after 20 seconds.
The PCF command timeout (expiry of the command message) should be configured separately, instead of multiplying response_wait_interval by 3. If we get even longer list of queues to inquire, then command timeout may need to be extened even further. Doing it based on response_wait_interval is not good, as we increase waiting time for each reply, while we get them perfectly in times. Also, suppose we may want to extend command timeout to 60. In this case we would need to set response_wait_interval to get the desired effect. However, if command takes even longer, it means we would timeut after 80 seconds - 60 for PCF command expirty and additional 20 seconds to wait for the next reply. But all replies come in time, so we don't want to wait so long in a scenario like this.
We have an issue doing multi message PCF inquiries over slow connections, which leads to timing up of the inquiry.
Here is a scenario. Doing a
MQCMD_INQUIRE_Qinquiry, specifying*for queue name. The queue manager is in US, the testing client application is in UK. When using default 5sresponse_wait_intervalset onPCFExecute, the application times out getting all responses from PCF reply queue (no more messages).If we increase
response_wait_interval, then we can get attributes of all queues after about 22s.Here is what is happening. When sending out PCF command, the code calculated
expiryfor its message based onresponse_wait_interval(multiplied by 3, which gives us 15 seconds).We get each each individual reply message in time, well under 5 seconds. Hoever, as we have a long list of queue and attributes of each queue come as a separte message, it takes a lot of time to get each individual message. As a result, after 15 seconds the PCF command message expires and queue manager stops processing PCF inquiry and does not send any more reply messages. Then client waits for another 5 seconds, which is
response_wait_interval, and then times out after 20 seconds.The PCF command timeout (expiry of the command message) should be configured separately, instead of multiplying
response_wait_intervalby 3. If we get even longer list of queues to inquire, then command timeout may need to be extened even further. Doing it based onresponse_wait_intervalis not good, as we increase waiting time for each reply, while we get them perfectly in times. Also, suppose we may want to extend command timeout to 60. In this case we would need to setresponse_wait_intervalto get the desired effect. However, if command takes even longer, it means we would timeut after 80 seconds - 60 for PCF command expirty and additional 20 seconds to wait for the next reply. But all replies come in time, so we don't want to wait so long in a scenario like this.