Wow, that was a quick response! Tim, is there a way for me to join the discussion? Is there another mail thread?
> On 24 Aug 2016, at 21:36, Tim Graham <[email protected]> wrote: > > multithreading support has been proposed a couple times but it hasn't passed > the discussion stage yet. > > https://code.djangoproject.com/ticket/20238 > https://code.djangoproject.com/ticket/25970 > > On Wednesday, August 24, 2016 at 2:21:07 PM UTC-4, roboslone wrote: > So I've tried LiveServerTestCase and it seems that live server is > single-threaded. > > If client timeout is 5 seconds, then LiveServerTestCase works fine for slow > requests, that take from 1 to 9 seconds to process. Second try will send > request to the same thread and client will get TimeoutError instead of "HTTP > 202 Accepted" (because thread is busy processing first request). > > I didn't find any information about how to start live server with multiple > threads in Django docs or LiveServerTestCase code, is that even possible? > > > On 24 Aug 2016, at 17:26, GMail <[email protected] <javascript:>> wrote: > > > > I didn't try LiveServerTestCase yet (and to be honest never heard of it > > before), I'll give it a try. Thanks! > > > > > >> On 24 Aug 2016, at 17:19, Shai Berger <[email protected] <javascript:>> > >> wrote: > >> > >> Yes, the prototype I mentioned is a PR against Django, except that if it > >> is > >> intended to clarify the request rather than supply it, it doesn't have to > >> be > >> full -- e.g. it doesn't need tests or documentation untill we decide we > >> want > >> the feature in. > >> > >> But before you go there -- isn't LiveServerTestCase (which starts a server > >> you > >> can send requests to) a better answer to your needs? > >> > >> On Wednesday 24 August 2016 17:10:42 GMail wrote: > >>> "Players" are backends (Django) and load balancer that proxies all user > >>> requests on one of the backends. In my case load balancer has small > >>> backend timeout (default is 3 sec, preferable is 1 sec) and it will send > >>> the same request (with the same X-Request-Id header) to another backend > >>> after this small timeout. Some requests may take a long time to process > >>> (well, longer than 1 sec), so backends should not try to process requests > >>> that are being processed by other backends (they actually return "HTTP > >>> 202 > >>> Accepted" instead). > >>> > >>> For testing purposes I have '/slow/<time>' view that takes exactly <time> > >>> seconds to process. > >>> > >>> What I want to do is this: > >>> 1. Use django.test.client.Client to send request with small timeout (like > >>> load balancer will do) and make assertion, that TimeoutError is raised. > >>> 2. > >>> Send same request again and make assertion, that backend responded with > >>> "HTTP 202 Accepted". 3. Wait for some time (<time> seconds to be sure, > >>> that request has been processed by first backend) and send same request > >>> again and make final assertion, that backend responded with "HTTP 200 > >>> OK". > >>> > >>> In my case backends are synchronised through distributed cache, so it > >>> doesn't matter which backend accepts each request, response will be the > >>> same. > >>> > >>> I do realise, that this can be accomplished by just firing up "manage.py > >>> runserver" and sending requests as real load balancer would do, but I > >>> think it's too much overhead for a simple test. > >>> > >>> By "prototype" you mean pull-request to Django with > >>> django.test.client.Client that supports 'timeout' argument, right? > >>> > >>>> On 24 Aug 2016, at 16:44, Shai Berger <[email protected] <javascript:>> > >>>> wrote: > >>>> > >>>> On Wednesday 24 August 2016 14:33:34 Александр Христюхин wrote: > >>>>> Actually network is not an issue here. I'm using locks in distributed > >>>>> cache to manage requests between backends and that's what I want to > >>>>> test. In this case calling Django directly is okay. > >>>> > >>>> I am sorry, then; it seems I have misunderstood your needs. Now I am > >>>> quite unsure about who are the "players" in your use-case -- who makes > >>>> requests to whom, what kind of requests, which side of these requests is > >>>> supposed to time out, and how the other side is supposed to discover the > >>>> problem. > >>>> > >>>> It may be helpful to do as Tim suggested and write a prototype, just so > >>>> we get the details in a clear and unambiguous way. > >>>> > >>>> HTH, > >>>> > >>>> Shai. > > > > > -- > You received this message because you are subscribed to the Google Groups > "Django developers (Contributions to Django itself)" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected] > <mailto:[email protected]>. > To post to this group, send email to [email protected] > <mailto:[email protected]>. > Visit this group at https://groups.google.com/group/django-developers > <https://groups.google.com/group/django-developers>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/93c1ee6d-a301-475f-a664-d8d5d63660c7%40googlegroups.com > > <https://groups.google.com/d/msgid/django-developers/93c1ee6d-a301-475f-a664-d8d5d63660c7%40googlegroups.com?utm_medium=email&utm_source=footer>. > For more options, visit https://groups.google.com/d/optout > <https://groups.google.com/d/optout>. -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/7E26BC93-F179-40CC-BAEC-859BE7E7E010%40gmail.com. For more options, visit https://groups.google.com/d/optout.
