- Zope - Zope lists

RE: SOLVED !!! (sorta) RE: [Zope] System performance threads/proc cesses & random crashes (SIGPIPE)
by Doyon, Jean-Francois 22 Mar '02

22 Mar '02

Not at all, Yes, registering a SIGPIPE handler that does nothing in z2.py fixes the problem. And I have sent an e-mail to the DA maintainers, as well as python and postgres people to try and better understand the problem. J.F. -----Original Message----- From: Chris McDonough [mailto:chrism@zope.com] Sent: Friday, March 22, 2002 6:32 PM To: Doyon, Jean-Francois; zope(a)zope.org Subject: Re: SOLVED !!! (sorta) RE: [Zope] System performance threads/proccesses & random crashes (SIGPIPE) I hope you dont mind me replying to the list... Actually, if registering a SIGPIPE signal handler "fixes" the problem, that is a perfectly ok thing to do and probably should become part of Zope startup. Does this actually fix the problem? It'd be nice to understand the problem better though. Maybe you could report the problem to one or both of the DA maintainers (if they're not reading the list) to see if they have any clues. - C ----- Original Message ----- From: "Doyon, Jean-Francois" <Jean-Francois.Doyon(a)CCRS.NRCan.gc.ca> To: "'Chris McDonough'" <chrism(a)zope.com> Sent: Friday, March 22, 2002 5:28 PM Subject: SOLVED !!! (sorta) RE: [Zope] System performance threads/proccesses & random crashes (SIGPIPE) > Chris, > > OK, it's official, the signal handling problem was coming from the > PostgreSQL Database adapters! Since the problem was occuring with BOTH > adapters, and I found no reference to signals in their source code, I have > ot assume it's the PostgreSQL client libs that are wrapped in python that > somehow interfere with the signal handling. > > I removed BOTH database adapters from my installation, removed the signal > trapping, retsarted, and did the "quick double click" trick, and bingo, I > got the ZServer errors, but none of the horrible crashing problems with > AIEEEE and error 500's .... > > The question now is: how do we fix this in a sensible manner? I will try and > contact the people from both of those DB interfaces to see if they have any > ideas, but maybe there's a Zope way to do it (Better in the sense that you > can control the problem centrally, insted of having to change all of the > DA's). > > I guess for now I will re-instate my signal trapping code, but a better > solution should be found. Since you may be more familiar with this kind of > stuff, how would you suggest I go about this? > > Thanks for everything, that was a fun littl eafternoon of debugging ... If > you're ever in Ottawa I'll buy you a beer! > > Cheers, > J.F. > > -----Original Message----- > From: Chris McDonough [mailto:chrism@zope.com] > Sent: Friday, March 22, 2002 4:53 PM > To: Chris McDonough; Doyon, Jean-Francois; zope(a)zope.org; matt(a)zope.com > Subject: Re: [Zope] System performance threads/proccesses & random > crashes (SIGPIPE) > > > You know, something comes to mind. When a UNIX process forks, it copies its > signal handler state to the child's process space. I dont know exactly how > the FastCGI stuff invokes Zope, but it may be that Python only installs a > SIGPIPE SIG_IGN handler if one isn't inherited from a parent process. > Setting it explicitly in z2.py ala the below message might cause your > problem to be solved if so. > > ----- Original Message ----- > From: "Chris McDonough" <chrism(a)zope.com> > To: "Doyon, Jean-Francois" <Jean-Francois.Doyon(a)CCRS.NRCan.gc.ca>; > <zope(a)zope.org>; <matt(a)zope.com> > Sent: Friday, March 22, 2002 4:41 PM > Subject: Re: [Zope] System performance threads/proccesses & random crashes > (SIGPIPE) > > > > > A couple of more things: > > > > > > This, so far as I can tell is a bug in the FastCGI implementation (Not > > > handling SIGPIPE as suggested). Should I report it somewhere? > > > > The bit you passed along from the FastCGI website seems to intimate that > the > > behavior is expected... I'm not sure where you would report it. ;-) > > > > > Python installs a small number of signal handlers by default: SIGPIPE is > > > ignored (so write errors on pipes and sockets can be reported as > ordinary > > > Python exceptions) > > > > I didn't know this. It appears Python already installs SIG_IGN as the > > signal handler for a SIGPIPE signal... mm. I'm not sure how your > > configuration manages to get around this. I'd have to guess that some > > product is resetting the signal handler. > > > > > And finally, how do I "ignore" a signal ? I guess just writing a "pass" > > > will work ? I'll try it out, I guess on reception of a signal, only one > > > handler is a called once? > > > > import signal > > signal.signal(signal.SIGPIPE, signal.SIG_IGN) > > > > This installs a null signal handler for the SIGPIPE signal. > > > > I wonder if you could find the place in the code where the exception > occurs > > when you click a lot and place a "print signal.getsignal(signal.SIGPIPE)" > > right before the place that the error happens. See if it's 1. If it's > 1... > > well, I'm not sure. I dont know how the process could be killed by a > SIGPIE > > then. > > > > If it's 0, that means that something has installed a signal handler on top > > of Python's default "ignore SIGPIPE" signal handler, and you might be able > > to find it by grepping for "SIGPIPE" or "13" in your code. > > > > - C > > > > > > > > _______________________________________________ > > Zope maillist - Zope(a)zope.org > > http://lists.zope.org/mailman/listinfo/zope > > ** No cross posts or HTML encoding! ** > > (Related lists - > > http://lists.zope.org/mailman/listinfo/zope-announce > > http://lists.zope.org/mailman/listinfo/zope-dev ) > > >

