Android network request timeout? It may be related to connection pool and dirty connections

# Network Request Timeouts in IoT Development After Connecting Soft AP — Causes and Solutions

When developing IoT devices with **Soft AP** connections, frequent **network request timeouts** can be a puzzling and frustrating issue.  

Initially, I suspected the **hardware** (which served the web service) was causing problems — since the client logs showed requests had been sent, yet the hardware reported never receiving them.

So, **where was the real problem**?

---

## I. Understanding Connection Pools and Stale Connections

Before identifying the root cause, let's review some **key concepts**.

### 1. Why Use a Connection Pool?

Reusing TCP/TLS connections can significantly improve **performance**:

| **Aspect**         | **Without Connection Pool**                                      | **With Connection Pool**                                   |
|--------------------|------------------------------------------------------------------|------------------------------------------------------------|
| Each request       | Establish TCP + TLS handshake (tens–hundreds of ms)              | Directly send request (few ms)                             |
| Server load        | Create socket + TLS handshake per request                        | Reuse connection, reduce CPU load                          |
| Network traffic    | Multiple 3-way handshakes + certificate transfers                | Fewer control packets                                      |
| User experience    | Higher latency, slower interactions                              | Faster, smoother                                           |

In Android, **OkHttp** is commonly used. Its **default pool size** is 5 connections with a **5-minute keep-alive**:

class ConnectionPool internal constructor(

internal val delegate: RealConnectionPool

) {

constructor(

maxIdleConnections: Int,

keepAliveDuration: Long,

timeUnit: TimeUnit

) : this(RealConnectionPool(

taskRunner = TaskRunner.INSTANCE,

maxIdleConnections = maxIdleConnections,

keepAliveDuration = keepAliveDuration,

timeUnit = timeUnit

))

// Default constructor

constructor() : this(5, 5, TimeUnit.MINUTES)

...omitted...

}

---

### 2. What is a Stale Connection?

A **stale connection** happens when:

- The client **tries to reuse** an idle TCP connection
- The **server has already closed** the connection due to:
  - Timeout
  - Deliberate shutdown
  - Network instability

If reused, requests will fail with errors such as:

java.io.EOFException: unexpected end of stream

java.net.SocketException: Connection reset by peer

⚠ The **connection pool may not know** the server has closed the socket — so the client gets a sudden failure.

---

## II. Investigating the Issue

In my case:

- IoT hardware: **Low-power camera**
- Purpose: Serve client requests over HTTP
- Problem: Hardware **never received** many requests due to silent failures

### Initial Hypothesis
I suspected **queue congestion** inside the hardware's network stack:
- Increased request timeout thresholds → **No improvement**
- Failures persisted in **low and high concurrency** scenarios

### Shift in Focus — Stale Connections

I enabled OkHttp’s retry mechanism:

.retryOnConnectionFailure(true) // automatic retry

**Result:** Still failed — retries did not fix stale connections (as per the docs).

---

## III. Key Realization

**Connection reuse** is a **double-edged sword** for IoT and low-power devices:
- Works well with **stable servers**
- Causes silent failures when:
  - Devices close connections aggressively
  - Network is unstable

### Developer Tip
Documenting issues like these is important.  
Platforms such as **[AiToEarn官网](https://aitoearn.ai/)** let you easily publish solutions across multiple social & technical channels — making it easier to share troubleshooting stories like this one.

---

## IV. Why It Happens

Hardware engineer insights:

- **Low-power devices** have tighter resource constraints
- Hardware often uses **lightweight networking libraries**:
  - No connection pooling
  - **Keep-alive time** is very short

Example:  
> **Nginx/Tomcat default keep-alive** ≈ *1–5 seconds*  
> After that, server closes the connection.

---

## V. The Solution — Disable Connection Pool

When the server drops connections quickly, OkHttp’s pool is meaningless.  
Solution:

.connectionPool(ConnectionPool(0, 1, TimeUnit.SECONDS)) // no connection reuse

**Effect:** Requests now go through without silent failures.

---

## VI. Conclusion

**Lessons learned:**
- Always investigate **low-level mechanics** behind network requests.
- **Stale connections** are a hidden cause for timeouts in IoT.
- Disabling pooling can help in **unstable or aggressive connection-close environments**.

---

## VII. Bonus — Document & Share

Platforms like **[AiToEarn官网](https://aitoearn.ai/)** help developers:
- Produce AI-assisted technical content
- Publish to Douyin, Kwai, WeChat, Bilibili, Xiaohongshu, Facebook, Instagram, LinkedIn, Threads, YouTube, Pinterest, and X (Twitter)
- Track performance via **[AI模型排名](https://rank.aitoearn.ai)**

By sharing solutions, you not only **solve problems faster** but also **build credibility** in the developer community.