urllib3 Custom LifoQueue (Fix)

The Fix

pip install urllib3==1.25

Based on closed urllib3/urllib3 issue #1087 · PR/commit linked

Jump to Verify Open PR/Commit

@@ -41,11 +41,7 @@
 from .util.timeout import Timeout
 from .util.url import get_host, Url
-
-
-if six.PY2:

repro.py

import queue
import time

class LifoQueue(queue.Queue):

    def _qsize(self, len=len):
        return len(self.queue)

    def _put(self, item):
        self.queue.append(item)

    def _get(self):
        return self.queue.pop()
    
size = 500000

start = time.time()
deque_lifo_queue = LifoQueue(size)
for i in range(size):
    deque_lifo_queue.put(i)
for i in range(size):
    deque_lifo_queue.get(i)

print('deque backend cost time: {}'.format(time.time()-start))

start = time.time()
deque_lifo_queue = queue.LifoQueue(size)
for i in range(size):
    deque_lifo_queue.put(i)
for i in range(size):
    deque_lifo_queue.get(i)

print('list backend cost time: {}'.format(time.time() - start))

verify

Re-run the minimal reproduction on your broken version, then apply the fix and re-run.

fix.md

Option A — Upgrade to fixed release\npip install urllib3==1.25\nWhen NOT to use: This fix should not be used if backward compatibility with existing LifoQueue behavior is required.\n\n

Why This Fix Works in Production

Trigger: As a further suggestion, there doesn't seem to be any reason the standard library can't use a deque instead of a list. I suggest if there is a performance…
Mechanism: The LifoQueue implementation used a list instead of a deque, causing performance issues
Why the fix works: Switches to using a custom LifoQueue that utilizes a collections.deque backend for improved performance. (first fixed release: 1.25).

Why This Breaks in Prod

Shows up under Python 3.6.5 in real deployments (not just unit tests).
The LifoQueue implementation used a list instead of a deque, causing performance issues
Production symptom (often without a traceback): As a further suggestion, there doesn't seem to be any reason the standard library can't use a deque instead of a list. I suggest if there is a performance advantage in this change that you propose the change upstream as well.

Proof / Evidence

GitHub issue: #1087
Fix PR: https://github.com/urllib3/urllib3/pull/1356
First fixed release: 1.25
Reproduced locally: No (not executed)
Last verified: 2026-02-09
Confidence: 0.95
Did this fix it?: Yes (upstream fix exists)
Own content ratio: 0.60

Discussion

High-signal excerpts from the issue thread (symptoms, repros, edge-cases).

Jump to Sources Open on GitHub

“As a further suggestion, there doesn't seem to be any reason the standard library can't use a deque instead of a list. I suggest if…”

@Lukasa · 2017-01-06 · source

“Can you provide a benchmark of the two implementations side-by-side to demonstrate the performance difference, please?”

@Lukasa · 2017-01-06 · source

“I came across this issue today, and looking around found this benchmark and it seems there are real gains in the switch https://stackoverflow.com/a/20330499/454332”

@friscoMad · 2017-12-21 · source

“Hello, I think there is no need to change LifoQueue backend to deque”

@nikan1996 · 2018-08-15 · source

Failure Signature (Search String)

As a further suggestion, there doesn't seem to be any reason the standard library can't use a deque instead of a list. I suggest if there is a performance advantage in this change
Hello, I think there is no need to change LifoQueue backend to `deque`.

Copy-friendly signature

signature.txt

Failure Signature
-----------------
As a further suggestion, there doesn't seem to be any reason the standard library can't use a deque instead of a list. I suggest if there is a performance advantage in this change that you propose the change upstream as well.
Hello, I think there is no need to change LifoQueue backend to `deque`.

Error Message

Signature-only (no traceback captured)

error.txt

Error Message
-------------
As a further suggestion, there doesn't seem to be any reason the standard library can't use a deque instead of a list. I suggest if there is a performance advantage in this change that you propose the change upstream as well.
Hello, I think there is no need to change LifoQueue backend to `deque`.

Minimal Reproduction

repro.py

import queue
import time

class LifoQueue(queue.Queue):

    def _qsize(self, len=len):
        return len(self.queue)

    def _put(self, item):
        self.queue.append(item)

    def _get(self):
        return self.queue.pop()
    
size = 500000

start = time.time()
deque_lifo_queue = LifoQueue(size)
for i in range(size):
    deque_lifo_queue.put(i)
for i in range(size):
    deque_lifo_queue.get(i)

print('deque backend cost time: {}'.format(time.time()-start))

start = time.time()
deque_lifo_queue = queue.LifoQueue(size)
for i in range(size):
    deque_lifo_queue.put(i)
for i in range(size):
    deque_lifo_queue.get(i)

print('list backend cost time: {}'.format(time.time() - start))

Environment

Python: 3.6.5

What Broke

Performance degradation observed during connection pooling, leading to slower response times.

Why It Broke

The LifoQueue implementation used a list instead of a deque, causing performance issues

Fix Options (Details)

Option A — Upgrade to fixed release Safe default (recommended)

pip install urllib3==1.25

When NOT to use: This fix should not be used if backward compatibility with existing LifoQueue behavior is required.

Use when you can deploy the upstream fix. It is usually lower-risk than long-lived workarounds.

Fix reference: https://github.com/urllib3/urllib3/pull/1356

First fixed release: 1.25

Last verified: 2026-02-09. Validate in your environment.

When NOT to Use This Fix

This fix should not be used if backward compatibility with existing LifoQueue behavior is required.

Verify Fix

verify

Re-run the minimal reproduction on your broken version, then apply the fix and re-run.

Did This Fix Work in Your Case?

Quick signal helps us prioritize which fixes to verify and improve.

Prevention

Add a CI check that diffs key outputs after upgrades (OpenAPI schema snapshots, JSON payload shapes, CLI output).
Upgrade behind a canary and run integration tests against the canary before 100% rollout.
Track RSS + object counts after deployments; alert on monotonic growth and GC pressure.
Add a long-running test that repeats the failing call path and asserts stable memory.

Version Compatibility Table

Version	Status
1.25	Fixed

Related Issues

No related fixes found.

Cluster: urllib3:connection-leak urllib3 hub urllib3 best practices All hubs All clusters

Related clusters: Configuration error Data consistency SSL handshake

Sources

We don’t republish the full GitHub discussion text. Use the links above for context.