Roché Compaan wrote:
snip /
I use QueueCatalog often and I know how it works. But if an application
requires immediate indexing then QueueCatalog is not a solution.
Sorry if I was unclear but what I'm really asking is if it is possible
to improve the conflict handling of the current indexes
Hi,
I have monkey-patched the QueueCatalog to adopt it to our needs, which
works fine. I now wanted to introduce a new feature:
The QueueCatalog should be bypassed during mass-import of data.
So I introduced a new variable _bypass, and new getBypassQueue() and
setBypassQueue methods in the
Summary of messages to the zope-tests list.
Period Tue Sep 18 12:00:00 2007 UTC to Wed Sep 19 12:00:00 2007 UTC.
There were 5 messages: 5 from Zope Unit Tests.
Tests passed OK
---
Subject: OK : Zope-2.7 Python-2.3.6 : Linux
From: Zope Unit Tests
Date: Tue Sep 18 20:50:14 EDT 2007
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Joachim Schmitz wrote:
Hi,
I have monkey-patched the QueueCatalog to adopt it to our needs, which
works fine. I now wanted to introduce a new feature:
The QueueCatalog should be bypassed during mass-import of data.
So I introduced a new
Tres Seaver schrieb:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
security.declareProtected(view_management_screens, 'getBypassQueue')
def getBypassQueue(self):
get _by_pass
if not hasattr(self,_bypass):
self._bypass = False
return self._bypass
I would write this
Laurence Rowe wrote at 2007-9-19 10:03 +0100:
...
Indexes are inherently difficult to perform conflict resolution on. As
Dieter mentioned their implementation is designed for efficient reading,
not efficient writing.
You did not mean me?
I have implemented the Conflict Reduced Indexes because
Joachim Schmitz wrote at 2007-9-19 11:54 +0200:
and
../portal_catalog/getBypassQueue
displays a 1
This looks like a security bug.
You should not be able to call something via the ZPublisher
what you cannot call in a script.
Maybe, you file a bug report?
--
Dieter
On Tue, 2007-09-18 at 20:01 +0200, Dieter Maurer wrote:
Roché Compaan wrote at 2007-9-18 08:55 +0200:
...
Sorry if I was unclear but what I'm really asking is if it is possible
to improve the conflict handling of the current indexes that we have in
Zope. I am also asking if concurrent
If I have an object that is represented like this:
FSPageTemplate at /atlas/maptext_view used for
/atlas/maps.mtp/environment.mtp/seaice.mtp/break-up.thm/1.mtx
How do I get to the object the template is being applied to (i.e. 1.mtx)?
Thanks :)
Jean-François Doyon
Data Dissemination Division |
Hi!
Every night my Zope server has 99% cpu usage and, sometimes, the server
stops to serve pages
There are any way to know what the Zope server is doing in real time?
I know I could look at event.log or z2.log but I would like to know the
activity in real time
Is this posible?
How can I know
On 9/19/07, Garito [EMAIL PROTECTED] wrote:
Hi!
Every night my Zope server has 99% cpu usage and, sometimes, the server
stops to serve pages
There are any way to know what the Zope server is doing in real time?
I know I could look at event.log or z2.log but I would like to know the
You might also consider turning on the trace log. I've sometimes done
troubleshooting by eyeballing that file and/or using
requestprofiler.py. This is useful if some requests are taking so
long that zope seems to hang. But DeadlockDebugger might be easier to
use.
- P
On Thu, Sep 20, 2007 at
huh
--On 19. September 2007 17:00:03 -0400 Doyon, Jean-Francois
[EMAIL PROTECTED] wrote:
If I have an object that is represented like this:
FSPageTemplate at /atlas/maptext_view used for
/atlas/maps.mtp/environment.mtp/seaice.mtp/break-up.thm/1.mtx
How do I get to the object the template
13 matches
Mail list logo