[Zope-dev] RE: [Zope] highly available Zope thread; our hanging problem

2000-06-06 Thread Marcus Collins

Hi,

I'd like to comment on this, and summarise some references below. Much of
this discussion took place on the zope-dev list (see references), so I'm
cc'ing the zope-dev list. You might also wish to add to the Wiki:
http://www.zope.org/Members/tseaver/Projects/HighlyAvailableZope/.

 -Original Message-
 From: Brian Takashi Hooper [mailto:[EMAIL PROTECTED]]
 Sent: 06 June 2000 12:11
 To: [EMAIL PROTECTED]
 Subject: [Zope] highly available Zope thread; our hanging problem
 
 Hi all -
 
 I was looking at the discussion from April that was posted on the
 HighlyAvailableZope Wiki about problems with Zope hanging; we had a
 similar situation here at Digital Garage which seemed to be alleviated
 by changing the zombie_timeout to be really short (like, 1 minute). 
 Before changing the zombie_timeout, the server would periodically hang
 and not give any responses to requests, sometimes recovering after a
 short time.

Some questions at this point:
1. Were you running with multiple threads, and if so, how many?

2. If you were using multiple threads, would *all* the threads periodically
hang, or was the hanging isolated to a single thread at a time?

3. Could you possibly comment on the operating system used?

4. Which zombie_timeout did you twiddle -- the one in the zhttp_channel in
ZServer.py, or that in http_channel in medusa/http_server.py?

 At this point, I don't have anything more than just an empirical
 observation - changing this parameter seemed to help our server.  Has
 anyone else noticed anything similar, or can explain this observation?

Concerning the zombie_timeout suggestion, here are some references when I
posed the question of whether reducing the value would be beneficial:

Amos Lattier wrote in
http://lists.zope.org/pipermail/zope-dev/2000-April/004194.html:
 The ZServer zombie stuff is to get rid of zombie client 
 connections, not zombie publishing threads. These are quite 
 different beasts.

Michel Pelletier wrote in 
http://lists.zope.org/pipermail/zope-dev/2000-April/004229.html:
 What the Zombie timeout means is that after a publishing thread gets
 done answering a request, the socket may not go away.  This many for a a
 number of reasons, the client 'hung' and is not 'putting down the phone
 after the converstation is over' (so to speak) or network troubles may
 prevent the connection from closing properly.  This means that there is
 a 'zombie' connection laying around.  This zombie will probably end up
 going away on its own, but if not, ZServer will kill it after a period
 of time.
 
 The only reasorce laying around during the life of a Zombie is an tiny
 little unused open socket, the Mack truck of a Zope thread that served
 the request for the zombie socket does not 'hang' for that entire period
 of time, but goes on after it has completed the request to serve other
 requests.
 
 Amos is correct in that these problems are almost always at the
 Application level, and not at the ZServer level.  The fact that Pavlos
 can prevent hanging by inserting a print statement in the asyncore loop[*]
 is suspicious, but we do not have enough information yet to point
 fingers anywhere.

