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 in the debuggin and testing chapter of the dev guide. Wanna take a stab? -Michel ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope Server hanging :-(
I'll vouch for the effectiveness of this method in tracking down some
problems. Chris' advice helped us track down some horrendous numbers around
a method calling DateTime. We've seen some definite improvements since we
reworked the way we're doing that function. It raises a question,
though--anyone else having weird performance issues using DateTime range
searches against DateTime values stored in the Catalog? We went from
checking a DateTime range to checking dates against an integer value, and
it's been working well.
> From: "Chris McDonough" <[EMAIL PROTECTED]>
> Date: Wed, 2 May 2001 12:08: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 explaining how to approach it from a functional
> perspective would be a good thing.
>
>
> - Original Message -
> From: "Tim McLaughlin" <[EMAIL PROTECTED]>
> To: "'Chris McDonough'" <[EMAIL PROTECTED]>; "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 Chris.
>>
>> I'll use it if we have any more issues. Currently, as I told ChrisW, the
>> issues have stopped. But I'm still keeping my eye on it.
>>
>> -Original Message-
>> From: 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. 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 --detailed
>>
>> And you see a profile line like (header added for reference):
>>
>> startwin wout wend tot S osize code act url
>> 2001-04-19T01:19:420 120 12 E 26024 2005
>> /Catalog/checkrep?P
>>
>> This means that:
>>
>> - this request started at 2001-04-19 1:19:42 UTC ("start")
>>
>> - zserver waited 0 secs for input from the client ("win")
>>
>> - zserver waited 12 secs for output from the publisher ("wend")
>>
>> - the total time from start to end for the request was 12 secs ("tot")
>>
>> - the request reached the end ("E") stage ("S", one of "E", "A", "I",
> "B")
>>
>> - the output size in bytes was 26024 ("osize")
>>
>> - the http code was 200 ("code")
>>
>> - the number of pending requests at the end of this request was 5
>> ("active")
>>
>> - the URL of the request ("url")
>>
>> Hangs are also interesting.
>>
>> Use detailed reporting to sort by end stage:
>>
>> requestprofiler.py your.log.file --detailed --sort=endstage
>>
>> Any requests that don't show a stage of "E" for their endstage were "hung"
>> requests.
>>
>> You can also use cumulative reporting to sort by "hangs":
>>
>> requestprofiler.py your.log.file --cumulative --sort=hangs
>>
>> This will show the methods that "hung" most frequently. Much of the time,
>> you can find problems this way by seeing methods that enter an infinte
> loop
>> or cause a segfault.
>>
>> Total time is also interesting:
>>
>> requestprofiler.py your.log.file --detailed --sort=total
>>
>> Shows you individual calls to methods that took a long time.
>>
>> - AND -
>>
>> requestprofiler.py your.log.file --cumulative --sort=total
>>
>> Shows you where most of the request time is spent.
>>
>> The goal is to indentify methods or requests that take a long time, don't
>> return, or are accessed frequently. If you can match this data up with
>> specific problems you've experienced (possibly by way of times/dates), it
>> becomes easier to form postulations about what is happening to Zope under
>> load. Then investigate those postulations by refactoring code or by doing
>> more detailed logging in the places where you think the problems are.
>>
>> - C
>>
>>
>>
>>
>>
>>> 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?
>>>
>>> cheers,
>>>
>>> Chris
>>>
>>
>
>
> ___
> Zope-Dev maillist - [EMAIL PROTECTED]
> http://lists.zope.org/mailman/listinfo/zope-dev
> ** No cross posts or HTML encoding! **
> (Related lists -
> http://lists.zope.org/mailman/listinfo/zope-announce
> http://lists.zope.org/mailman/listinfo/zope )
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://lists.zope.org/ma
[Zope-dev] ANNOUNCE Berkeley storage 1.0 beta 2 for Zope/ZODB
Hello Zope and ZODB users! The folks at Digital Creations, PythonLabs bring to you the second beta release of a Berkeley DB based storage for ZODB. Information about the Berkeley storage, can be found on the Berkeley storage Wiki at http://www.zope.org/Wikis/ZODB/BerkeleyStorage and other ZODB developments can be found on the ZODB Wiki page: http://www.zope.org/Wikis/ZODB/FrontPage This release of the Berkeley storage package contains the Packless.py implementation from 1.0beta1 which provides a non-versioning, non-undoable storage that uses reference counting to eliminate the need for explicit packs (except in the face of object cycles). The 1.0beta2 release adds two new storages: Full.py which is a complete versioning and undoable storage, and Minimal.py which is a rewritten non-versioning, non-undoable storage that will eventually replace Packless.py. Also included is an extensive PyUnit-based test suite. You must install Sleepycat's Berkeley DB 3.2.9 and Robin Dunn's PyBSDDB wrapper package. Berkeley storage 1.0beta2 has been tested with Python 2.0 and 2.1; it may work with Python 1.5.2 but no decision yet has been made whether that will be officially supported. Berkeley storage 1.0beta2 can be installed as a Python distutils package, and works well with StandaloneZODB distribution: http://www.zope.org/Wikis/ZODB/StandaloneZODB It, of course, can also be used with Zope, however please read the release notes concerning undo with the Full.py storage (there's a new non-destructive undo mechanism called Transactional Undo, which is not compatible with Zope 2.3.1 -- Full.py should work with Zope 2.3.1 but you will not be able to undo). Future development will include the integration of cyclic garbage detection with Full.py, and the addition of reference counting and cyclic gc to Minimal.py. See the ZODB Wiki for other developments. The release is available here: http://www.zope.org/Products/bsddb3Storage Discussions should take place on the [EMAIL PROTECTED] mailing list. Enjoy, -Barry Barry A. Warsaw PythonLabs at Digital Creations [EMAIL PROTECTED] ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
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 explaining how to approach it from a functional
perspective would be a good thing.
- Original Message -
From: "Tim McLaughlin" <[EMAIL PROTECTED]>
To: "'Chris McDonough'" <[EMAIL PROTECTED]>; "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 Chris.
>
> I'll use it if we have any more issues. Currently, as I told ChrisW, the
> issues have stopped. But I'm still keeping my eye on it.
>
> -Original Message-
> From: 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. 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 --detailed
>
> And you see a profile line like (header added for reference):
>
> startwin wout wend tot S osize code act url
> 2001-04-19T01:19:420 120 12 E 26024 2005
> /Catalog/checkrep?P
>
> This means that:
>
> - this request started at 2001-04-19 1:19:42 UTC ("start")
>
> - zserver waited 0 secs for input from the client ("win")
>
> - zserver waited 12 secs for output from the publisher ("wend")
>
> - the total time from start to end for the request was 12 secs ("tot")
>
> - the request reached the end ("E") stage ("S", one of "E", "A", "I",
"B")
>
> - the output size in bytes was 26024 ("osize")
>
> - the http code was 200 ("code")
>
> - the number of pending requests at the end of this request was 5
> ("active")
>
> - the URL of the request ("url")
>
> Hangs are also interesting.
>
> Use detailed reporting to sort by end stage:
>
> requestprofiler.py your.log.file --detailed --sort=endstage
>
> Any requests that don't show a stage of "E" for their endstage were "hung"
> requests.
>
> You can also use cumulative reporting to sort by "hangs":
>
> requestprofiler.py your.log.file --cumulative --sort=hangs
>
> This will show the methods that "hung" most frequently. Much of the time,
> you can find problems this way by seeing methods that enter an infinte
loop
> or cause a segfault.
>
> Total time is also interesting:
>
> requestprofiler.py your.log.file --detailed --sort=total
>
> Shows you individual calls to methods that took a long time.
>
> - AND -
>
> requestprofiler.py your.log.file --cumulative --sort=total
>
>Shows you where most of the request time is spent.
>
> The goal is to indentify methods or requests that take a long time, don't
> return, or are accessed frequently. If you can match this data up with
> specific problems you've experienced (possibly by way of times/dates), it
> becomes easier to form postulations about what is happening to Zope under
> load. Then investigate those postulations by refactoring code or by doing
> more detailed logging in the places where you think the problems are.
>
> - C
>
>
>
>
>
> > 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?
> >
> > cheers,
> >
> > Chris
> >
>
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )
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 Chris.
I'll use it if we have any more issues. Currently, as I told ChrisW, the
issues have stopped. But I'm still keeping my eye on it.
-Original Message-
From: 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. 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 --detailed
And you see a profile line like (header added for reference):
startwin wout wend tot S osize code act url
2001-04-19T01:19:420 120 12 E 26024 2005
/Catalog/checkrep?P
This means that:
- this request started at 2001-04-19 1:19:42 UTC ("start")
- zserver waited 0 secs for input from the client ("win")
- zserver waited 12 secs for output from the publisher ("wend")
- the total time from start to end for the request was 12 secs ("tot")
- the request reached the end ("E") stage ("S", one of "E", "A", "I", "B")
- the output size in bytes was 26024 ("osize")
- the http code was 200 ("code")
- the number of pending requests at the end of this request was 5
("active")
- the URL of the request ("url")
Hangs are also interesting.
Use detailed reporting to sort by end stage:
requestprofiler.py your.log.file --detailed --sort=endstage
Any requests that don't show a stage of "E" for their endstage were "hung"
requests.
You can also use cumulative reporting to sort by "hangs":
requestprofiler.py your.log.file --cumulative --sort=hangs
This will show the methods that "hung" most frequently. Much of the time,
you can find problems this way by seeing methods that enter an infinte loop
or cause a segfault.
Total time is also interesting:
requestprofiler.py your.log.file --detailed --sort=total
Shows you individual calls to methods that took a long time.
- AND -
requestprofiler.py your.log.file --cumulative --sort=total
Shows you where most of the request time is spent.
The goal is to indentify methods or requests that take a long time, don't
return, or are accessed frequently. If you can match this data up with
specific problems you've experienced (possibly by way of times/dates), it
becomes easier to form postulations about what is happening to Zope under
load. Then investigate those postulations by refactoring code or by doing
more detailed logging in the places where you think the problems are.
- C
> 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?
>
> cheers,
>
> Chris
>
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope Server hanging :-(
Chris McDonough wrote: > 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 times/dates), well, I have tail -f of the detailed log constantly open on my desktop ;-) > it > becomes easier to form postulations about what is happening to Zope under > load. To be honest, there really isn't any load on this server... maybe one or two people using it :-S > Then investigate those postulations by refactoring code or by doing > more detailed logging in the places where you think the problems are. Hmmm, I know what you mean but it doesn't sound like it's going to be fun :-S well, thanks for the info, I'll do what I can... Chris ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope Server hanging :-(
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 --detailed
And you see a profile line like (header added for reference):
startwin wout wend tot S osize code act url
2001-04-19T01:19:420 120 12 E 26024 2005
/Catalog/checkrep?P
This means that:
- this request started at 2001-04-19 1:19:42 UTC ("start")
- zserver waited 0 secs for input from the client ("win")
- zserver waited 12 secs for output from the publisher ("wend")
- the total time from start to end for the request was 12 secs ("tot")
- the request reached the end ("E") stage ("S", one of "E", "A", "I", "B")
- the output size in bytes was 26024 ("osize")
- the http code was 200 ("code")
- the number of pending requests at the end of this request was 5
("active")
- the URL of the request ("url")
Hangs are also interesting.
Use detailed reporting to sort by end stage:
requestprofiler.py your.log.file --detailed --sort=endstage
Any requests that don't show a stage of "E" for their endstage were "hung"
requests.
You can also use cumulative reporting to sort by "hangs":
requestprofiler.py your.log.file --cumulative --sort=hangs
This will show the methods that "hung" most frequently. Much of the time,
you can find problems this way by seeing methods that enter an infinte loop
or cause a segfault.
Total time is also interesting:
requestprofiler.py your.log.file --detailed --sort=total
Shows you individual calls to methods that took a long time.
- AND -
requestprofiler.py your.log.file --cumulative --sort=total
Shows you where most of the request time is spent.
The goal is to indentify methods or requests that take a long time, don't
return, or are accessed frequently. If you can match this data up with
specific problems you've experienced (possibly by way of times/dates), it
becomes easier to form postulations about what is happening to Zope under
load. Then investigate those postulations by refactoring code or by doing
more detailed logging in the places where you think the problems are.
- C
> 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?
>
> cheers,
>
> Chris
>
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope Server hanging :-(
> > 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 time of day, > > etc.) Do you think you'd be willing to play around with it a little bit to > > try to discover a pattern? > > Definitely, can you help me with 'reading the runes'? Absolutely! When you've got some representative data, and you've successfully run requestprofiler against it in various ways, let me know. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope Server hanging :-(
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? cheers, Chris ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Bug in dtml-in ????
Hi, i have found a solution in DT_In.py change this( beginning at line 537 ): else: kw['previous-sequence']=0 if index==last: try: # The following line is a sneaky way to # test whether there are more items, # without actually computing a length: sequence[end] pstart,pend,psize=opt(end+1-overlap,0, sz,orphan,sequence) kw['previous-sequence']=0 kw['next-sequence']=1 kw['next-sequence-start-index']=pstart-1 kw['next-sequence-end-index']=pend-1 kw['next-sequence-size']=pend+1-pstart except: pass to this: if index==last: try: # The following line is a sneaky way to # test whether there are more items, # without actually computing a length: sequence[end] pstart,pend,psize=opt(end+1-overlap,0, sz,orphan,sequence) kw['next-sequence']=1 kw['next-sequence-start-index']=pstart-1 kw['next-sequence-end-index']=pend-1 kw['next-sequence-size']=pend+1-pstart except: pass and everything works well with size=1 as Andre Schubert schrieb: > Hi, > > I have found a error/bug in the dtml-in tag. > I have an SQL-Query that returns traffic-data grouped by month and year. > > Th SQL-query returns 5 rows of data. > I want a page to show only one month. > If i use: > > > > . > > > > I got the following result. > The next-statement returns the url to the next row of data( the second > row ). > The context is the current row of data ( first row ). > If i click on the link to the next row( query_start=2 ) i got the the > second row of data, but i don't got a link to the third row of data, i > only got a link back to the first. > If i set size=2 everything works fine. > But when size=1 the the error occurs, i can only switch between the > first to rows of data. > I have testet it with different SQL-query's on Zope-2.2.5 on > Redhat-Immunix-6.2 > > Please help > > Thanks as > > ___ > Zope-Dev maillist - [EMAIL PROTECTED] > http://lists.zope.org/mailman/listinfo/zope-dev > ** No cross posts or HTML encoding! ** > (Related lists - > http://lists.zope.org/mailman/listinfo/zope-announce > http://lists.zope.org/mailman/listinfo/zope ) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope Server hanging :-(
Chris McDonough wrote: > > Hmmm... it might be useful to turn on detailed request logging (-M logging) > in the start file (see z2.py). OK, this is done now... > 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 time of day, > etc.) Do you think you'd be willing to play around with it a little bit to > try to discover a pattern? Definitely, can you help me with 'reading the runes'? cheers, Chris PS: > > 4. restart usually yields a .trX file (an aborted transaction I suppose) I didn't get any .tr? files, and no, I didn't rm them either ;-) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Hanging :-( More details... (before restart)
Well, it's still happening, this time I was just browsing the management interface :-( The last thing in Z2.log was: 194.193.44.4 - - [02/May/2001:14:35:30 +0100] "GET /VirtualHostBase/http/server.nipltd.com:80/VirtualHostRoot/manage_workspace HTTP/1.0" 302 440 "http://www.cases.nipltd.com/manage_menu"; "Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 4.0)" The last thing in the stupid log was: 2001-05-02T13:35:30 ERROR(200) ZODB Couldn't load state for '\000\000\000\000\000\020\030\177' Traceback (innermost last): File /usr/local/zope/Zope-2.3.2-src/lib/python/ZODB/Connection.py, line 508, in setstate AttributeError: 'None' object has no attribute 'load' When I tried to restart I got: 2001-05-02T13:42:00 PANIC(300) z2 Startup exception Traceback (innermost last): File /usr/local/zope/current/z2.py, line 566, in ? File , line 1, in ? File /usr/local/zope/Zope-2.3.2-src/lib/python/Zope/__init__.py, line 110, in ? File /usr/local/zope/Zope-2.3.2-src/lib/python/ZODB/FileStorage.py, line 264, in __init__ File /usr/local/zope/Zope-2.3.2-src/lib/python/ZODB/lock_file.py, line 101, in lock_file StorageSystemError: Could not lock the database file. There must be another process that has opened the file. Big wgh! That meant I needed to rm Data.fs.lock, sadly I actually did rm Data.fs due to tab-name completion and stupidity (tab and return do different things, duh!) Would anyone support a plea to have the lock file called something else? Anyway, once I'd got that restored off tape, then next restart yielded: Traceback (innermost last): File /usr/local/zope/current/z2.py, line 623, in ? File /usr/local/zope/Zope-2.3.2-src/ZServer/HTTPServer.py, line 391, in __init__ File /usr/local/zope/Zope-2.3.2-src/ZServer/medusa/http_server.py, line 542, in __init__ File /usr/local/zope/Zope-2.3.2-src/ZServer/medusa/asyncore.py, line 250, in bind error: (98, 'Address already in use') One killall -9 python later, and I now have Zope up and running with -M working. Wierdness with -M, I did -M var/server.dlog, Zope bitched that it couldn't create var/var/server.dlog I took the var out and it's okay. I wonder what gives? Anyway, if anyone's got ideas as to WTF is going on here, I'd love to hear them :-S cheers, Chris ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] CST 0.8 Updater Fixed...
Chris McDonough wrote: > > But to make it happen you'd need ZPublisher to support a > callback from ZServer when a connection was terminated. > Since I know little about either, I'm not entirely confident > I can be more specific. yeah, well, even I was impressed how high above my head that flew, so I think I'll leave it be in terms on trying to implement it. ;-) cheers, Chris ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] Bug in dtml-in ????
Hi, I have found a error/bug in the dtml-in tag. I have an SQL-Query that returns traffic-data grouped by month and year. Th SQL-query returns 5 rows of data. I want a page to show only one month. If i use: . I got the following result. The next-statement returns the url to the next row of data( the second row ). The context is the current row of data ( first row ). If i click on the link to the next row( query_start=2 ) i got the the second row of data, but i don't got a link to the third row of data, i only got a link back to the first. If i set size=2 everything works fine. But when size=1 the the error occurs, i can only switch between the first to rows of data. I have testet it with different SQL-query's on Zope-2.2.5 on Redhat-Immunix-6.2 Please help Thanks as ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