1 0

Re: SOLVED !!! (sorta) RE: [Zope] System performance threads/proccesses & random crashes (SIGPIPE)
by Chris McDonough 22 Mar '02

22 Mar '02

I hope you dont mind me replying to the list... Actually, if registering a SIGPIPE signal handler "fixes" the problem, that is a perfectly ok thing to do and probably should become part of Zope startup. Does this actually fix the problem? It'd be nice to understand the problem better though. Maybe you could report the problem to one or both of the DA maintainers (if they're not reading the list) to see if they have any clues. - C ----- Original Message ----- From: "Doyon, Jean-Francois" <Jean-Francois.Doyon(a)CCRS.NRCan.gc.ca> To: "'Chris McDonough'" <chrism(a)zope.com> Sent: Friday, March 22, 2002 5:28 PM Subject: SOLVED !!! (sorta) RE: [Zope] System performance threads/proccesses & random crashes (SIGPIPE) > Chris, > > OK, it's official, the signal handling problem was coming from the > PostgreSQL Database adapters! Since the problem was occuring with BOTH > adapters, and I found no reference to signals in their source code, I have > ot assume it's the PostgreSQL client libs that are wrapped in python that > somehow interfere with the signal handling. > > I removed BOTH database adapters from my installation, removed the signal > trapping, retsarted, and did the "quick double click" trick, and bingo, I > got the ZServer errors, but none of the horrible crashing problems with > AIEEEE and error 500's .... > > The question now is: how do we fix this in a sensible manner? I will try and > contact the people from both of those DB interfaces to see if they have any > ideas, but maybe there's a Zope way to do it (Better in the sense that you > can control the problem centrally, insted of having to change all of the > DA's). > > I guess for now I will re-instate my signal trapping code, but a better > solution should be found. Since you may be more familiar with this kind of > stuff, how would you suggest I go about this? > > Thanks for everything, that was a fun littl eafternoon of debugging ... If > you're ever in Ottawa I'll buy you a beer! > > Cheers, > J.F. > > -----Original Message----- > From: Chris McDonough [mailto:chrism@zope.com] > Sent: Friday, March 22, 2002 4:53 PM > To: Chris McDonough; Doyon, Jean-Francois; zope(a)zope.org; matt(a)zope.com > Subject: Re: [Zope] System performance threads/proccesses & random > crashes (SIGPIPE) > > > You know, something comes to mind. When a UNIX process forks, it copies its > signal handler state to the child's process space. I dont know exactly how > the FastCGI stuff invokes Zope, but it may be that Python only installs a > SIGPIPE SIG_IGN handler if one isn't inherited from a parent process. > Setting it explicitly in z2.py ala the below message might cause your > problem to be solved if so. > > ----- Original Message ----- > From: "Chris McDonough" <chrism(a)zope.com> > To: "Doyon, Jean-Francois" <Jean-Francois.Doyon(a)CCRS.NRCan.gc.ca>; > <zope(a)zope.org>; <matt(a)zope.com> > Sent: Friday, March 22, 2002 4:41 PM > Subject: Re: [Zope] System performance threads/proccesses & random crashes > (SIGPIPE) > > > > > A couple of more things: > > > > > > This, so far as I can tell is a bug in the FastCGI implementation (Not > > > handling SIGPIPE as suggested). Should I report it somewhere? > > > > The bit you passed along from the FastCGI website seems to intimate that > the > > behavior is expected... I'm not sure where you would report it. ;-) > > > > > Python installs a small number of signal handlers by default: SIGPIPE is > > > ignored (so write errors on pipes and sockets can be reported as > ordinary > > > Python exceptions) > > > > I didn't know this. It appears Python already installs SIG_IGN as the > > signal handler for a SIGPIPE signal... mm. I'm not sure how your > > configuration manages to get around this. I'd have to guess that some > > product is resetting the signal handler. > > > > > And finally, how do I "ignore" a signal ? I guess just writing a "pass" > > > will work ? I'll try it out, I guess on reception of a signal, only one > > > handler is a called once? > > > > import signal > > signal.signal(signal.SIGPIPE, signal.SIG_IGN) > > > > This installs a null signal handler for the SIGPIPE signal. > > > > I wonder if you could find the place in the code where the exception > occurs > > when you click a lot and place a "print signal.getsignal(signal.SIGPIPE)" > > right before the place that the error happens. See if it's 1. If it's > 1... > > well, I'm not sure. I dont know how the process could be killed by a > SIGPIE > > then. > > > > If it's 0, that means that something has installed a signal handler on top > > of Python's default "ignore SIGPIPE" signal handler, and you might be able > > to find it by grepping for "SIGPIPE" or "13" in your code. > > > > - C > > > > > > > > _______________________________________________ > > Zope maillist - Zope(a)zope.org > > http://lists.zope.org/mailman/listinfo/zope > > ** No cross posts or HTML encoding! ** > > (Related lists - > > http://lists.zope.org/mailman/listinfo/zope-announce > > http://lists.zope.org/mailman/listinfo/zope-dev ) > > >

