On Wed, 6 Jun 2001 [EMAIL PROTECTED] wrote:
... at least then we know what the exception is.
:
Again - try that code in an interactive interpreter if you really want to
find out what's going on...
Yeah, thanks, that would work as a workaround, but isn't this buggish
behaviour?
On Wednesday 06 June 2001 18:03, Erik Enge wrote:
On Wed, 6 Jun 2001 [EMAIL PROTECTED] wrote:
... at least then we know what the exception is.
Again - try that code in an interactive interpreter if you really want to
find out what's going on...
Yeah, thanks, that would work as a
On Wed, 6 Jun 2001, Richard Jones wrote:
http://www.zope.org/Members/anthony/BarewordExcepts
Feel free to find the bad except: and submit a patch...
Ugh. There are tons of them... I'll see what I have time for.
___
Zope-Dev maillist -
On Sun, 29 Apr 2001, Erik Enge wrote:
I'll try to do an hour or so of analysing this tomorrow, and I'll get back
to you. :-)
Well, now we all know what vikings believe an hour or so mean, don't we?
I figured it out, I think. Let's say I have these two methods:
def a():
b()
def
Erik Enge wrote:
On Sun, 29 Apr 2001, Erik Enge wrote:
I figured it out, I think. Let's say I have these two methods:
def a():
b()
def b():
a()
If I call a(), then Zope dies and restarts without giving me any error
at all. Anyone got a clue?
There are many
Erik Enge wrote:
On Sun, 29 Apr 2001, Erik Enge wrote:
I figured it out, I think. Let's say I have these two methods:
def a():
b()
def b():
a()
If I call a(), then Zope dies and restarts without giving me any error
at all. Anyone got a
Dieter Maurer wrote:
Erik Enge wrote:
On Sun, 29 Apr 2001, Erik Enge wrote:
I figured it out, I think. Let's say I have these two methods:
def a():
b()
def b():
a()
If I call a(), then Zope dies and restarts without giving me any
Hmmm... saw these in the stupid log, just before the server crashed:
--
2001-05-03T10:09:34 INFO(0) Z2 CONFLICT Competing writes at,
/VirtualHostBase/http/server.nipltd.com:80/VirtualHostRoot/folder/object
Traceback (innermost last):
File
Good morning, I presume? :-)
Chris McDonough wrote:
This probably isn't meaningful... unless it is. ;-)
Huh?
Conflict errors
are normal... I wish they wouldn't be so big and have an UPPERCASE
word in their description.
OK, but I did notice them just before the server died. Maybe now
Chris Withers wrote:
Good morning, I presume? :-)
Present!
This probably isn't meaningful... unless it is. ;-)
Huh?
This is a Jim Fultonism. In English, it means this is probably not
meaningful.
Conflict errors
are normal... I wish they wouldn't be so big and have an UPPERCASE
]
Subject: Re: [Zope-dev] Zope Server hanging :-(
On Wed, 2 May 2001, Chris McDonough wrote:
The docs (available via the --help switch) go into some of this detail,
but
I agree that a narrative explaining how to approach it from a functional
perspective would be a good thing.
This should go
Chris McDonough wrote:
You can also use cumulative reporting to sort by hangs:
requestprofiler.py your.log.file --cumulative --sort=hangs
python requestprofiler.py my.log --cumulative --sort=hangs out2.txt
resulted in:
Traceback (innermost last):
File requestprofiler.py, line 586,
: return (v1 + v2) / 2
def total(self):
t = 0
- Original Message -
From: Chris Withers [EMAIL PROTECTED]
To: Chris McDonough [EMAIL PROTECTED]
Cc: Tim McLaughlin [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Thursday, May 03, 2001 10:35 AM
Subject: Re: [Zope-dev] Zope Server
On Thu, 3 May 2001, Chris McDonough wrote:
It's no problem, especially as Michel had insomnia last night and did
it. ;-)
My best stuff comes out when I can't sleep.
Those of you who are interested in looking at it, check out the
ever-growing Zope Developer's Guide (shame on you if you
On Thu, 3 May 2001, Michel Pelletier wrote:
On Thu, 3 May 2001, Chris McDonough wrote:
It's no problem, especially as Michel had insomnia last night and did
it. ;-)
My best stuff comes out when I can't sleep.
Those of you who are interested in looking at it, check out the
Chris McDonough wrote:
Absolutely! When you've got some representative data, and you've
successfully run requestprofiler against it in various ways, let me know.
Hmmm, not really sure what I should be looking for :-S
What ways should I look to run it and what should I do with the output?
Attached is a script that I just checked into the trunk to do analysis
of
the file generated by the -M log. It can help you figure out if there's
a
pattern to the hangs (whether it happens on a particular method, whether
it
happens at heavy load time, whether it happens at a particular
One of the more important bits is the active count when using
the --detailed option to requestprofiler. This tells you how many *other*
requests were unfinished at the end of a particular request.
So for instance, if you run requestprofiler like this:
python requestprofiler.py log.file.name
Chris McDonough wrote:
snip info
Thanks, that's just what I was looking for
The goal is to indentify methods or requests that take a long time, don't
return, or are accessed frequently.
Yup
If you can match this data up with
specific problems you've experienced (possibly by way of
: Chris McDonough [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, May 02, 2001 12:00 PM
To: Chris Withers
Cc: Tim McLaughlin; [EMAIL PROTECTED]
Subject: Re: [Zope-dev] Zope Server hanging :-(
One of the more important bits is the active count when using
the --detailed option to requestprofiler
]; Chris Withers
[EMAIL PROTECTED]
Cc: Tim McLaughlin [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Wednesday, May 02, 2001 12:05 PM
Subject: RE: [Zope-dev] Zope Server hanging :-(
Nice info. This could be useful for many, many things. you oughtta put
this in a how-to (if you haven't already). thanks
:19 -0400
To: Tim McLaughlin [EMAIL PROTECTED], Chris Withers
[EMAIL PROTECTED]
Cc: Tim McLaughlin [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: Re: [Zope-dev] Zope Server hanging :-(
The docs (available via the --help switch) go into some of this detail, but
I agree that a narrative
On Wed, 2 May 2001, Chris McDonough wrote:
The docs (available via the --help switch) go into some of this detail, but
I agree that a narrative explaining how to approach it from a functional
perspective would be a good thing.
This should go in the debuggin and testing chapter of the dev
On Fri, 27 Apr 2001, Chris Withers wrote:
Well, I thought the upgrade to 2.3.2b2 would solve the problem but it
hasn't :-( I have a (very important :-S) Zope instance which hangs at
what seems like the slightest touch.
Maybe I can help.
I've seen similar behaviour, and by some chance I
Joachim Werner wrote:
Right now we don't face these problems any more. As far as I know, the only
thing Stephan changed on the server was exchanging the CoreSession tracking
by the newest version (0.8 I think), which had to be patched to run for us
AFAIK. Now the server is reliable again.
Tim McLaughlin wrote:
1. Hangs on anything from Pythonscript or dtml
Sounds about right.
2. top shows no significant mem or cpu usage
Yup
3. threads are all unresponsive
yup
4. restart usually yields a .trX file (an aborted transaction I suppose)
Hadn't noticed, but I'll ook out
Chris McDonough wrote:
I forgot to mention... our neither our z2.log or stupid_log show anything
upon freezing. afterwards the stupid_log shows the failed transaction
cleanup, but that's it.
Hmmm... it might be useful to turn on detailed request logging (-M logging)
in the start file
Erik Enge writes:
When, in my Zope Python Product, I call a method that does not exist, Zope
dies, restarts and then is fine again. If something (another method or a
browser perhaps) is calling this method again and again, Zope does a die,
restart, rinse, repeat.
I think the problem
On Sun, 29 Apr 2001, Dieter Maurer wrote:
Very strange!
Indeed.
Did you look in the log files? Have their been any core dumps?
I'll try to do an hour or so of analysing this tomorrow, and I'll get back
to you. :-)
___
Zope-Dev maillist -
The symptoms are as follows:
1. Go to a given URL, which doesn't respond (browser sits and spins)
2. Doing a 'top' on the server shows python nowhere to be seen (so it's
not
infinite-loop-processor-hogging)
3. ps shows the python threads are all still there, but none of them will
respond.
I forgot to mention... our neither our z2.log or stupid_log show anything
upon freezing. afterwards the stupid_log shows the failed transaction
cleanup, but that's it.
Hmmm... it might be useful to turn on detailed request logging (-M logging)
in the start file (see z2.py).
Attached is a
31 matches
Mail list logo
