On Tue, 2007-06-19 at 06:51 +0100, David Reynolds wrote:
> Morning,
>
> We are experiencing a problem with Mysql with django. Since an svn
> up yesterday (which seems to be revision 5492) we have lots of
> sleeping (hanging) mysql processes and we keep hitting our limit of
> processes
Malcolm Tredinnick wrote:
> Perhaps read the remainder of the thread? :-)
Sorry, I was too impatient this time :-)
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send
On Fri, 2007-06-22 at 10:05 +0400, Ivan Sagalaev wrote:
> Malcolm Tredinnick wrote:
> > Thanks, Ilya. I'd gotten that far, too. Unfortunately, though, it isn't
> > quite that easy. Well, it is that easy for mod_python, however for WSGI
> > compliance, we can't do that (since the WSGI handler
Malcolm Tredinnick wrote:
> Thanks, Ilya. I'd gotten that far, too. Unfortunately, though, it isn't
> quite that easy. Well, it is that easy for mod_python, however for WSGI
> compliance, we can't do that (since the WSGI handler returns an
> iterable).
But a WSGI server calls "close()" on the
Malcolm Tredinnick wrote:
> One other thing that I forgot in my earlier email: it's not actually
> clear why the database connections get "lost" in the current
> implementation. We close the connection too early, but when the template
> rendering needs to access the database, it just opens a new
Hi Graham,
On Fri, 2007-06-22 at 02:44 +, Graham Dumpleton wrote:
> On Jun 22, 9:52 am, Malcolm Tredinnick <[EMAIL PROTECTED]>
> wrote:
> > On Thu, 2007-06-21 at 07:45 -0700, Ilya Semenov wrote:
> > > Malcolm,
> >
> > > I traced the problem and submitted the patch, see details at
> >
On Jun 22, 9:52 am, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> On Thu, 2007-06-21 at 07:45 -0700, Ilya Semenov wrote:
> > Malcolm,
>
> > I traced the problem and submitted the patch, see details at
> >http://code.djangoproject.com/ticket/4650
> > I'm not completely sure about the logic of
On Thu, 2007-06-21 at 07:45 -0700, Ilya Semenov wrote:
> Malcolm,
>
> I traced the problem and submitted the patch, see details at
> http://code.djangoproject.com/ticket/4650
> I'm not completely sure about the logic of signals though, the change
> may affect some middleware depending on it.
On Thu, 2007-06-21 at 07:45 -0700, Ilya Semenov wrote:
> Malcolm,
>
> I traced the problem and submitted the patch, see details at
> http://code.djangoproject.com/ticket/4650
> I'm not completely sure about the logic of signals though, the change
> may affect some middleware depending on it.
Malcolm,
I traced the problem and submitted the patch, see details at
http://code.djangoproject.com/ticket/4650
I'm not completely sure about the logic of signals though, the change
may affect some middleware depending on it.
--~--~-~--~~~---~--~~
You received
On Thu, 2007-06-21 at 09:45 +1000, Malcolm Tredinnick wrote:
> On Thu, 2007-06-21 at 01:14 +0200, Sean Mc Allister wrote:
> > Just to let you know, I'm using postgres and I am also experiencing the
> > same problems with revisions above 5481.
> > It doesn't seem to leave every connection open,
On Thu, 2007-06-21 at 01:14 +0200, Sean Mc Allister wrote:
> Just to let you know, I'm using postgres and I am also experiencing the
> same problems with revisions above 5481.
> It doesn't seem to leave every connection open, but more like 2 out of 3
> or something like that. so it's not only a
Just to let you know, I'm using postgres and I am also experiencing the
same problems with revisions above 5481.
It doesn't seem to leave every connection open, but more like 2 out of 3
or something like that. so it's not only a mysql thing.
Sean
David Reynolds wrote:
>
> On 19 Jun 2007, at
Malcolm,
I'm having exactly the same problem.
Under Apache+mod_python, each HTTP request keeps a stale MySQL
connection.
I traced the changeset, it was 5481->4582.
I put some logging to django.db.backends.mysql.base:
self.connection = Database.connect(**kwargs)
+ log.msg("connected to
On 19 Jun 2007, at 5:16 pm, Gábor Farkas wrote:
i'm glad this fixed your problem, but please note that:
from the information you provided, we know that 5481 works, but 5492
does not. but this does not mean that 5481 broke it. there are
still 10
revisions (starting with 5482 and ending with
David Reynolds wrote:
> Malcolm,
>
> On 19 Jun 2007, at 8:09 am, Malcolm Tredinnick wrote:
>
>> It would be interesting to know if anything prior to [5482] (that's
>> 5482, not 5492) works. There was a very large change in [5482] that
>> should be mostly invisible but may have some side-effects
Malcolm,
On 19 Jun 2007, at 8:09 am, Malcolm Tredinnick wrote:
It would be interesting to know if anything prior to [5482] (that's
5482, not 5492) works. There was a very large change in [5482] that
should be mostly invisible but may have some side-effects we need
to be
aware of.
Thanks
On Tue, 2007-06-19 at 06:51 +0100, David Reynolds wrote:
> Morning,
>
> We are experiencing a problem with Mysql with django. Since an svn
> up yesterday (which seems to be revision 5492) we have lots of
> sleeping (hanging) mysql processes and we keep hitting our limit of
> processes
On Tue, 2007-06-19 at 07:02 +0100, David Reynolds wrote:
> On 19 Jun 2007, at 6:56 am, Gábor Farkas wrote:
>
> > hi,
> >
> > i have no idea what went wrong, but to the developers it certainly
> > would
> > help, if you could find out exactly which revision broke the mysql
> > behaviour.
>
>
On 19 Jun 2007, at 6:56 am, Gábor Farkas wrote:
hi,
i have no idea what went wrong, but to the developers it certainly
would
help, if you could find out exactly which revision broke the mysql
behaviour.
Difficult to tell since we hadn't svn up'd for a while...
--
David Reynolds
[EMAIL
David Reynolds wrote:
> Morning,
>
> We are experiencing a problem with Mysql with django. Since an svn up
> yesterday (which seems to be revision 5492) we have lots of sleeping
> (hanging) mysql processes and we keep hitting our limit of processes
> (which we weren't doing before). Anyone
Morning,
We are experiencing a problem with Mysql with django. Since an svn
up yesterday (which seems to be revision 5492) we have lots of
sleeping (hanging) mysql processes and we keep hitting our limit of
processes (which we weren't doing before). Anyone have any idea why
it may be
22 matches
Mail list logo