1 0

dumb questions?
by Justin D Vose 22 Mar '02

22 Mar '02

hi! i'm currently running 2.5.0b3, and looking to upgrade to 2.5.0 (stable) -- is there an upgrade patch? or do i need to get the 2.5.0 (stable) source, unzip into my existing dir, and compile? i'm on Windows, unfortunately. :) i'm assuming that if i use the latest binary distro (5+Mb), it'll mess up what i've already got, right? jake

1 0

Security Question
by Jonathan Bryant 22 Mar '02

22 Mar '02

Hi all, I have a question about security and users in Zope. I'm trying to set up a system where a user sees the list of subfolders in a folder. The problem is that the user can only see those subfolders that he/she has access to. I've tried a number of different methods but none seem to work, specifically using AUTHENTICATED_USER.has_permission('View', MySubfolder) Let's say I have a folder called projects: projects/ (User 'Bill' role='View_Only') /project1 (User 'Bill' role='Manager') /project2 (User 'Bill' no role specified) Using the following dtml method I can get Bill's roles in each folder: <dtml-in "AUTHENTICATED_USER.getRoles()"> <dtml-var sequence-item> </dtml-in> So far so good, in the 'projects' folder I get: >>View_Only >>Authenticated And in the project1 folder I get >>Manager >>Authenticated Looks good, except that when I call my method from above FROM the projects folder Using the following code: <dtml-in expr="objectValues(['Folder'])"> <dtml-var title><br> <dtml-var roles> </dtml-in> I get the following input >>project1 >>View_only >>Authenticated >> >>project2 >>View_only >>Authenticated The roles for project2 makes sense since Bill inherits his role there from the parent folder. What I don't understand is why Bill's role of 'Manager' is unrecognized in folder 'project1' Thanks in advance, Jon Bryant _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com