[* references http://lists.zope.org/pipermail/zope/2000-April/023697.html]

I'd be _very_ interested in hearing more on this! Our Zope installation has
been pretty stable of late (isn't it strange that, when you want to find out
what's causing things to break, they play nice?), with uptime of
thirty-something days, but I'm still very keen to get to the bottom of this,
since I don't believe it was some ephemeral problem.

hth, and thanks again!

-- Marcus

___
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] Re: [Zope] highly available Zope thread; our hanging problem

2000-06-06 Thread Brian Takashi Hooper


On Tue, 6 Jun 2000 15:19:29 +0200 
Marcus Collins [EMAIL PROTECTED] wrote:

 Hi,
 
 I'd like to comment on this, and summarise some references below. Much of
 this discussion took place on the zope-dev list (see references), so I'm
 cc'ing the zope-dev list. You might also wish to add to the Wiki:
 http://www.zope.org/Members/tseaver/Projects/HighlyAvailableZope/.
OK, that's a good suggestion!

 
  -Original Message-
  From: Brian Takashi Hooper [mailto:[EMAIL PROTECTED]]
  Sent: 06 June 2000 12:11
  To: [EMAIL PROTECTED]
  Subject: [Zope] highly available Zope thread; our hanging problem
  
  Hi all -
  
  I was looking at the discussion from April that was posted on the
  HighlyAvailableZope Wiki about problems with Zope hanging; we had a
  similar situation here at Digital Garage which seemed to be alleviated
  by changing the zombie_timeout to be really short (like, 1 minute). 
  Before changing the zombie_timeout, the server would periodically hang
  and not give any responses to requests, sometimes recovering after a
  short time.
 
 Some questions at this point:
 1. Were you running with multiple threads, and if so, how many?
Yes; Zope is set to run with 16 threads (-t 16), and we've increased the
pool_size parameter in ZODB/DB.py to 16 also (guess this is all
right... :-P )

 
 2. If you were using multiple threads, would *all* the threads periodically
 hang, or was the hanging isolated to a single thread at a time?
All the threads hang.  One interesting thing is, we looked at vmstat and
whenever the system is having trouble, the number of system calls drops
dramatically, when the server is doing well it's normally up in the
1000s, but when it's in trouble there are like 20-30 system calls per
second, and they're all either lwp_* or poll s.

 
 3. Could you possibly comment on the operating system used?
Solaris, 2.6, on netras.  Our Zope is still v. 2.1.4.

 
 4. Which zombie_timeout did you twiddle -- the one in the zhttp_channel in
 ZServer.py, or that in http_channel in medusa/http_server.py?
The one in zhttp_channel.  As far as I can tell, since zhttp_channels
are actually used instead of http_channels, the number in zhttp_channel
is the one that matters.  The kill_zombies method, and the code that
calls it, is inherited from the medusa code... kill_zombies looks at the
timeout value of all the channels in the select list, and since all of
those instances happen to be zhttp_channels in the case of Zope, they
all use the zhttp_channel timeout.

 
  At this point, I don't have anything more than just an empirical
  observation - changing this parameter seemed to help our server.  Has
  anyone else noticed anything similar, or can explain this observation?
 
 Concerning the zombie_timeout suggestion, here are some references when I
 posed the question of whether reducing the value would be beneficial:
 
 Amos Lattier wrote in
 http://lists.zope.org/pipermail/zope-dev/2000-April/004194.html:
  The ZServer zombie stuff is to get rid of zombie client 
  connections, not zombie publishing threads. These are quite 
  different beasts.
 
 Michel Pelletier wrote in 
 http://lists.zope.org/pipermail/zope-dev/2000-April/004229.html:
  What the Zombie timeout means is that after a publishing thread gets
  done answering a request, the socket may not go away.  This many for a a
  number of reasons, the client 'hung' and is not 'putting down the phone
  after the converstation is over' (so to speak) or network troubles may
  prevent the connection from closing properly.  This means that there is
  a 'zombie' connection laying around.  This zombie will probably end up
  going away on its own, but if not, ZServer will kill it after a period
  of time.
  
  The only reasorce laying around during the life of a Zombie is an tiny
  little unused open socket, the Mack truck of a Zope thread that served
  the request for the zombie socket does not 'hang' for that entire period
  of time, but goes on after it has completed the request to serve other
  requests.
  
  Amos is correct in that these problems are almost always at the
  Application level, and not at the ZServer level.  The fact that Pavlos
  can prevent hanging by inserting a print statement in the asyncore loop[*]
  is suspicious, but we do not have enough information yet to point
  fingers anywhere.
 
 [* references http://lists.zope.org/pipermail/zope/2000-April/023697.html]
Yeah, I saw this... like I said, I haven't gathered enough information
yet to be able to say anything that sounds like an explanation; all I
have is a vague experimental observation.

I found out about the mpstat command on Solaris, didn't know about it
before, it gives you info on thread activity and multiprocessor
behavior, so maybe I can get some more info from that.

Hmm.

--Brian Hooper

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **

[Zope-dev] BerkeleyStorage.py is broken?

2000-06-06 Thread nw_moriarty

There are many admonitions to use BerkeleyStorage.py if you don't require versions in 
a database.  However, I have tried without success to get it to work with TCS.bsddb.db 
and BerkeleyDB 2.7.7 in a stand alone application.

How ANYBODY got it to work?  

Nigel


--== Sent via Deja.com http://www.deja.com/ ==--
Before you buy.

___
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] ReiserStorage 0.01 alpha

2000-06-06 Thread Petru Paler

  Hello all,

   Attached you can find the code for a preliminary ZODB storage manager
which is designed to take adventage of the reiserfs filesystem
(http://devlinux.com/namesys). While it is usable on other filesystems
too, the performance will decrease as the number of objects in your
database increases.
   Comments:

1. This is as alpha as it can be. While it is usable to do some testing on
a spare Zope, you must be insane to even try to use this on a production
system.
2. A generic DirectoryStorage is comming soon, with the diference being
splitting files by directory (and, of course, being slower than the
reiserfs version).
3. As you can see in the source, I/O errors in critical points can corrupt
the storage.
4. It currently does not support versioning and undo. I'm working first on
getting it stable and fast, and then add these features.

Feedback is not only welcome, but wanted :)

-Petru


##
# 
# Zope Public License (ZPL) Version 1.0
# -
# 
# Copyright (c) Digital Creations.  All rights reserved.
# Copyright (c) 2000 Petru Paler ([EMAIL PROTECTED]) All rights reserved.
# 
# This license has been certified as Open Source(tm).
# 
# Redistribution and use in source and binary forms, with or without
# modification, are permitted provided that the following conditions are
# met:
# 
# 1. Redistributions in source code must retain the above copyright
#notice, this list of conditions, and the following disclaimer.
# 
# 2. Redistributions in binary form must reproduce the above copyright
#notice, this list of conditions, and the following disclaimer in
#the documentation and/or other materials provided with the
#distribution.
# 
# 3. Digital Creations requests that attribution be given to Zope
#in any manner possible. Zope includes a "Powered by Zope"
#button that is installed by default. While it is not a license
#violation to remove this button, it is requested that the
#attribution remain. A significant investment has been put
#into Zope, and this effort will continue if the Zope community
#continues to grow. This is one way to assure that growth.
# 
# 4. All advertising materials and documentation mentioning
#features derived from or use of this software must display
#the following acknowledgement:
# 
#  "This product includes software developed by Digital Creations
#  for use in the Z Object Publishing Environment
#  (http://www.zope.org/)."
# 
#In the event that the product being advertised includes an
#intact Zope distribution (with copyright and license included)
#then this clause is waived.
# 
# 5. Names associated with Zope or Digital Creations must not be used to
#endorse or promote products derived from this software without
#prior written permission from Digital Creations.
# 
# 6. Modified redistributions of any form whatsoever must retain
#the following acknowledgment:
# 
#  "This product includes software developed by Digital Creations
#  for use in the Z Object Publishing Environment
#  (http://www.zope.org/)."
# 
#Intact (re-)distributions of any official Zope release do not
#require an external acknowledgement.
# 
# 7. Modifications are encouraged but must be packaged separately as
#patches to official Zope releases.  Distributions that do not
#clearly separate the patches from the original work must be clearly
#labeled as unofficial distributions.  Modifications which do not
#carry the name Zope may be packaged in any form, as long as they
#conform to all of the clauses above.
# 
# 
# Disclaimer
# 
#   THIS SOFTWARE IS PROVIDED BY DIGITAL CREATIONS ``AS IS'' AND ANY
#   EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
#   IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
#   PURPOSE ARE DISCLAIMED.  IN NO EVENT SHALL DIGITAL CREATIONS OR ITS
#   CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
#   SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
#   LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
#   USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
#   ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
#   OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
#   OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
#   SUCH DAMAGE.
# 
# 
# This software consists of contributions made by Digital Creations and
# many individuals on behalf of Digital Creations.  Specific
# attributions are listed in the accompanying credits file.
# 
##


# To-do list:
# Critical:
#- Most I/O operations are not atomic. This means that I/O errors (and, for
#  

Re: [Zope-dev] LM and user objects

2000-06-06 Thread Bill Anderson

"Phillip J. Eby" wrote:
 
 At 04:03 PM 6/6/00 -0600, Bill Anderson wrote:
 
 I am using the deafult UserSource that comes with LM for the moment (one
 step at a time ;)
 
 LM or PTK?

LM

(Waiting for Dan's changes before trying _any_ LM with PTK ;)

 
 When I try to add through the manage interface, I get:
 Error Type: KeyError
 Error Value: _v_rack
 
 Eh?  What manage interface?  Nothing Ty or I put out has a manage interface
 to add a user.


The management interface, a sin click through Lm to UserSouorce, select
LM User object from the  select-box. Sorry, in ahurry I left off 'ment'
:/
 
 So I judge that this interface to be a no-workie.
 
 I guess so.  :)
 
 So I tried the form-method method, and I get:
 Error Type: NotFound
 Error Value: None
 
 And no help in the traceback. :(
 
 The what method?  I'm sorry, I'm completely lost.

I made a form that took an input for id , and called the newItem(id)
method.

  If you're using the
 PTK's PersistentUserSource, I don't know anything helpful to tell you,
 'cause I haven't had time to look at it yet (too busy on ZPatterns, not to
 mention non-Zope work).

Yeah, I hear you. I am finally getting the time to start doing some
heavy work with LM and PTK later this month, so I am trying to get
caught up, so to speak. figured since i knew more abot pTK than LM, that
LM would be a good thing to start with. :)

___
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] Interfaces Wiki Changes

