Re: [Zope] zeoctl logreopen doesn't work

[Andrew Langmead]

On Sep 13, 2006, at 4:00 AM, Gerhard Schmidt wrote:
But no new zeo.log is created and all log entries still go to the  
old file.





It looks like that wasn't implemented and just sort of stubbed out.
The method that gets called with logrotate looks like this:

def handle_sigusr2(self):
# TODO: this used to reinitialize zLOG. How do I achieve
# the same effect with Python's logging package?
# Should we restart as with SIGHUP?
log("received SIGUSR2, but it was not handled!",  
level=logging.WARNING)



___
Zope maillist  -  Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
**   No cross posts or HTML encoding!  **
(Related lists - 
http://mail.zope.org/mailman/listinfo/zope-announce

http://mail.zope.org/mailman/listinfo/zope-dev )

Re: [Zope] Resizing an Image with PIL via a Form Upload

[Andrew Langmead]

On Feb 22, 2007, at 1:29 PM, Tom Von Lahndorff wrote:


8original_image=getattr(self, original_id)
9original_file=StringIO(str(original_image.data))

[and later]

AttributeError: DSCF0004.jpg


I think your line numbers are off by one, because I'd think it is the  
getattr that would be causing the Attribute Error (at most, line "9"  
could give an attribute error for something called "data".


Zope turns file upload objects into   
ZPublisher.HTTPRequest.FileUpload instances. and pass them to your  
method. FileUpload instances have an interface similar to python file  
objects, you can .read(), .seek(), .close() or do whatever you want  
to them and might not need to wrap the contents into a StringIO  
object first. (your trying to fetch the file as an attribute of  
"self" seems to imply that you think the form data is already  
uploaded into zope and is an Image object in a folder. It isn't there  
yet, and won't be unless you store it there.)


I think if you removed lines 8 and 9 (by your numbering) and renamed  
the second argument to the method to "original_file", things would  
work as you need:


1 def makeImages(self, original_file):
2
3import PIL.Image
4import PIL
5import os.path
6
...





___
Zope maillist  -  Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
**   No cross posts or HTML encoding!  **
(Related lists - 
http://mail.zope.org/mailman/listinfo/zope-announce

http://mail.zope.org/mailman/listinfo/zope-dev )

Re: [Zope] Re: Windows compile Zope 2.8?

[Andrew Langmead]

On Apr 9, 2005, at 4:04 PM, David H wrote:
 Cannot open source file:
  
'Products/PluginIndexes/TextIndex/Splitter/ISO_8859_1_Splitter/src/ 
ISO_8859_1_Splitter.c':
    No such file or directory
 error: command '"C:\Program Files\Microsoft Visual  
Studio\VC98\BIN\cl.exe"' failed with exit status 2

 When I inspect  
'Products/PluginIndexes/TextIndex/Splitter/ISO_8859_1_Splitter/src I  
find only one file and its:
 ISO_8859_64 (no extension).

 I've been reviewing distUtils but just started so I'm unlcear about  
this stuff still.
 Any ideas?
This looks similar to an error I've seen on Unix when Zope is unpacked  
with a version of tar that only supports Unix v7 tar format and not the  
later POSIX extensions.


___
Zope maillist  -  Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
**   No cross posts or HTML encoding!  **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope-dev )

Re: [Zope] how to generate debug.log for requestprofiler

[Andrew Langmead]

On Apr 14, 2005, at 6:02 PM, Jim Abramson wrote:

At some point btn Zope 2.6.2 and 2.7.4, it seems way you set up a logfile to be used by requestprofiler.py has changed. 

Now I need "debug.log" - whats the proper way to generate one?  I've just been googling and can't find explicit instructions about this.



The log that I think of as the "debug.log" seems to now be called the "event log". Request profiler still needs the "trace log". You can enable it by putting the following stanza in your zope.conf file:


level WARN

path $INSTANCE/log/trace.log
format %(message)s



The zopectl command isn't the direct equivalent of the old z2.py. It is a wrapper around it. (the rough equivalent of z2.py is run.py, The zopectl program spawn something that spawns run.py) so command line parameters added to zopectl aren't seen by zope itself.

___
Zope maillist  -  Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
**   No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope-dev )

Re: [Zope] Problem with Zope Threads on Debain

[Andrew Langmead]

On Apr 20, 2005, at 5:43 AM, David wrote:
I do : ps -aux  . There is one zope process (user : zope) running in 
every moment :

zope 19004  0.3 11.0 171460 114380 ? S09:58   0:16 
/usr/bin/python2.3 /usr/lib/zope2.7/lib/python/Zope/Startup/run.py -C 
/var/lib/zope2.7/instance/ ...

However, there are a lot of apache process (6) running.
Do you know another way to obtain the number of zope threads running?
Apache spawns multiple processes, not threads. (that changes a bit with 
Apache 2, but lets ignore that for the moment.) Zope uses threads 
instead.

The Linux kernel, before version 2.6 had relatively primitive thread 
support, and built threads out of multiple processes with some memory 
sharing. Linux 2.6 has more advanced thread support that supports the 
pthread standard. One side effect of real pthreads is that all threads 
are really within the same process.

If you use the command and options "ps auxm", you will see displayed 
the threads within the process.

___
Zope maillist  -  Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
**   No cross posts or HTML encoding!  **
(Related lists - 
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope-dev )

Re: [Zope] Re: Zope 3 for Debian?

[Andrew Langmead]

On May 17, 2005, at 5:17 PM, Tres Seaver wrote:Perhaps I conflated two memories.  I'm pretty sure that *something* in the Zope codebase requires zlib, but I take Tim's word for it that I wrongly attributed that dependency to ZODB.At one point, our system administration staff commissioned machines in the barest of bare bones fashions, and zlib was one of the things that wasn't installed unless specifically requested. I have had also spent time building python and Zope just to have Zope complain about zlib on startup. There are at least a couple of places that I can think of on the Zope side that require zlib, the HTTP server needs it to handle  "content-encoding: gzip" responses.___
Zope maillist  -  Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
**   No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope-dev )

Re: [Zope] Re: Problem with keep-alive timeout

[Andrew Langmead]

If you really need handle an arbitrary processing time. You might  
need to separate the request submission from the processing, and the  
processing from the results display.


Roughly the way it would work would be like dropping your laundry off  
at the cleaners. You bring in the dirty clothes and then get a ticket  
back and an expected due date. You come back around the due date.  
Very likely your clothes are ready and when you present the ticket  
you receive your clean clothes. Occasionally, you get told that due  
to some sort of delay your clothes aren't ready and you are given a  
new due date.


A similar sort of thing could be done with a long running request.  
The initial request gets bundled into some sort of "job" object, and  
a Job ID is returned and a "please wait" page. That page can have a  
delayed redirect to a results page which can take a job ID, determine  
if it is complete and display the result. Meanwhile, you have an  
entirely separate process (perhaps run by the Scheduler product  
 that takes jobs, processes  
them and inserts its results.


Of course, I'm leaving off a lot of details here. Off the top of my  
head, I can think of the following issues that I'm just glossing  
over. I'm sure there are many more:  You don't want job IDs to be  
easily guessable or forgeable, or people might be able to steal each  
others laundry. You have to think about what you do when jobs get  
abandoned, (eventually the clothing racks get full) Finally, (and  
thankfully one that I don't have a laundry analogy for) you may need  
to concern yourself with the fact that the Zope user that is doing  
the job processing is different than the one doing the requesting.

___
Zope maillist  -  Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
**   No cross posts or HTML encoding!  **
(Related lists - 
http://mail.zope.org/mailman/listinfo/zope-announce

http://mail.zope.org/mailman/listinfo/zope-dev )

Re: [Zope] Re: Problem with keep-alive timeout

[Andrew Langmead]

On Jun 22, 2005, at 1:25 PM, Jonathan wrote:Set up your web page so that it has two frames: the main frame (visable) invokes the long running zope script;  and a secondary (hidden) frame uses a _javascript_ routine (running on a timer) which queries a no-op zope script. This should stop your browser from timing out.  Ugly, but it should work.I don't think it would. Those two frames would or could be two separate requests. Starting the no-op script is going to have no effect on the entirely separate long running script.When I said "would or could", it is because the exact behavior may depend on circumstances but the end result is the same. If Ralph is truly seeing HTTP 1.0 requests, then of course each connection would be independent and the completion of one request isn't going to reset the timeout for the other. In HTTP 1.1, you can combine multiple requests into a single socket connection, but I still don't think it would help. The way I've seen most browsers implement HTTP 1.1 persistent connections, A connection opened for an initial user request (when the user clicks  a link or types a new address into the menu bar.) it send requests for the subordinate elements (the "src=""no-op" request will not be responded to.___
Zope maillist  -  Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
**   No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope-dev )

Re: [Zope] External editor for ZMI

[Andrew Langmead]

On Thu, Jun 23, 2005 at 04:27:50PM +0100, John Poltorak wrote:


What alternatives are there to editing objects through ZMI?



I've often used the WebDAV support for using standard file system  
based editing tools on Zope content. How well it works depends  
greatly on the WebDAV client you have (I guess the WebDAV client  
authors would claim that it depends on the WebDAV server, but in this  
case the server is fixed as Zope) On MacOSX, it works very well. I've  
never been able to get Windows Web Folders to work successfully with  
Zope.

___
Zope maillist  -  Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
**   No cross posts or HTML encoding!  **
(Related lists - 
http://mail.zope.org/mailman/listinfo/zope-announce

http://mail.zope.org/mailman/listinfo/zope-dev )

Re: [Zope] large installations and conflict errors

[Andrew Langmead]

On Aug 8, 2005, at 10:01 AM, M. Krainer wrote:

So far our story, but what I really wonder is, if there's anyone out
there who has a similar large installation. Please let me know how
large your zope instance is and what you have done to increase your
(write) performance. Also any ideas that may help us are welcome.



We have a ZODB that packs down to about 30 gigs. The unpacked size  
grows about 10 gigs a week, which shows that there is a lot of write  
activity in our environment too. We have three Zope instances as ZEO  
clients (1.4Gig PIII, with about two gigs of RAM) A load balancer in  
front of those machines is set to favor certain URL prefixes towards  
the same machine. This someone unbalanced set up for the load  
balancer improves the chance that the ZEO client cache will have the  
appropriate object and avoid accessing the ZODB for it. (on these  
machines, the ZEO client cache is set to 2GB and a cache flip occurs  
maybe twice a week.)


Three other machines are handling purely non-interactive tasks  
(either through wget or through the Scheduler product) If possible,  
these machines are set up with a single zope thread and a large  
memory cache. (instead of the standard setup with four threads of xMB  
each, it is one thread of x*4MB.)  Not only does this help with the  
speed of a request,  but prevents each threads private object cache  
from having duplicate copies of the same object. (these machines also  
have a 2GB ZEO client cache, but flip daily)


A ZCatalog has a index that is single large Zope object, loosing it  
from cache will cause a lot of pain when you need it again. Although  
we don't use QueueCatalog, I can see the advantage of having it  
concentrate a lot of catalog work in a  single thread and transaction.


Zope's opportunistic transactions are assuming that a request will  
complete relatively quickly, and that the likelihood of two entirely  
separate requests accessing the same object is slim. I like to think  
of it as the assumption that it is hard for two lightning bolts to  
hit the same place at the same time. The two ways you can run afoul  
to this assumption is to either have one object whose modification is  
greatly favored over others, or requests taking much longer than  
average.


I've had to investigate object hotspots before, and what I've found  
useful is fsdump.py on an unpacked version of the database.


fsdump.py var/storage/var/Data.fs|sed -n  's/.*data #[0-9]*//p'|sort| 
uniq -c|sort -n


then finding particular oids that occur in the fsdump log much more  
frequently than the rest. Once you've found the hot objects, you can   
looj back through the fsdump.py log to find the transactions that  
they belong to and the URL associated with them. Once you've found  
the code paths that are all modifying the same object, then the  
changes that need to be done to make the object less hot are  
application specific.


For requests that are taking so long that they are starting to  
interfere with other requests, they might be able to be found with  
requestprofiler.py and the ZopeProfiler product. Once they are found,  
standard code optimization techniques are needed to reduce them.


That's about all I can think of writing at the moment, but if you  
have anything you want to ask me, give me a yell.

___
Zope maillist  -  Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
**   No cross posts or HTML encoding!  **
(Related lists - 
http://mail.zope.org/mailman/listinfo/zope-announce

http://mail.zope.org/mailman/listinfo/zope-dev )

Re: [Zope] large installations and conflict errors

[Andrew Langmead]

On Aug 9, 2005, at 7:01 AM, Sascha Ottolski wrote:

What we've seen so far: we used to set the cache-size to 250 MB;  
and every
know and than we have to observe that after a restart of a client a  
cache
verification is necessary (while not always obvious, why this  
happened),
which often takes "forever" (that is, 10 to 20 minutes are  
possible). And
that during such a verification, the whole system seems to be down  
(in the
sense that delivery of pages is slow as hell :-(). I think that in  
such a
case simply deleting the cache file and starting with a fresh one  
is way

faster, but have no hard numbers to prove that feeling.


In Zope 2.6, we wound up turning off persistent cache files. Having  
things be a little bit slow on one client while the cache filled up  
was preferable to the systemwide torture the re-verification of a  
cache file. Zope 2.7 and higher have a shortcut to cache  
verification, which can be adjusted with the "invalidation-queue- 
size" parameter.


Unfortunately, there are times where the ZEO client will decide to do  
a re-verification of a transient cache file (I think due to  
unexpected runtime exceptions) The best we've found to do is to  
monitor the health of the clients and the servers and when they all  
get simultaneously busy, find the client re-verifying and restart it.

___
Zope maillist  -  Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
**   No cross posts or HTML encoding!  **
(Related lists - 
http://mail.zope.org/mailman/listinfo/zope-announce

http://mail.zope.org/mailman/listinfo/zope-dev )

Re: [Zope] Startup hook

[Andrew Langmead]

On Aug 17, 2005, at 4:40 PM, Tino Wildenhain wrote:


cd Products
mkdir FancyThirtPartyStartupDieterForgotTheName
cd Fancy*
echo "import mymoduleineedtostart" >__init__.py
echo "mymoduleineedtostart.run()" >>__init__.py

maybe? ;)



A neat variation of this would be something derived from  
OFS.Folder.Folder that would iterate over each of its contained  
objects and execute them. You could then drop in whatever sort of  
python scripts, external methods, ZSQL methods, custom products,  or  
whatever you wanted to have done at startup.


___
Zope maillist  -  Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
**   No cross posts or HTML encoding!  **
(Related lists - 
http://mail.zope.org/mailman/listinfo/zope-announce

http://mail.zope.org/mailman/listinfo/zope-dev )

Re: [Zope] Zope 2.8.1 on Mac OS X tiger Server

[Andrew Langmead]

On Aug 18, 2005, at 1:19 PM, Garito wrote:


Sorry but my Mac OS X skill are null


I think you are in the unfortunate spot of of OS X where you are  
confronted with the ease of use of Unix and the ubiquity of the  
Macintosh.




I try:

sudo /System/Library/StartupItems/Zope/Zope

but raises line 31: $1: unbound variable

now I supouse $1 will be StartService/StopService/RestarService





You might want to take a look at some of Apple's documentation for  
creating its startup items, since it is significantly different than  
either the traditional Unix styles (both BSD and SysV)





Also, I would recommend against putting your startup items in /System/ 
Library/StartupItems, and suggest to use /Library/StartupItems  
instead. Everything in /System can be overwritten by OS upgrades, / 
Library is for a machine's local customizations.


What I believe you want in order to test your script is:

sudo /Library/StartupItems/Zope/Zope start


the RunService function will take the argument "start" , "stop", or  
"restart", and based on that, run either the function "StartService",  
"StopService", or "RestartService". All three functions need to  
exist, whether they are used or not.




Once you get that to succeed, you might want to try to see if this  
succeeeds:


sudo /sbin/SystemStarter  restart "Zope WebServer"

(or maybe "Zope Server", you seem to have changed it between plist  
revisions.)


___
Zope maillist  -  Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
**   No cross posts or HTML encoding!  **
(Related lists - 
http://mail.zope.org/mailman/listinfo/zope-announce

http://mail.zope.org/mailman/listinfo/zope-dev )

Re: [Zope] Zope 2.8.1 on Mac OS X tiger Server

[Andrew Langmead]

On Aug 23, 2005, at 6:24 AM, Garito wrote:

I try sudo /System/Library/StartupItems/Zope/Zope start but nothing  
happend (nor on console)


but if I launch /var/zope/sistes/bin/zopectl start it works perfectly

I try to comment the if and fi lines but don't work




I just want to make sure I point out to you, that little of this has  
to do with Zope itself, and most of the audience of this list knows  
little or cares little about the peculiarities of the MacOSX/Darwin  
init environment.



One piece of information that I now realize that I forgot to put in  
the previous message was that if you have the section "if [ "$ 
{ZOPESERVER=-NO-}" = "-YES-" ]; then" in your startup script, then  
you probably have to put a line in your /etc/hostconfig that says   
ZOPESERVER=-YES-. The bundles in /System/Library/StartupItems and / 
Library/StartupItems tell the machine how to start services and in  
what order, but the /etc/hostconfig file specifies which services are  
desired for a particular machine.


If you want to diagnose the shell script in /Library/StartupItems/ 
Zope/Zope, you might want to try to run it with the bourne shell's  
trace option, specified by the "-x" parameter.


sh -x /Library/StartupItems/Zope/Zope start


___
Zope maillist  -  Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
**   No cross posts or HTML encoding!  **
(Related lists - 
http://mail.zope.org/mailman/listinfo/zope-announce

http://mail.zope.org/mailman/listinfo/zope-dev )

Re: [Zope] question about Zope capabilities

[Andrew Langmead]

On Nov 17, 2005, at 9:38 AM, Jonathan wrote:

A less quick and less dirty solution could be to create several  
templates (each with different layouts) and serve them up at random.


Instead of at random, maybe based on certain conditions of the object  
being displayed. It may take some time to come up with the  
requirements, but would probably need to start with taking a look at  
the existing pages and figuring out what the designer wants different  
for each circumstance.


What I assumed the original poster meant was somewhat along the lines  
of looking at his site and thinking, "For an image that small,  
putting it above the headline gives too much whitespace, I wish it  
was in the right rail." or "For such a long page I wish the image was  
between the second and the third paragraph, unless the first two  
paragraphs are really short."


Depending on how much work the original poster wants to put into  
developing those rules, the templates could be created to accommodate  
his needs.

___
Zope maillist  -  Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
**   No cross posts or HTML encoding!  **
(Related lists - 
http://mail.zope.org/mailman/listinfo/zope-announce

http://mail.zope.org/mailman/listinfo/zope-dev )

Re: [Zope] Trapping zope exceptions in python script

[Andrew Langmead]

On Dec 15, 2005, at 4:01 PM, Nikko Wolf wrote:

Can you elaborate on what "strange and unpredictable behavior" you  
mean?  I'm curious in general, but especially w.r.t. the code above?


BTW, a simple grep of sources in Zope (2.7.6-final) turns up 600+  
places where a bare except is used, and my Zope instance (which  
uses Plone) contains over 350 more.


Often when you see a bare except, it is after some of the specific  
important exceptions are caught and re-raised:


try:
  something()
except ConflictError:
raise
except:
recover()


Even this is  pretty poor style anyway (If you don't know enough  
about what is going wrong to know what is being thrown, you probably  
shouldn't be in charge of recovering from it.)


The problem with catching and swallowing ConflictError and similar  
internal Zope errors is that  you leave your ZODB in an inconsistent  
state. Roughly, one request has started making modifications to the  
ZODB, then a second request has been making modifications to the same  
object. The ZODB has noticed this, and throws this  ConflictError  
exception. It is expecting this exception to bubble up all the way  
out of your code, throwing away whatever potential modifications you  
have made to the ZODB and having Zope try your code again. (at that  
point, hopefully the task that didn't get the conflict error has  
completed and committed its changes. When your code is run again, it  
will see the new values from the other transaction.


Here an (again very rough) example:

Imagine that you have two collections of objects called "unprocessed"  
and "processed". A group of somethings or someones grab the next item  
in "unprocessed", and puts it into "processed". If two requests come  
in to grab the next item from "unprocessed" and put it one of the  
other buckets, at some point. one or both of them will get the  
ConflictError exception. If the exception is swallowed by the code  
both of them will save their copy of the object in "processed", and  
where you had one object before you now have two. If these objects  
were student quizzes, two copies of the same quiz will double the  
weight of the score. If these object were loan application, the  
amount of money you were paying out has doubled. All around bad news.



___
Zope maillist  -  Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
**   No cross posts or HTML encoding!  **
(Related lists - 
http://mail.zope.org/mailman/listinfo/zope-announce

http://mail.zope.org/mailman/listinfo/zope-dev )

Re: [Zope] dealing with scripts that take too long

[Andrew Langmead]

On Jan 25, 2006, at 5:17 PM, martin f krafft wrote:



we're experiencing problems with certain maintenance scripts, which
just take too long to complete, so that the browser resets the
connection and Zope aborts the transaction.


If these are maintenance scripts that are kicked off manually by  
admins (as opposed to things that can be automated with cron) then  
maybe you can use a technique similar to one we use here.


For certain long running actions that our users need, we use the Zope  
Scheduler product. The clicks a button on a UI form, the form then  
adds the script to the schedule queue as a one shot action. The  
scheduler clock is actually running on an entirely separate Zope  
instance on a different machine, so that machines sole duty is to  
handle these async requests. The script, once completed updates its  
status, so revisiting the initial form will let the user know the  
status of their request. (we also give them a view into the schedule  
queue so if things are taking too long at least they know where they  
stand.)


The Zope server that processes the scheduler queue is set up  
differently, since it is never has to handle user input. It only has  
a single thread, and the cache size is larger than normal (the stock  
zope config is for four threads, and each thread has its own cache  
pool.)

___
Zope maillist  -  Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
**   No cross posts or HTML encoding!  **
(Related lists - 
http://mail.zope.org/mailman/listinfo/zope-announce

http://mail.zope.org/mailman/listinfo/zope-dev )

Re: [Zope] Squid & ESI

[Andrew Langmead]

On Jan 30, 2006, at 1:16 PM, Chris Withers wrote:

Perhaps you could write a short how-to describing the exact  
versions you used? Both myself and Jens had little joy with this...



I just managed to build myself an ESI enabled Squid3 with the  
following configure invocation. It is based roughly on the example on  
longsleep.org,but it removes the ssl module and adds  one critically  
needed adjustment of specifying libxml2


env CXXFLAGS="`xml2-config --cflags`"   CFLAGS="$CXXFLAGS"   
LDFLAGS="`xml2-config --libs`"  sh configure --prefix=/usr/local/ 
squid3 --enable-gnuregex -with-pthreads --enable-esi --enable- 
storeio=ufs,aufs --with-aufs-threads=10 --enable-useragent-log -- 
enable-referer-log  --enable-x-accelerator-vary --with-dl


make

sudo make install

Getting the SSL module to work seemed to require one small adjustment  
to to the source in src/client_side.cc . I'll try to get a patch to  
configure.in together so that the correct paths are recognized  
automatically.


I wasn't involved in the Squid3/ESI work done at boston.com before,  
so I don't know if there are any issues beyond the ones I resolved in  
getting things to build. 
___

Zope maillist  -  Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
**   No cross posts or HTML encoding!  **
(Related lists - 
http://mail.zope.org/mailman/listinfo/zope-announce

http://mail.zope.org/mailman/listinfo/zope-dev )

Re: [Zope] Check Zope status

[Andrew Langmead]

On Jul 11, 2006, at 9:20 AM, Jonathan Bowlas wrote:

Is there any tool we can use to test to see if Zope has actally  
crashed?


At our company, we wrote something that checks the trace.log file to  
check the status of the current zope requests. The trace.log file  
records when a new network connection is opened, when a thread starts  
processing a request, when a thread is done publishing, and when it  
has finished writing. The tool continuously re-reads the end of the  
file looking for new data records and turns those into SNMP data for  
the number of active requests, the number of queued requests, and the  
average response time.

___
Zope maillist  -  Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
**   No cross posts or HTML encoding!  **
(Related lists - 
http://mail.zope.org/mailman/listinfo/zope-announce

http://mail.zope.org/mailman/listinfo/zope-dev )

Re: POUND AND ZOPE HELL!!! was: Re: [Zope] Can't Find This Bug!

[Andrew Langmead]

On Aug 16, 2006, at 11:13 AM, Jonathan wrote:
Another idea is to have your client install ieHTTPHeaders (or  
equivalent for non-IE browsers) in their web browser and then send  
you the http header info that they are seeing.



The Mozilla equivalent is LiveHTTPHeaders livehttpheaders.mozdev.org/>


Also, Shane Hathaway's tcpwatch  is another option and can be used with any browser that  
allows the user to set an HTTP proxy. (Which essentially means  
supported by any browser.)

___
Zope maillist  -  Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
**   No cross posts or HTML encoding!  **
(Related lists - 
http://mail.zope.org/mailman/listinfo/zope-announce

http://mail.zope.org/mailman/listinfo/zope-dev )