1 0

Error with context.absolute_url() in Python script
by Harry Wilkinson 22 Mar '02

22 Mar '02

Hi all : ) I am hacking away at a CMF content type. This content type has an edit() method. There is a page template in a skins folder called mycontenttype_edit_form. The form in this PT submits to a Python script called mycontenttype_edit, which is also in the same skins folder. In this Python script, the edit() method is called through context.edit(), and then the user is redirected using a context.REQUEST.RESPONSE.redirect() call. In order to get the right address to redirect them to, I call context.absolute_url() and add some stuff to the end of the string. I am getting an error on context.absolute_url(). The traceback shows that the context is an instance of my content type. The context.edit() call is working fine. The error I am getting on absolute_url() is shown in this last bit of the traceback: line 115, in _exec (Object: question_edit) (Info: ({'script': <FSPythonScript instance at 8780e90>, 'context': <MyContentType instance at 8d286c8>, 'container': <CMFSite instance at 8a1f398>, 'traverse_subpath': []}, (), {}, None)) File Script (Python), line 13, in mycontenttype_edit File /usr/local/zope/2.5.0_base/lib/python/OFS/Traversable.py, line 37, in absolute_url (Object: contenttype_instance) File /usr/local/zope/2.5.0_base/lib/python/OFS/Traversable.py, line 60, in getPhysicalPath (Object: contenttype_instance File /usr/local/zope/2.5.0_base/lib/python/OFS/SimpleItem.py, line 65, in getId (Object: contenttype_instance) TypeError: id() takes exactly 1 argument (0 given) Does anyone have any ideas where I'm going wrong? Thanks in advance :) Harry

2 1

Why isn't my Python script updating my properties? (code included)
by A M Thomas 22 Mar '02

22 Mar '02

Hi there and thanks much for reading this. I'm sure I'm missing some fundamental point, but I've looked and haven't been able to find help in the documentation I have. A good example would be helpful, if anyone can recommend one. Basically, I've made a ZClass, called SiteSection, in my product. It has base classes of Folder, CatalogAware, and DTML Document. In a later version, I'll probably remove the DTML Document base class - I'm not sure why I included it. The ZClass has a property sheet (also called SiteSection) with these properties: title, LastModifiedBy, InSite, MainTextIsDTML, ContainedObjectsArePages, NavOrder, NavShortDescription, and NewMenuSection. (Please let me know if I shouldn't define title here). Also, creating an instance of SiteSection also creates a DTML Document inside the new instance with the ID of MainText. I have created a custom management view, currently called SiteSection_edit, which should allow the user to set most of the properties in the PropertySheet, as well as update the text in the MainText object. The form calls a Python script, included below, which should actually do the updating. I'm able to update the contents MainText successfully using these commands: try: # in case MainText doesn't exist - is there another way? context.manage_addDTMLMethod('MainText','') except: nop = 0; context.MainText.manage_edit(request['MainText'], '') I'm trying to set the other properties individually using manage_changeProperties, for example: context.manage_changeProperties(NavShortDescription=request['NavShortDescription']) I think I can do multiple properties at once, but was trying this form first. Oddly, the title property (and MainText) are the only properties that are being set. In its current form (more below on that), the script doesn't give an error, but neither does it update any of the other properties. I'm sure I'm doing several things wrong - can someone please correct me? Here's the complete Python script: ==================== SiteSection_edit_general ===================== # Import a standard function, and get the HTML request and response objects. from Products.PythonScripts.standard import html_quote request = container.REQUEST RESPONSE = request.RESPONSE # ----- update MainText object; create it if it doesn't exist try: context.manage_addDTMLMethod('MainText','') except: nop = 0; context.MainText.manage_edit(request['MainText'], '') # ----- ContainedObjectsArePages context.manage_changeProperties(ContainedObjectsArePages=request['ContainedObjectsArePages']) # ----- NavShortDescription context.manage_changeProperties(NavShortDescription=request['NavShortDescription']) # ----- NewMenuSection # why is it failing here? # context.manage_changeProperties(NewMenuSection=request['NewMenuSection']) # ----- title context.manage_changeProperties(title=request['title']) RESPONSE.redirect(context.absolute_url() + '/SiteSection_editform_general') return ===================== end Python script ============================ Also, for the sake of completeness and in case the problem is in the form, here is the pertinent section of SiteSection_editform_general, which invokes the above Python script: =================== SiteSection_editform_general =================== <Form action="<dtml-var absolute_url>/" method="post"> <table border="0" cellpadding="1" cellspacing="0" width="100%"><TR><td> <dtml-var body_font_tag> Title: <input type="text" name="title:string" size="35" value="<dtml-if title><dtml-var title></dtml-if>"> <p><dtml-if MainTextIsDTML>DTML Code:<dtml-else>Structured Text (<a href="<dtml-var "structured_text_help.absolute_url()">">help</a>)</dtml-if> <br><textarea name="MainText:text" rows="6" cols="50" wrap="virtual"><dtml-if MainText><dtml-var MainText></dtml-if></textarea> <br>Contents (at right) display: <input type="radio" name="ContainedObjectsArePages:boolean"<dtml-if ContainedObjectsArePages> checked="1"</dtml-if>>as Pages <input type="radio" name="ContainedObjectsArePages:boolean"<dtml-unless ContainedObjectsArePages> checked="1"</dtml-unless>>as Page Sections <p>Menu Description: <br><textarea name="NavShortDescription:text" rows="3" cols="50" wrap="virtual"><dtml-if NavShortDescription><dtml-var NavShortDescription></dtml-if></textarea> <br><input type="checkbox" name="NewMenuSection:boolean" <dtml-if NewMenuSection> checked="1"</dtml-if>>Starts New Menu Section <input name="SiteSection_edit_general:method" type="submit" class="form-element" value="Save Changes"> </form> ======================== end DTML code ============================= Any help would be most appreciated! Many thanks, Am Thomas --- Virtue of the Small http://virtueofthesmall.com

