Yes, mainly some things that needs to be done async and you don't want to
keep up the request for those such as email sending or logging. So this
work is just offloaded to a thread pool and the request returns instantly.
Also when you are using auto scaling services from amazon and since each
t
Is there a good reason to do this with your own custom thread pool
management inside Django and (I'm assuming) WSGI? Celery is a well
understood solution to the problem of background tasks and has a really
nice API.
On Wed, Jun 1, 2016 at 5:34 PM, Cristiano Coelho
wrote:
> Let me start saying so
That's pretty close but on a much more difficult level, since it is about
multi processing? Things starts to get very odd with multi processing and
django, compared to threads that you can easily launch a new thread or pool
without any special work, it is just the database connections handling t
Here's a ticket requesting the documentation you seek (as far as I
understand):
https://code.djangoproject.com/ticket/20562
On Wednesday, June 1, 2016 at 6:34:05 PM UTC-4, Cristiano Coelho wrote:
>
> Let me start saying sorry if this actually belongs to django-users rather
> than developers.
>
>
Let me start saying sorry if this actually belongs to django-users rather
than developers.
I'm curious about (and if someone can point me to the code) how exactly
django handles database connections (in particular when persistent
connections are used). As I can tell from the docs, they are kept
If this problem has been reported before, I don't remember it. Nothing
about our Trac installation has changed recently that I'm aware of. In case
it helps, I just updated to Trac 1.0.11.
It's unclear if the problem would be our problem and or an issue with Trac
but for what it's worth, our bug
It seems that the issue is somehow related to empty trac_session cookie which
somehow has got set. Here is the curl request which can be used to obtain the
403 response:
curl -I -H 'Cookie: trac_session=' https://code.djangoproject.com/ticket/2659
Clearing the cookies solved the problem, so the
Trying to browse any ticket on code.djangoproject.com yields 403 Forbidden,
with a message “TICKET_VIEW privileges are required to perform this operation.
You don't have the required permissions.”. An attempt to login via
https://code.djangoproject.com/login results in 502. It has been broken th
