Re: What's wrong with the jenkins testrun failing on ASGI (I think?)

Yup, I'm seeing if we can get asgiref fixed today, otherwise I'll revert the change that broke Django and issue 3.2.9. Andrew On Tue, Jun 16, 2020, at 2:48 AM, Florian Apolloner wrote: > Ok, so rebasing PRs to current master will fix this (leaving this here as > note for others who run into thi

Re: What's wrong with the jenkins testrun failing on ASGI (I think?)

Ok, so rebasing PRs to current master will fix this (leaving this here as note for others who run into this). On Tuesday, June 16, 2020 at 10:39:13 AM UTC+2, Mariusz Felisiak wrote: > > It's an issue with the asgiref==3.2.8, see > https://github.com/django/asgiref/issues/170. We temporarily pinn

Re: What's wrong with the jenkins testrun failing on ASGI (I think?)

It's an issue with the asgiref==3.2.8, see https://github.com/django/asgiref/issues/170. We temporarily pinned asgiref==3.2.7 [1]. Best, Mariusz [1] https://github.com/django/django/commit/dcb4d79ef719d824431a8b3ff8ada879bbab21cc -- You received this message because you are subscribed to the

What's wrong with the jenkins testrun failing on ASGI (I think?)

Hi, do we have any idea what is happening on https://djangoci.com/job/pr-mariadb/database=mysql,label=mariadb,python=python3.8/6459/ ? It seems as if (mostly) the same set of tests is failing over and over. Is this ASGI/concurrency related? Cheers, Florian -- You received this message becau

Re: On ASGI...

Raising this across in aio-libs for a bit of exploratory discussion... https://groups.google.com/forum/#!topic/aio-libs/7rJ8Pb1y7aA > I'm not sure where I sit on it - on one hand <...> on the other hand <...> Same really, yes. :) -- You received this message because you are subscribed to the G

Re: On ASGI...

> > > > If we end up with one format for channel names and messages that is > spread across two consumption forms (in-process async and cross-process > channel layers), I think that would still be a useful enough standard and > make a lot more people happy. > > Yes. I'm not sure if there aren't al

Re: On ASGI...

> My ideal solution is one that allows both approaches, and I'd like to investigate that further. I think you're getting closer to the sort of thing I'm imagining with the uvcorn designs, but I feel like there's still something a little extra that could be done so it's possible to offload over

Re: On ASGI...

FuncName() and FuncNameAsync() are common patterns in .NET land with async/await. The snake case translation would be funcname_async. From a quick scan, the JS world hasn't settled on a convention yet, though there is a bit of discussion about how to differentiate the names. Personally I don't

Re: On ASGI...

Right - as long as you make clients deal with reconnection (which obviously they should), then as long as your load-balancing has a way to shed connections from a sticky server by closing them then all should be fine. Honestly, I have always been annoyed at the no-local-context thing in channels;

Re: On ASGI...

> I wonder if there is a way of doing something like this well, so that it's easy to write but also lets you scale later. It's not obvious that sticky websockets are *necessarily* problematic for typically use cases. Couple of things you'd want: * Have clients be responsible for graceful reconn

Re: On ASGI...

Ah, I see, you are assuming sticky sockets. That makes things a lot easier to architecture, but a whole lot harder to load-balance (you have to get your load-balancer to deliberately close sockets when a server is overloaded as many will not go away by themselves). Still, it makes scaling down a l

Re: On ASGI...

> I note that your examples do not include "receiving messages from a WebSocket and sending replies" - I would love to see how you propose to tackle this given your current API, and I think it's the missing piece of what I understand. I've just added an `echo` WebSocket example. I've also now

Re: On ASGI...

On Mon, Jun 12, 2017 at 10:53 PM, Tom Christie wrote: > > def handler(channel_layer, channel_name, message): > > Oh great! That's not a million miles away from what I'm working towards on > my side. > Are you planning to eventually introduce something like that as part of > the ASGI spec? > I ha

Re: On ASGI...

> def handler(channel_layer, channel_name, message): Oh great! That's not a million miles away from what I'm working towards on my side. Are you planning to eventually introduce something like that as part of the ASGI spec? > So is the channels object just a place to stuff different function h

Re: On ASGI...

On Fri, Jun 9, 2017 at 8:22 PM, Tom Christie wrote: > Figure I may as well show the sort of thing I'm thinking wrt. a more > constrained consumer callable interface... > > * A callable, taking two arguments, 'message' & 'channels' > * Message being JSON-serializable python primitives. > * Channel

Re: On ASGI...

Figure I may as well show the sort of thing I'm thinking wrt. a more constrained consumer callable interface... * A callable, taking two arguments, 'message' & 'channels' * Message being JSON-serializable python primitives. * Channels being a dictionary of str:channel * Channel instances expose `

Re: On ASGI...

On Thu, Jun 8, 2017 at 8:55 PM, Tom Christie wrote: > > Any interface like this would literally just be "this function gets > called with every event, but you can't listen for events on your own" > > Gotcha, yes. Although that wouldn't be the case with asyncio frameworks, > since the channel read

Re: On ASGI...

> Any interface like this would literally just be "this function gets called with every event, but you can't listen for events on your own" Gotcha, yes. Although that wouldn't be the case with asyncio frameworks, since the channel reader would be a coroutine. Which makes for interesting design t

Re: On ASGI...

On Wed, Jun 7, 2017 at 7:05 PM, Tom Christie wrote: > Making some more progress - https://github.com/tomchristie/uvicorn > I'll look into adding streaming HTTP request bodies next, and then into > adding a websocket protocol. > > I see that the consumer interface is part of the channels API refer

Re: On ASGI...

Making some more progress - https://github.com/tomchristie/uvicorn I'll look into adding streaming HTTP request bodies next, and then into adding a websocket protocol. I see that the consumer interface is part of the channels API reference, rather than part of the ASGI spec. Is the plan to event

Re: On ASGI...

Right. I'll try and get a full async example up in channels-examples soon to show off how this might work; I did introduce a Worker class into the asgiref package last week as well, and the two things that you need to override on that are "the list of channels to listen to" and "handle this message

Re: On ASGI...

> I suspect there is potential for a very fast async-only layer that can trigger the await that's hanging in a receive_async() directly from a send() to a related channel, rather than sticking it onto a memory location and waiting Yup. Something that the gunicorn worker doesn't currently provid

Re: On ASGI...

Thanks for the continued speedy research, Tom! Weighing in on the design of an ASGI-direct protocol, the main issue I've had at this point is not HTTP (as there's a single request message and the body stuff could be massaged in somehow), but WebSocket, where you have separate "connect", "receive"