3 2

optional sql tag
by Horvath Adam 22 Mar '02

22 Mar '02

Hi, I have 3 select -> there are 3 form variable: year, month, day which are arguments for the ZSQL Method: select * from table c <dtml-sqlgroup where> ... <dtml-and> c.date >= <dtml-sqlvar "year+'-'+month+'-'+day" type=string> <dtml-and> ... </dtml-sqlgroup> It works great, but when there is nothing in the form variables, it will be c.date >='--' How can I do that with empty form variables this <dtml- and> tag would be optional? Halinux

3 2

How to use manage_clone right??
by Breitenreicher, Marc 22 Mar '02

22 Mar '02

Hi, I've got a problem with the manage_clone function. I used it several times before, but this time it's something special. Normally you clone an object like this, where 'mydoc' is the the object and 'new_id' the new name of the cloned object: <dtml-call "manage_clone(mydoc, 'new_id')"> In my special case, mydoc is not the object itself, but a string of the objects name. The function now can't clone, because mydoc (the string) is not an object and returns the error message AttributeError: cb_isCopyable So how can I clone an object by calling the manage_clone function with the variable 'mydoc'??? Thanks for help Marc

3 2

RE: [Zope] System performance threads/proccesses & random crashes (SIGPIPE)
by Doyon, Jean-Francois 22 Mar '02

