Application-level timeout for WSMQ_OpenSession service

In Azure Kubernetes Service (AKS), we observed that when a network connection is blocked by a Kubernetes Network Policy, the WSMQ_OpenSession service can take between 30 and 40 minutes to fail and return the error:

MQException during MQCONN: CC=2 RC=2538

During this period, application threads remain blocked waiting for the connection attempt to complete, leading to thread exhaustion, degraded throughput, increased resource consumption, and significant performance issues.

This behavior is not specific to Azure and is applicable to any Kubernetes platform that implements Network Policies through silent packet drops. In these scenarios, blocked traffic is discarded without sending any TCP reset or ICMP unreachable response. As a result, the Linux TCP stack continues retransmission attempts until the kernel-level TCP timeout is reached.

With a single connection attempt, the timeout is typically observed at approximately 5 minutes, which aligns with the default Linux TCP retransmission behavior. However, when multiple concurrent WSMQ_OpenSession requests are executed, retransmission cycles overlap and become serialized at different stages, causing the overall failure duration to increase substantially. In our testing, this resulted in connection attempts taking 35–40 minutes before failing. The duration could increase further as the number of parallel connection attempts grows.