On ASGI...

I've been doing some initial work on a Gunicorn worker process that interfaces with an ASGI consumer callable, rather than a WSGI callable. https://github.com/tomchristie/asgiworker In the standard channels setup, the application is run behind a message bus... Protocol Server -> Channe

Re: Thoughts on ASGI or Why I don't see myself ever wanting to use ASGI

On Fri, May 6, 2016 at 2:11 PM, Carl Meyer wrote: > > On 05/06/2016 02:31 PM, Andrew Godwin wrote: > > > > On Fri, May 6, 2016 at 1:19 PM, Carl Meyer > > wrote: > > > > On 05/06/2016 01:56 PM, Donald Stufft wrote: > > > User level code would not be handling WebSo

Re: Thoughts on ASGI or Why I don't see myself ever wanting to use ASGI

On 05/06/2016 02:31 PM, Andrew Godwin wrote: > > On Fri, May 6, 2016 at 1:19 PM, Carl Meyer > wrote: > > On 05/06/2016 01:56 PM, Donald Stufft wrote: > > User level code would not be handling WebSockets asynchronously, that > > would be left up to the web se

Re: Thoughts on ASGI or Why I don't see myself ever wanting to use ASGI

On Fri, May 6, 2016 at 1:19 PM, Carl Meyer wrote: > On 05/06/2016 01:56 PM, Donald Stufft wrote: > > User level code would not be handling WebSockets asynchronously, that > > would be left up to the web server (which would call the user level code > > using deferToThread each time a websocket fra

Re: Thoughts on ASGI or Why I don't see myself ever wanting to use ASGI

On 05/06/2016 01:56 PM, Donald Stufft wrote: > User level code would not be handling WebSockets asynchronously, that > would be left up to the web server (which would call the user level code > using deferToThread each time a websocket frame comes in). Basically > similar to what’s happening now, e

Re: Thoughts on ASGI or Why I don't see myself ever wanting to use ASGI

> On 06 May 2016, at 21:56, Donald Stufft wrote: > >> On May 6, 2016, at 3:49 PM, Aymeric Augustin >> > > wrote: >> >> Sure, this works for WSGI, but barring significant changes to Django, it >> doesn’t make it convenient to handle WSGI synchronously

Re: Thoughts on ASGI or Why I don't see myself ever wanting to use ASGI

> On May 6, 2016, at 3:49 PM, Aymeric Augustin > wrote: > > Sure, this works for WSGI, but barring significant changes to Django, it > doesn’t make it convenient to handle WSGI synchronously and WebSockets > asynchronously with the same code base, let alone in the same process. User level co

Re: Thoughts on ASGI or Why I don't see myself ever wanting to use ASGI

> On 06 May 2016, at 19:59, Donald Stufft wrote: > >> On May 6, 2016, at 1:45 PM, Andrew Godwin > > wrote: >> >> On Fri, May 6, 2016 at 9:11 AM, Donald Stufft > > wrote: >> >> So what sort of solution would I personally advocate had I the ti

Re: Thoughts on ASGI or Why I don't see myself ever wanting to use ASGI

> On May 6, 2016, at 1:45 PM, Andrew Godwin wrote: > > Want to just cover a few more things I didn't in my reply to Aymeric. > > On Fri, May 6, 2016 at 9:11 AM, Donald Stufft > wrote: > > In short, I think that the message bus adds an additional layer of complexity >

Re: Thoughts on ASGI or Why I don't see myself ever wanting to use ASGI

Want to just cover a few more things I didn't in my reply to Aymeric. On Fri, May 6, 2016 at 9:11 AM, Donald Stufft wrote: > > > In short, I think that the message bus adds an additional layer of > complexity > that makes everything a bit more complex and complicated for very little > actual > ga

Re: Thoughts on ASGI or Why I don't see myself ever wanting to use ASGI

> > ISTM that the strongest argument in favor is that I think it _is_ > significantly easier for a casual user to build and deploy their first > websockets app using Channels than using any other currently-available > approach with Django. Both channels and Django+whatever-async-server > require ma

Re: Thoughts on ASGI or Why I don't see myself ever wanting to use ASGI

On 05/06/2016 11:09 AM, Aymeric Augustin wrote: > I think it's important to keep a straightforward WSGI backend in case we crack > this problem and build an async story that depends on asyncio after dropping > support for Python 2. > > I don't think merging channels as it currently stands hinders

Re: Thoughts on ASGI or Why I don't see myself ever wanting to use ASGI

On Fri, May 6, 2016 at 10:09 AM, Aymeric Augustin < aymeric.augus...@polytechnique.org> wrote: > Hello Donald, all, > > Some thoughts inline below. > > > On 06 May 2016, at 18:11, Donald Stufft wrote: > > > > For an example, in traditional HTTP servers where you have an open > connection > > asso

Re: Thoughts on ASGI or Why I don't see myself ever wanting to use ASGI

Hello Donald, all, Some thoughts inline below. > On 06 May 2016, at 18:11, Donald Stufft wrote: > > For an example, in traditional HTTP servers where you have an open connection > associated with whatever view code you're running whenever the client > disconnects you're given a few options of w

Thoughts on ASGI or Why I don't see myself ever wanting to use ASGI

Let me just start out saying that I think that ASGI is reasonably designed for the pattern that it is attempting to produce. That being said, I am of the belief that the fundamental way that ASGI is designed to work misses the mark for the kind of feature that people should be using in the general