22 Mar '02

Chris, Thanks for the great help. After doing some invertigation, I am now pretty sure the behavior mentionned in the FastCGI docs is what is happening here, a request isn't given time to finish. In my case this can be replicated by users clicking VERY fast on the web pages, sending a request to the server before the first one is finished. (I have some slow processes, drawing dynamically generated maps). I can replicate the SIGPIPE almost 100% using this method. Anyways, I took a look at the code you mentionned, and that will hopefully help, although I'm venturing in extremely unknown territory for me here! A couple of more things: This, so far as I can tell is a bug in the FastCGI implementation (Not handling SIGPIPE as suggested). Should I report it somewhere? Also I was reading the signal handling stuff for python and came upon this: Python installs a small number of signal handlers by default: SIGPIPE is ignored (so write errors on pipes and sockets can be reported as ordinary Python exceptions) Now I'm confused. If Python ignores SIGPIPE by default, why is Zope complaining ? This would mean there there is allready a SIGPIPE handler defined somwehere overriding the default, in which case that is probably where the change should be made, instead of adding yet another handler. And finally, how do I "ignore" a signal ? I guess just writing a "pass" will work ? I'll try it out, I guess on reception of a signal, only one handler is a called once? Thanks again and again :) J.F. -----Original Message----- From: Chris McDonough [mailto:chrism@zope.com] Sent: Friday, March 22, 2002 3:05 PM To: Doyon, Jean-Francois; zope(a)zope.org; matt(a)zope.com Subject: Re: [Zope] System performance threads/proccesses & random crashes (SIGPIPE) You could register a SIGPIPE handler for Zope that just ignores the signal. See the chrism-logrotate-branch in CVS at http://cvs.zope.org/?only_with_tag=chrism_logrotate_branch and take a look at z2.py's "installsighandlers" function... maybe use this branch but add a SIGPIPE handler to the function that mimics the others except uses the function SIG_IGN as a callback instead of the current signal handler function. ----- Original Message ----- From: "Doyon, Jean-Francois" <Jean-Francois.Doyon(a)CCRS.NRCan.gc.ca> To: "'Chris McDonough'" <chrism(a)zope.com>; <zope(a)zope.org>; <matt(a)zope.com> Sent: Friday, March 22, 2002 2:45 PM Subject: RE: [Zope] System performance threads/proccesses & random crashes (SIGPIPE) Hello, Thanks for the help! Well, I've determined it most likely isn't PostgreSQL, since I switched the connections from socket based to TCP based, and the problem still occurs. So, I turn my attention to FastCGI ... I just read this on the FastCGI Website: If an http client aborts a request before it completes, mod_fastcgi does too - this results in a SIGPIPE to the FastCGI application. At a minimum, SIGPIPE should be ignored (applications spawned by mod_fastcgi have this setup automatically). Ideally, it should result in an early abort of the request handling within your application and a return to the top of the FastCGI accept() loop. I guess Zope isn't handling the SIGPIPE the way it is suggested here? Anyways this seems to be the most likely cause of the problems I'm having. That AND possibly the problem Matt describes. Matt, where can I find more information on this, and possible solutions? For now, I'm guessing switching to using TCP instead of sockets for FastCGI connections might help solve the problem? I am getting *A LOT* of these errors, every 5 to 10 minutes!!! And it *IS* traffic related ... when the business day dies down, the errors stop occuring (Normal usage pattern at this time would suupport the theory that the rrors are therefore directly related to the amount of usage). I'm also thinking of playing the -restart-delay option of the FastCgiServer directive ... Help!!! Thank you, J.F. -----Original Message----- From: Chris McDonough [mailto:chrism@zope.com] Sent: Thursday, March 21, 2002 11:08 AM To: Doyon, Jean-Francois; zope(a)zope.org Subject: Re: [Zope] System performance threads/proccesses & random crashes (SIGPIPE) SIGPIPE is raised by the OS when a UNIX pipe is broken in the application. UNIX takes this exception seriously which is why it sends the signal to the process telling it "you've got a broken pipe". As you say it started happening when you began using the database adapter, it may be that some piece of the database adapter opens a pipe that is later broken (for whatever reason, that's the $10,000 question ;-), causing the OS to send Zope a SIGPIPE. It may be possible to install a signal handler for SIGPIPE to get rid of the problem, but I'm not exactly sure what it should/would do during this failure state, and it would be more useful to try to pin down the pipe that is getting broken by making the problem replicable. The ZODB pool_size parameter is controlled via the pool_size argument to ZODB.DB.DB's constructor. It signifies how many database connections its willing to place in the pool. When Zope starts up, each Zope thread needs to use its own database connection. So you should likely never have a smaller pool_size than number of threads (the -t parameter to z2.py). Adjusting these values up and down may improve performance but there has to this day not been any empirical studies as to how performance is impacted when you do. It's probably something you need to try out in a load testing environment. If you find something interesting, let us know! ;-) ----- Original Message ----- From: "Doyon, Jean-Francois" <Jean-Francois.Doyon(a)CCRS.NRCan.gc.ca> To: <zope(a)zope.org> Sent: Thursday, March 21, 2002 9:57 AM Subject: [Zope] System performance threads/proccesses & random crashes (SIGPIPE) Hello, I'm running into random crashes of my zope processes, but I'm not finding any reference anywhere in the mailing list archives or on the site about this specific one: I'm getting: 2002-03-21T14:48:52 ERROR(200) zdaemon zdaemon: Thu Mar 21 09:48:52 2002: Aiieee! 20070 exited with error code: 13 Every now and then, for now apparent reason. signal 13 is a SIGPIPE ... This is Zope 2.5.0 with CMF 1.2 on a severly upgraded/updated/patched RH6.2 ... with a Python 2.1.2 built with defaults. It runs with FastCGI to Apache 1.3.2x ... Usually I just wait a couple of seconds, hit referesh in my browser and things come back to normal, but it's still annoying, and doesn't look good to the public. Note that when this happens, it ususally seems to happen to ALL processes. It looks to me like the PIPE's between the master zope process and it's children dies, and they all have to restart for some reason. Could this be ? and if so , why ? Note that I started noticing this when I for the first time started using Psycopg to create RDBMS connections to my PostgreSQL ... Could there be a relation somehow? On a slightly similar topic, How to I manage performance? I plan on using Zope for a fairly high demand web site .. I noticed I can control how many processes/threads start, but then I also read somethign about the ZODB pool_size ... What is the relation between the two exactly ? Thank you, Jean-François Doyon Internet Service Development and Systems Support GeoAccess Division Canadian Center for Remote Sensing Natural Resources Canada http://atlas.gc.ca Phone: (613) 992-4902 Fax: (613) 947-2410 _______________________________________________ Zope maillist - Zope(a)zope.org http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev ) _______________________________________________ Zope maillist - Zope(a)zope.org http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )

2 2

HomeSite 5 and Zope
by hpinson＠indepthl.com 22 Mar '02

22 Mar '02

Hi. Has anyone experienced this? When using Homesite 5 as an FTP interface to Zope 2.5, upon file save, HomeSite throws an error: "A discrepency in the byte counts of the local copy and the copy saved to the remote server has been detected. There may have been a problem in the transfer..." And any changes to the file are not saved. Harlow Pinson Indepth Learning Email: hpinson(a)indepthl.com Web: http://www.indepthl.com Voice: 505-994-2135 FAX: 208-475-7678

2 2