If you run daphne --endpoint ssl:8000:privateKey=key.pem:certKey=cert.pem --bind 0.0.0.0 MyApp.asgi:application in trying to specify that the application should bind to 0.0.0.0, two bindings will be made to the same port, and daphne will never properly start. While I know the --bind 0.0.0.0 specification is unnecessary, it's certainly confusing to debug and is not intuitive from the standpoint of the programmer trying to use the CLI.

Done! Thanks for your work on this, I'm excited to get the actual methods/functions typed now as well.

These are useful for users of asgiref to type check their ASGI usage. It also serves as the reference typing for the ASGI Specification.

The whole point of thread_sensitive is to enable the ORM to work - threadsafe does not mean that it is not thread sensitive (that is, connections vary per thread). The feature was built almost exactly for the reason you describe - making the ORM threading and persistent connections make sense.

The only thing left to do is to make it so that thread_sensitive mode has one thread per request rather than one thread per process, but there's a series of PRs dropping that are going to enable that.

sync_to_async will always run the target function in the same thread as any other invocation of sync_to_async now that thread_sensitive defaults to True; would that not solve your issue? (Plus the executor only has a single thread anyway).

the thread_sensitive in my case is set to False since the ORM is thread-safe.

I'd prefer to merge as is.

I'm happy with this as is; let me know if you want to merge it or if you want to refine the typing a little with the omitted keys handled somehow. I personally think it's OK to not worry about handling omissions and be complete, or we could bring in something else that handles them OK (I know Pydantic does this, but it's not quite standard typing)

sync_to_async will always run the target function in the same thread as any other invocation of sync_to_async now that thread_sensitive defaults to True; would that not solve your issue? (Plus the executor only has a single thread anyway).

This allows for overriding it easily in derived classes, and it seems to be better than changing the loop's default executor (in the case of ASGI_THREADS being set).

Ref: https://github.com/django/channels/issues/1091

The PR is still marked as WIP so I'm going to close it to now as it's been over a year with no response from the author.

I'll try to take a look at this next weekend; don't have much time right now

Is this PR going?

[StatelessServer.application_exception][1] is not doing that, the format is not being applied, it's being deferred to the root logger's formatter:

async def application_exception(self, exception, application_details):
      """
      Called whenever an application coroutine has an exception.
      """
      logging.error(
          "Exception inside application: %s\n%s%s",
          exception,
          "".join(traceback.format_tb(exception.__traceback__)),
          "  {}".format(exception),
      )

I wonder why they are using the root logger instead of the module level logger. Anyway you can monkey patch this function or override it in some subclass.

I think it's common to use the @sync_to_async decorator to run Django ORM's queries, but in the current setup that function will be ran in the global thread pool. I would like to set a dedicated thread pool just to run database queries, so I can keep the database connections persistent for some time. Django states the following about persistent connections:

Since each thread maintains its own connection, your database must support at least as many simultaneous connections as you have worker threads [...] The development server creates a new thread for each request it handles, negating the effect of persistent connections. Don’t enable them during development.

In the global thread pool the threads may be busy running non query functions, so its persisted connection will not be usable. I think that could be done the same way it's done for single_thread_executor as a class variable of SyncToAsync, so user's could subclasss it and change the executor. Maybe allowing it to be passed throught constructor would be better.

I needed to run Twisted code inside an ASGI application served by a StatelessServer, but it's not possible to setup the event-loop the server runs on, since it's created in StalelessServer.run(). Twisted supports integration with asyncio through the asyncio reactor, which is installed over a given asyncio loop, so the server should be ran over the same event-loop used to install the Twisted's reactor.

Never mind, fixed it by installing Memurai

How did you resolve this issue? I am also getting this error and I am using ubuntu 20.04 in WSL Redis version is 5.0.7

Issues are for concrete, actionable bugs and feature requests only - if you're just asking for debugging help or technical support we have to direct you elsewhere. If you just have questions or support requests please use:

• Stack Overflow
• The Django Users mailing list django-users@googlegroups.com (https://groups.google.com/forum/#!forum/django-users)

We have to limit this because of limited volunteer time to respond to issues!

Please also try and include, if you can:

• Your OS and runtime environment, and browser if applicable linux,python3.8

• A pip freeze output showing your package versions aioredis==1.3.1 appdirs==1.4.4 asgiref==3.3.1 async-timeout==3.0.1 channels==3.0.3 channels-redis==3.2.0 cryptography==3.3.1 daphne==3.0.1 decorator==4.4.2 Django==3.0.5 django-daterange-filter==1.3.0 djongo==1.3.3 Jinja2==2.11.2 redis==3.5.3 rq==1.7.0 websockets==8.1

• What you expected to happen vs. what actually happened is there a way to complete my needs?

• How you're running Channels (runserver? daphne/runworker? Nginx/Apache in front?) python manage.py runserver

• Console logs and full tracebacks of any errors no errors. The websocket client can receive messages from server's loop.

When I run the project locally with php artisan server it works perfectly, but when I upload it to gcloud I get the error: ERR_TOO_MANY_REDIRECTS. I tried to use private browsing and delete the cookies.

live: https://cloud.google.com/community/tutorials/antho-bare-metal-getting-started

As a note for other async newcomers like myself, by far the easiest way to deal with this is just to move the entire block using querysets to a separate, non-async function and then wrap that function call in a sync_to_async where you previously had the block. I wasted a huge amount of time thinking that I should be able to get it done in the async function, and it is almost certain to not be time worth spent for others either!

While that becomes clearer after you waste time then re-read https://docs.djangoproject.com/en/3.1/topics/async/, it might be nice to add a note to that page. Would that be a reasonable addition? Should I submit a PR?

I'll submit this for publication this afternoon. The build and submission process takes a couple of hours, so it's possible that this might not go live until the beginning of the next business day.

It was suggested that I move this post from the Google Cloud Practitioners blog to the community site since it is a straight up tutorial.

its pretty straightforward, but it would be nice to clear and concise documentation on this

https://cloud.google.com/community/tutorials/dlp-hybrid-inspect

"hybrid inspection method" link is broken.