Why do we use `param["url"]` as a unique connection pool key?

[calamont]

Hey all 🙂

I'm wondering if there was delibrate reason param["url"] was chosen as the connection pool key in the ConnectionFactory? Two cache configurations could still have the same URL. Once the first connection is created, any subsequent request will use the first parameters applied, regardless of which cache alias is requested from django.core.cache.caches.

If this is not desired behaviour I can open an PR to provide a workaround.

Thanks!

[WisdomPill]

might be a slip up, I did not create the library myself, I inherited it,
but I see your point here and I welcome any PR to solve the issue.

Just to be sure, you're referring to some options that could be used with some alias and not the others?

[calamont]

you're referring to some options that could be used with some alias and not the others?

Yeah. The use case I came up against was configuring two different timeouts. It seemed creating two aliases for these different configurations was the way forward (correct me if there is another approach I didn't see).

Because of the issue I described above, if the app used one timeout in one flow, any subsequent connection pool would use that timeout, even if the other alias was specified. The app is a monolith that uses a shared Elasticache instance, so there are a few flows were timeouts can be more generous.

I can raise a PR with the solution I ended up applying on my end, though there could be a better approach :)

[WisdomPill]

are we talking about the default timeout of an arbitrary key? or something at the connection level, like socket timeout?

[calamont]

Sorry, I meant the socket timeout and socket connect timeout.

[WisdomPill]

got it, please feel free to submit a PR and I will be happy to review it and merge it, also any feedback on the setup for the local development is welcome 😄

[ShudelEV]

Hi everyone! I encountered the same issue while using django-redis with multiple Sentinel clusters.

The problem occurs because connection_pool is reused when the LOCATION are the same ("LOCATION": "redis://mymaster/0"), but the SENTINELS configuration is different. This leads to a situation where the wrong Sentinel cluster is used for some cache instances.

I confirmed this by changing the db number for one of my cache configurations, which forced django-redis to create a separate connection pool. After that, everything worked correctly.

Are there any plans to fix this issue in future releases?