#34666 closed Bug (needsinfo)
Mysql issue using afirst "The client was disconnected by the server because of inactivity"
Reported by: | Bernardo Tavares | Owned by: | nobody |
---|---|---|---|
Component: | Database layer (models, ORM) | Version: | 4.2 |
Severity: | Normal | Keywords: | async, afirst, mysql, inactivity |
Cc: | Triage Stage: | Unreviewed | |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
I'm using Django 4.2 connected to a MySQL 8 database.
I'm running asyncio for a function I really need to run asynchronously:
from django.db import connection import asyncio example_object = asyncio.run(example(request)) connection.close()
async def example(request): object = await ModelExample.objects.filter(example=example).afirst() return object
I'm having the following error:
"The client was disconnected by the server because of inactivity. See wait_timeout and interactive_timeout for configuring this behavior"
Initially the work codes fine, the error only happens after a few hours (maybe 8h, like the default wait_timeout variable) after I restart the (nginx) server.
It's a low traffic website so it's very possible the function is executed only once a day.
In my understanding, Django always opens a connection, executes a query and then closes a connection.
Is it not closing the connection when using "afirst()"? This feels seems like a bug to me, or is something in the documentation I'm not getting.
Any help? Thank you in advance!
Other things that I tried:
- Before doing the connection.close(), I would have an error like: "MySQL server has gone away"
- Adding close_old_connections() before asyncio.run. Don't understand why there is an inactive connection left open at all.
- Increasing the wait_timeout value and interactive_timeout variables in my MySQL config file. I find it very strange that this had no impact at all but the "SHOW VARIABLES" command shows me they are indeed currently set to 31536000.
- Then I thought that maybe the connection from Django is somehow independent of that and tried setting CONN_HEALTH_CHECKS option to True, in the hopes that "if the health check fails, the connection will be re-established without failing the request"
- Changing the CONN_MAX_AGE from the default 0 to "None" in the Django settings file, which according to Django docs, means an unlimited persistent database connection, but then I would have a "Lost connection to MySQL server during query"
Change History (4)
follow-up: 3 comment:1 by , 17 months ago
follow-up: 4 comment:2 by , 17 months ago
Resolution: | → needsinfo |
---|---|
Status: | new → closed |
In my understanding, Django always opens a connection, executes a query and then closes a connection.
Yes, if you're talking about request-response cycle and connections are not persistent.
Is it not closing the connection when using "afirst()"? This feels seems like a bug to me, or is something in the documentation I'm not getting.
As far as I'm aware, this has nothing to do with afirst()
.
Any help? Thank you in advance!
I don't think you've explained the issue in enough detail to confirm a bug in Django and Trac is not a support channel. Please reopen the ticket if you can debug your issue and provide details about why and where Django is at fault. A small project that reproduces the issue will also help. If you're having trouble debugging, see TicketClosingReasons/UseSupportChannels for ways to get help.
comment:3 by , 17 months ago
Replying to Natalia Bidart:
I wonder if this is related to #33497...
Bernardo, do you think you could provide a minimal (but complete) example to reproduce this issue? Thanks!
I'm using unicorn with wsgi. Sure!
comment:4 by , 17 months ago
Replying to Mariusz Felisiak:
In my understanding, Django always opens a connection, executes a query and then closes a connection.
Yes, if you're talking about request-response cycle and connections are not persistent.
Is it not closing the connection when using "afirst()"? This feels seems like a bug to me, or is something in the documentation I'm not getting.
As far as I'm aware, this has nothing to do with
afirst()
.
Any help? Thank you in advance!
I don't think you've explained the issue in enough detail to confirm a bug in Django and Trac is not a support channel. Please reopen the ticket if you can debug your issue and provide details about why and where Django is at fault. A small project that reproduces the issue will also help. If you're having trouble debugging, see TicketClosingReasons/UseSupportChannels for ways to get help.
Understood. I will try to go deeper on this.
I opened a forum discussion here https://forum.djangoproject.com/t/debugging-the-client-was-disconnected-by-the-server-because-of-inactivity/21730 , if you can help me debug a bit further and explain why this is not related with afirst() I would be grateful.
I wonder if this is related to #33497...
Bernardo, do you think you could provide a minimal (but complete) example to reproduce this issue? Thanks!