2000-06-06 Thread Chris Withers

Hi Michel,

I've been good and documented what I learned from the docs discussion in
the interfaces wiki.

Can you check and correct as appropriate please:
http://www.zope.org/Members/michel/Projects/Interfaces/ACPermissions
http://www.zope.org/Members/michel/Projects/Interfaces/QueryObject

Also, could the case sensitivity of each of the index types
(text|keyword|field) be documented in the Wiki?

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] (no subject)

2000-06-06 Thread Chris McDonough

I was kicking the idea of making one around, but I don't think I'll have
time to do it.

There's a document on how to write a Zope database adapter by Chris
Petrilli at:

http://www.zope.org/Members/petrilli/WritingADA

Since the Python layer has been (well) done by Alex, it shouldn't be too
hard to make one if you're OK with Python.

Good luck!

 -Original Message-
 From: kyn [mailto:[EMAIL PROTECTED]]
 Sent: Wednesday, June 07, 2000 12:34 AM
 To: '[EMAIL PROTECTED]'
 Subject: [Zope-dev] (no subject)
 
 
 Hi Zope-developers,
 
 I try out Zope last week and was greatly impressed with the 
 flexiblity of the zope system.  Now, I am thinking of porting 
 my Company intranet to zope but I have one problem.  Our 
 company backend database servers (for items catelogs, leave 
 application ...etc) sits on Inprise Interbase server.   I 
 check through all the mailing list and unable to find an 
 adapter to it.
 
 Currently, I notice that Inprise has made Interbase an open 
 source database system on linux. Is there anyone looking into 
 coming out with an adapter on Interbase ?
 
 Or someone in the developing labs can give me guidelines on 
 how to write an adapter for Inprise Interbase on linux.  I 
 manage to get a copy python code that can access Interbase 
 server on linux.  Credit has to be given to Alexandra (email 
 :'[EMAIL PROTECTED]').
 
 Need advise ...
 
 
 bye ... kyn
 
 
 
 
 ___
 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 )