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].
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/93c1ee6d-a301-475f-a664-d8d5d63660c7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to