Re: [Zope] Re: zope 2.8.4 on windows 98
--On 12. November 2005 16:53:43 -0800 Alexander Limi <[EMAIL PROTECTED]> wrote: On Sat, 12 Nov 2005 03:52:28 -0800, Fernando Martins <[EMAIL PROTECTED]> wrote: I understand the problem, but is it the intention that zope is not supported on win98? Yes, I believe this is intentional. Windows 98 is a seven year old OS with insufficient infrastructure to reliably run server tasks anyway. At least get Windows 2000, which has a decent kernel. Also keep in mind that Windows 98 is no longer supported by Microsoft. So there is no need for anyone especially for us to support Zope on Windows 98 in any way. However that does not mean that Zope won't run on Windows 98. For a recent project where we ship and install Zope on all customers desktop machines I had to do a lot of testing especially on Windows 98. Although doing tests on any Windows version is pain in the a** I must admit that our Zope application (which is a rather complex application with multiple storages etc.) worked nicely without major problems on Windows 98. Ok, I also have to admit I could test the application on clean virtual machines running a mostly naked Windows 98 installation...but in general as result of my testing I have to say that Zope is running stable on almost every Windows version. -aj pgpMNldno9USJ.pgp Description: PGP signature ___ 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 )
[Zope] Re: zope 2.8.4 on windows 98
Andreas Jung wrote: >> On Sat, 12 Nov 2005 03:52:28 -0800, Fernando Martins >> wrote: >> >>> I understand the problem, but is it the intention that zope is not >>> supported on win98? >> >> Yes, I believe this is intentional. Windows 98 is a seven year old OS >> with insufficient infrastructure to reliably run server tasks anyway. At >> least get Windows 2000, which has a decent kernel. >> > > However that does not mean that Zope won't run on Windows 98. For a recent > project where we ship and install Zope on all customers desktop machines I > had to do a lot of testing especially on Windows 98. I've been using zope 2.7.4 on win 98 for some development/testing, not as a real server. But I'm confused by your statement: if zope 2.8.4 is calling an NT security function, not available in win98, then it does NOT run on win98?? DO you mean there is something wrong with my win98 setup or that zope 2.8.4 could be patched to overcome this issue? Thanks, Fernando ___ 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 2.8.4 on windows 98
--On 13. November 2005 09:26:18 +0100 Fernando Martins <[EMAIL PROTECTED]> wrote: But I'm confused by your statement: if zope 2.8.4 is calling an NT security function, not available in win98, then it does NOT run on win98?? DO you mean there is something wrong with my win98 setup or that zope 2.8.4 could be patched to overcome this issue? I have no idea about internal Windows issue. For testing I was just in the position of a "dumb" Windows end-user...it just worked for me. -aj pgpcN2GsCrpXk.pgp Description: PGP signature ___ 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 )
[Zope] session variables in the presence of conflicts
Zope 2.8.4 ZEO 3.4.2 ZODB 3.4.2 Python 2.4.2 or 2.3.5 MySQL 4.0.20 MySQL-Python 1.2.0 MYSQLDA 2.0.9 We have just moved from Zope 2.7.6 to Zope 2.8.4 motivated, in part, but the ability to avoid read conflicts under ZODB 3.4.2. We have been having a lot of problems: more conflict errors, release of unreleased locks in MySQL transactions, loss of session variables, and others. We use session variables and MySQL very heavily. Our MySQL tables are MyISAM and are not transactional. ZODB3 3.4.1 introduce some changes to the conflict resolution which appears to be a logical improvement but also appears to have acerbated our problems. In the ZODB# 3.4.2 system, if a commit fails, an exception is raised and the transaction is aborted. Zope then attempts to reschedule the transaction. The abort needs to roll back MySQL transactions that are part of the conflicting ZODB and the Session Variable Store so the restart is clean. In our case, we have been using MyISAM tables, which are not transactional. The rollbacks fail and the locking in the database adapter gets confused. Changing the table type from MyISAM to Innodb, which is transactional, should resolve the MySQL problems, although it has yet to be tested. Conflict errors also arise through the session variables. Since we have a multi-Zope system configuration sharing a single ZEO, the session variables are stored in a Temporary Storage object on the ZEO host. When a conflict occurs, a number of things, none good, apparently can happen. Session variable transactions cannot be rolled back (as the temporary storage mechanism is not transactional). And, at a different level, session variable persistence requires that transactions require a copy-out/copy-in mechanism to identify those changes which have been changed and need to persisted; an aborted transaction may not be marked as persistent and so will disappear at some apparently random time in the future when the temporary store is packed and cruft removed. Some refactoring of the programming can help minimize the potential for session variable conflicts, but they cannot be eliminated. If systems stability in the face of session variable conflicts is important, 1. Does the store for session variable need to be transactional and support rollbacks? and 2. What Temporary Storage object provides the right mechanism to manage session variables with rollback efficiently? ___ 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] Sessions and Persistence
Dennis, can you try the same thing but without recreating SESSION as a
variable of REQUEST, i.e. like this instead::
# Script (Python) "setSessionVariable"
##bind container=container
##bind context=context
##bind namespace=
##bind script=script
##bind subpath=traverse_subpath
##parameters=var, val
##title=
##
request = container.REQUEST
RESPONSE = request.RESPONSE
session=request['SESSION']
session[var]=val
#request.set( 'SESSION', session )
That's how I always have been using it. Remember, type(REQUEST) !=
type({}) and the same applies for REQUEST.SESSION
On 11/12/05, Dennis Allison <[EMAIL PROTECTED]> wrote:
> Current configuration:
>Linux RH7.3
>Zope 2.8.4
>Python 2.4.2 (but the same is observed with Python 2.3.5)
>
> I continue to observe occasional failures of the Zope session variable
> mechanism. The problem manifests itself by a KeyError when accessing data
> in the session data container. We have recently moved to Zope 2.8.4 from
> Zope 2.7.6. The frequency of these errors aooears to have increased
> significantly; of late, we have occasionally seen error messages saying
> that an entire SESSION data container is missing.
>
> The session variable interface is very simple: a pair of Python Scripts,
> one that gets a session variable and another that sets it. Both use the
> copy-out/copy-in mechanism required for persistence.
>
> ## Script (Python) "getSessionVariable"
> ##bind container=container
> ##bind context=context
> ##bind namespace=
> ##bind script=script
> ##bind subpath=traverse_subpath
> ##parameters=varname
> ##title=
> ##
> request=container.REQUEST
> session=request['SESSION']
> return session[varname]
>
>
> # Script (Python) "setSessionVariable"
> ##bind container=container
> ##bind context=context
> ##bind namespace=
> ##bind script=script
> ##bind subpath=traverse_subpath
> ##parameters=var, val
> ##title=
> ##
> request = container.REQUEST
> RESPONSE = request.RESPONSE
> session=request['SESSION']
> session[var]=val
> request.set( 'SESSION', session )
>
> Most of the information we store in session variables are simple numbers
> or strings. In a few instances, we store python lists, python tuples, or
> python dictionaries.
>
> I am beginning to suspect the source of my bug is a persistence problem
> perhaps triggered by a conflict error or garbage collection in the
> temporary store used to hold the session variables.
>
> I further suspect that lists and dictionaries stored in session variables
> need to be instances of PersistentDict and PersistentList and not ordinary
> python data structures.
>
> I'd appreciate confirmation on these two issues from someone who knows the
> persistence mechanism better than I.
>
> Neither PersistentDict nor PersistentList are exposed in the restricted
> namespace. Advice as to how to expose them would be helpful as well.
>
> If I have a complex data structure (a list of dictionaries) does all the
> substructure need to have persistence wrappers as well--that is, does it
> have to be turtles all the way down?
>
> Thanks in advance. -d
>
> ___
> 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 )
>
--
Peter Bengtsson,
work www.fry-it.com
home www.peterbe.com
hobby www.issuetrackerproduct.com
___
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] session variables in the presence of conflicts
Have you considered upgrading to PostgreSQL? Things might have changed since the last time I tried mysql but I'm pretty sure Postgresql and psycopg deals much better with transactions in Zope. Admittedly, this doesn't explain why you're getting into trouble just because you've upgraded to zodb 3.4.2 On 11/13/05, Dennis Allison <[EMAIL PROTECTED]> wrote: > Zope 2.8.4 > ZEO 3.4.2 > ZODB 3.4.2 > Python 2.4.2 or 2.3.5 > MySQL 4.0.20 > MySQL-Python 1.2.0 > MYSQLDA 2.0.9 > > We have just moved from Zope 2.7.6 to Zope 2.8.4 motivated, in part, but > the ability to avoid read conflicts under ZODB3.4.2. We have been having > a lot of problems: more conflict errors, release of unreleased locks in > MySQL transactions, loss of session variables, and others. > > We use session variables and MySQL very heavily. Our MySQL tables are > MyISAM and are not transactional. > > ZODB3 3.4.1 introduce some changes to the conflict resolution which > appears to be a logical improvement but also appears to have acerbated > our problems. In the ZODB# 3.4.2 system, if a commit fails, an exception > is raised and the transaction is aborted. Zope then attempts to reschedule > the transaction. The abort needs to roll back MySQL transactions that are > part of the conflicting ZODB and the Session Variable Store so the > restart is clean. > > In our case, we have been using MyISAM tables, which are not > transactional. The rollbacks fail and the locking in the database adapter > gets confused. Changing the table type from MyISAM to Innodb, which is > transactional, should resolve the MySQL problems, although it has yet to > be tested. > > Conflict errors also arise through the session variables. Since we have a > multi-Zope system configuration sharing a single ZEO, the session > variables are stored in a Temporary Storage object on the ZEO host. When > a conflict occurs, a number of things, none good, apparently can happen. > Session variable transactions cannot be rolled back (as the temporary > storage mechanism is not transactional). And, at a different level, > session variable persistence requires that transactions require a > copy-out/copy-in mechanism to identify those changes which have been > changed and need to persisted; an aborted transaction may not be marked as > persistent and so will disappear at some apparently random time in the > future when the temporary store is packed and cruft removed. > > Some refactoring of the programming can help minimize the potential for > session variable conflicts, but they cannot be eliminated. > > If systems stability in the face of session variable conflicts is > important, > > 1. Does the store for session variable need to be transactional > and support rollbacks? > > and > > 2. What Temporary Storage object provides the right mechanism to > manage session variables with rollback efficiently? > > > > ___ > 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 ) > -- Peter Bengtsson, work www.fry-it.com home www.peterbe.com hobby www.issuetrackerproduct.com ___ 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 )
[Zope] Zope-Documentation: Args
Hi, I've found quite a lot of doc about the Zope built-in-functions. But very often I miss information about the args that can be passed to the functions, e.g. "manage_changeProperties". You find a description of the function, an example passing REQUEST, but I had to guess that you can pass a map as well. Any help? Am I blind or stupid? Probably both :) Thanks in advance Horst ___ 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-Documentation: Args
Am Sonntag, den 13.11.2005, 14:15 +0100 schrieb Horst Jäger:
> Hi,
>
> I've found quite a lot of doc about the Zope built-in-functions. But
> very often I miss information about the args that can be passed to
> the functions, e.g. "manage_changeProperties". You find a description
> of the function, an example passing REQUEST, but I had to guess that
> you can pass a map as well.
>
> Any help? Am I blind or stupid? Probably both :)
The quickest way - ideally you use ZEO for storage
and have a client running for your web access,
use another client instance like this:
--- interactive example -
./bin/zopectl debug
Starting debugger (the name "app" is bound to the top-level Zope object)
>>> help(app.manage_changeProperties)
Help on function manage_changeProperties in module OFS.PropertyManager:
manage_changeProperties(self, REQUEST=None, **kw)
Change existing object properties.
Change object properties by passing either a mapping object
of name:value pairs {'foo':6} or passing name=value parameters
--- end interactive example
while app is your zope-root and you can reach any
object via dotted notation and just try things
out before you write code.
___
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 )
[Zope] Re: Zope-Documentation: Args
Tino Wildenhain wrote:
I've found quite a lot of doc about the Zope built-in-functions. But
very often I miss information about the args that can be passed to
the functions, e.g. "manage_changeProperties". You find a description
of the function, an example passing REQUEST, but I had to guess that
you can pass a map as well.
Any help? Am I blind or stupid? Probably both :)
The quickest way - ideally you use ZEO for storage
and have a client running for your web access,
use another client instance like this:
--- interactive example -
./bin/zopectl debug
Starting debugger (the name "app" is bound to the top-level Zope object)
help(app.manage_changeProperties)
Help on function manage_changeProperties in module OFS.PropertyManager:
manage_changeProperties(self, REQUEST=None, **kw)
Change existing object properties.
Change object properties by passing either a mapping object
of name:value pairs {'foo':6} or passing name=value parameters
--- end interactive example
while app is your zope-root and you can reach any
object via dotted notation and just try things
out before you write code.
Well, except that in this case the docstring for manage_changeProperties
is badly wrong, if you pass a mapping as first argument, it will think
it's a request and render a page you'll never use as a result, which
slows it down a lot.
The proper way to call manage_changeProperties is:
manage_changeProperties(foo=6, bar='blah')
or
manage_changeProperties(**somemapping)
I've been meaning to fix Zope for years but...
Florent
--
Florent Guillaume, Nuxeo (Paris, France) Director of R&D
+33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED]
___
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-Documentation: Args
Am Sonntag, den 13.11.2005, 16:13 +0100 schrieb Florent Guillaume:
> Tino Wildenhain wrote:
> >>I've found quite a lot of doc about the Zope built-in-functions. But
> >>very often I miss information about the args that can be passed to
> >>the functions, e.g. "manage_changeProperties". You find a description
> >>of the function, an example passing REQUEST, but I had to guess that
> >>you can pass a map as well.
> >>
> >>Any help? Am I blind or stupid? Probably both :)
> >
> >
> > The quickest way - ideally you use ZEO for storage
> > and have a client running for your web access,
> > use another client instance like this:
> >
> > --- interactive example -
> >
> > ./bin/zopectl debug
> > Starting debugger (the name "app" is bound to the top-level Zope object)
> >
> help(app.manage_changeProperties)
> >
> > Help on function manage_changeProperties in module OFS.PropertyManager:
> >
> > manage_changeProperties(self, REQUEST=None, **kw)
> > Change existing object properties.
> >
> > Change object properties by passing either a mapping object
> > of name:value pairs {'foo':6} or passing name=value parameters
> >
> > --- end interactive example
> >
> >
> > while app is your zope-root and you can reach any
> > object via dotted notation and just try things
> > out before you write code.
>
> Well, except that in this case the docstring for manage_changeProperties
> is badly wrong, if you pass a mapping as first argument, it will think
> it's a request and render a page you'll never use as a result, which
> slows it down a lot.
>
> The proper way to call manage_changeProperties is:
>manage_changeProperties(foo=6, bar='blah')
> or
>manage_changeProperties(**somemapping)
>
>
> I've been meaning to fix Zope for years but...
>
Well, these are easy fixes either in the docs
(or docstrings) or in the API. Maybe if filed
as bug some starter might pick them up on next
bugday?
--Tino
___
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-Documentation: Args
On 13 Nov 2005, at 16:31, Tino Wildenhain wrote: Well, except that in this case the docstring for manage_changeProperties is badly wrong, if you pass a mapping as first argument, it will think it's a request and render a page you'll never use as a result, which slows it down a lot. The proper way to call manage_changeProperties is: manage_changeProperties(foo=6, bar='blah') or manage_changeProperties(**somemapping) I've been meaning to fix Zope for years but... Well, these are easy fixes either in the docs (or docstrings) or in the API. Maybe if filed as bug some starter might pick them up on next bugday? There's already one actually: http://www.zope.org/Collectors/Zope/878 It's really the code that should be changed, the patch in the collector (modernized a bit) would be enough. Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of R&D +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ 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 )
[Zope] Non-responsive objects reprise
Hello everyone, this is from an older thread which I'm resurrecting with more information. Despite Dieter's helpful pointers I'm no closer to solving this problem but do have more information about it in case anyone can lend a hand. To quickly recap: Periodically when visiting our zope site, certain objects appear not to respond. It's consistently the same objects from a Page Template in one folder to an image somewhere else. The site is running on Zope 2.8.1, Python 2.3.5 and sitting behind a VHM and Apache 2.0.46 using the usual ReWrite rules. This problem suddenly started several months ago with the site having been running smoothly for many months prior. This is all on Red Hat Enterprise Linux ES release 3 (Taroon Update 2). The server is a dual processor with 1GB RAM, 300GB of hard disk space, hosted by Rackspace. The site is relatively large and reasonably active. Its content is largely made up of Page Templates with a few supporting python scripts and Script (Python)'s. There are also a few ZClass-based objects that offer no real unique functionality other than providing an interface for the admins to create "News" or "Feature" items. The site also utilizes a MySQL database. I've noticed the following things about this problem: = 1) DeadlockDebugger shows no problems when one of the objects appears not to be responding. Everything appears normal. 2) I can ALWAYS successfully get to the non-responsive objects by bypassing Apache and directly viewing the Zope server's equivalent :8080 address. 3) While tailing the trace.log when an object is siezing through Apache, I can see the request come to Zope and go right back out with no problem. I think that's what this is illustrating: B -1348776468 2005-11-13T10:46:37 GET /VirtualHostBase/http/www.domain.org:80/portal/html/VirtualHostRoot/resources/contact I -1348776468 2005-11-13T10:46:37 0 A -1348776468 2005-11-13T10:46:38 200 14938 E -1348776468 2005-11-13T10:46:38 4) Turning on debugging output for Apache shows the following proxy errors when trying to access an offending object. I've searched for related information about this proxy and only found one hit from the ZODB-DEV list from 2004 with no responses. The errors: [Sat Nov 12 00:33:33 2005] [error] [client xx.xx.xx.xx] proxy: error reading status line from remote server localhost [Sat Nov 12 00:33:33 2005] [error] [client xx.xx.xx.xx] proxy: Error reading from remote server returned by /contact [Sat Nov 12 00:34:02 2005] [error] [client xx.xx.xx.xx] proxy: error reading status line from remote server localhost [Sat Nov 12 00:34:02 2005] [error] [client xx.xx.xx.xx] proxy: Error reading from remote server returned by /resources/index_html I removed the client IP. Keep #2 and #3 in mind in the context of this problem. 5) In case there was something in one of the templates that was screwing things up, I methodically removed portions of a page (or its inherited template). When the page suddenly started responding through Apache I thought I hit paydirt, but then I noticed in one instance that all I removed was a block of plain HTML (no METAL/TALES statements) and that put me back at square one. I think #2 and #3 make this point irrelevant, and certain images will get hung up, too. 6) The server is also running Mailman (using the same Python as Zope). It uses a seperate virtual host container in Apache to expose its adminstrative interface. One of my co-workers swears that when he experiences the siezing, he soon after gets several emails from one of the Mailman lists which is supposed to be a once-a-day broadcast-only list. I think this is more of a coincidence though, and I haven't gotten a big enough sample size of occurrences to rely on this report. 7) Restarting Zope *usually* corrects the problem (on Friday, restarting it (several times) didn't help) 8) Restarting Apache sometimes corrects the problem without needing to restart Zope. 9) On one occasion killing Mailman suddenly made one of the offending objects respond for a little then stop. 10) On the rare occasion we have had to physically reboot the server (like on Friday). 11) After the server was rebooted on Friday, memory usage for Zope went from about 3% to 20+% as reported by 'top' over a period of about 12 hours. I don't know whether that is indicative of a leak or just general memory consumption. Restarting Zope appears to return that memory back to the OS. This memory usage is what we normally see for this site. 12) Upgrading from Zope 2.7.6 to 2.8.1 appeared to help for a little while, but the problem either came back or never left. 13) I briefly enabled mod_disk_cache in Apache for this site in case Zope was getting too stressed out. It appeared to work wonders, but some file objects, like PDFs, would periodically be reported as corrupted by Acrobat after being downloaded. I assume this was a failure to configure mod_disk_cache appropriately, and we've since disabled it (at which
[Zope] Problem with permissions in 2.8.4
Hello,
I am having a very tough time with permissions after I have upgraded to
2.8.4 from 2.8.1, and I would really appreciate some help as I have
exhausted my imagination trying to figure what's wrong.
I have the following structure in my zope instance:
zope root
| sites
|| admin
|| website
Inside the folder admin I have some templates using a macro named "page"
in a sibling template.
The folder "sites" has some checks marked in the security tab, but this
is supposed to be ineffective since all the permissions are also
acquiring from the root folder.
The folder "admin" has the default permissions but for the "View" and
"Access Content Information", which I only made available for Managers
and some other irrelevant roles.
Pages inside admin (i.e.: "users.html") have additional security
configurations, but in all cases Managers are explicitly allowed.
The "website" folder is the virtual domain, so when I call
http://mywebsite.com/admin I am in fact acquiring the folder from above
the site root (website). However, this doesn't seem to be the problem:
the same occurs if I move admin inside website.
My user is defined in the zope root and although there's another
acl_folder in "sites" there's no user there with my same id.
The odd thing is that if I (also) check all the "Acquire permissions
settings" checkbox in admin, I will be able to access the macro but then
the macro page won't be able to access some methods
i.e."template/title_or_id". I think this should not happen, Managers are
always (explicitly!) allowed all along the path from the root to each page.
As said, this was working fine in 2.8.1.
Any help or hint would be greatly appreciated,
TIA, Pablo
PS: this is the traceback:
Request URL http://mywebsite.com/admin/users.html
Exception Type Unauthorized
Exception Value Not authorized to access binding: context
Traceback (innermost last):
* Module ZPublisher.Publish, line 113, in publish
* Module ZPublisher.mapply, line 88, in mapply
* Module ZPublisher.Publish, line 40, in call_object
* Module Shared.DC.Scripts.Bindings, line 311, in __call__
* Module Shared.DC.Scripts.Bindings, line 348, in _bindAndExec
* Module Products.PageTemplates.ZopePageTemplate, line 256, in _exec
* Module Products.PageTemplates.PageTemplate, line 104, in pt_render
* Module TAL.TALInterpreter, line 206, in __call__
* Module TAL.TALInterpreter, line 250, in interpret
* Module TAL.TALInterpreter, line 697, in do_useMacro
* Module Products.PageTemplates.TALES, line 221, in evaluate
URL: /sites/admin/users.html
Line 4, Column 0
Expression: standard:'here/template_admin.html/macros/page'
Names:
{'container': ,
'context': ,
'default': ,
'here': ,
'loop': ,
'modules': instance at 0xb7528b4c>,
'nothing': None,
'options': {'args': ()},
'repeat': ,
'request': http://mywebsite.com/admin/users.html>,
'root': ,
'template': ,
'traverse_subpath': [],
'user': pablo}
* Module Products.PageTemplates.Expressions, line 185, in __call__
* Module Products.PageTemplates.Expressions, line 173, in _eval
* Module Products.PageTemplates.Expressions, line 127, in _eval
__traceback_info__: here
* Module Products.PageTemplates.Expressions, line 284, in
restrictedTraverse
__traceback_info__: {'path': ['template_admin.html', 'macros',
'page'], 'TraversalRequestNameStack': ['page', 'macros']}
* Module Shared.DC.Scripts.Bindings, line 180, in __getattr__
* Module Shared.DC.Scripts.Bindings, line 187, in __you_lose
Unauthorized: Not authorized to access binding: context
___
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 )
[Zope] Re: Non-responsive objects reprise
You probably have a network problem, all the Zope logs show everything was completed normally (your points 1 and 3). Your problem may be tied to packet size or keepalives. A network trace, for instance using Ethereal, will probably help you more than anything. Florent Garth B. wrote: Hello everyone, this is from an older thread which I'm resurrecting with more information. Despite Dieter's helpful pointers I'm no closer to solving this problem but do have more information about it in case anyone can lend a hand. To quickly recap: Periodically when visiting our zope site, certain objects appear not to respond. It's consistently the same objects from a Page Template in one folder to an image somewhere else. The site is running on Zope 2.8.1, Python 2.3.5 and sitting behind a VHM and Apache 2.0.46 using the usual ReWrite rules. This problem suddenly started several months ago with the site having been running smoothly for many months prior. This is all on Red Hat Enterprise Linux ES release 3 (Taroon Update 2). The server is a dual processor with 1GB RAM, 300GB of hard disk space, hosted by Rackspace. The site is relatively large and reasonably active. Its content is largely made up of Page Templates with a few supporting python scripts and Script (Python)'s. There are also a few ZClass-based objects that offer no real unique functionality other than providing an interface for the admins to create "News" or "Feature" items. The site also utilizes a MySQL database. I've noticed the following things about this problem: = 1) DeadlockDebugger shows no problems when one of the objects appears not to be responding. Everything appears normal. 2) I can ALWAYS successfully get to the non-responsive objects by bypassing Apache and directly viewing the Zope server's equivalent :8080 address. 3) While tailing the trace.log when an object is siezing through Apache, I can see the request come to Zope and go right back out with no problem. I think that's what this is illustrating: B -1348776468 2005-11-13T10:46:37 GET /VirtualHostBase/http/www.domain.org:80/portal/html/VirtualHostRoot/resources/contact I -1348776468 2005-11-13T10:46:37 0 A -1348776468 2005-11-13T10:46:38 200 14938 E -1348776468 2005-11-13T10:46:38 4) Turning on debugging output for Apache shows the following proxy errors when trying to access an offending object. I've searched for related information about this proxy and only found one hit from the ZODB-DEV list from 2004 with no responses. The errors: [Sat Nov 12 00:33:33 2005] [error] [client xx.xx.xx.xx] proxy: error reading status line from remote server localhost [Sat Nov 12 00:33:33 2005] [error] [client xx.xx.xx.xx] proxy: Error reading from remote server returned by /contact [Sat Nov 12 00:34:02 2005] [error] [client xx.xx.xx.xx] proxy: error reading status line from remote server localhost [Sat Nov 12 00:34:02 2005] [error] [client xx.xx.xx.xx] proxy: Error reading from remote server returned by /resources/index_html I removed the client IP. Keep #2 and #3 in mind in the context of this problem. 5) In case there was something in one of the templates that was screwing things up, I methodically removed portions of a page (or its inherited template). When the page suddenly started responding through Apache I thought I hit paydirt, but then I noticed in one instance that all I removed was a block of plain HTML (no METAL/TALES statements) and that put me back at square one. I think #2 and #3 make this point irrelevant, and certain images will get hung up, too. 6) The server is also running Mailman (using the same Python as Zope). It uses a seperate virtual host container in Apache to expose its adminstrative interface. One of my co-workers swears that when he experiences the siezing, he soon after gets several emails from one of the Mailman lists which is supposed to be a once-a-day broadcast-only list. I think this is more of a coincidence though, and I haven't gotten a big enough sample size of occurrences to rely on this report. 7) Restarting Zope *usually* corrects the problem (on Friday, restarting it (several times) didn't help) 8) Restarting Apache sometimes corrects the problem without needing to restart Zope. 9) On one occasion killing Mailman suddenly made one of the offending objects respond for a little then stop. 10) On the rare occasion we have had to physically reboot the server (like on Friday). 11) After the server was rebooted on Friday, memory usage for Zope went from about 3% to 20+% as reported by 'top' over a period of about 12 hours. I don't know whether that is indicative of a leak or just general memory consumption. Restarting Zope appears to return that memory back to the OS. This memory usage is what we normally see for this site. 12) Upgrading from Zope 2.7.6 to 2.8.1 appeared to help for a little while, but the problem either came back or never left. 13) I briefly enabled mod_disk_cache in Apache for this site in
[Zope] Re: Problem with permissions in 2.8.4 (resolved)
Replying to my own post as I just found the answer to my problem (which
had nothing to do with the version of zope).
The problem was that when I mass-imported some folders to the new
instance, I didn't check to retain the ownership information; thus the
templates where executed whith the credentials of the Anonymous role.
Sorry for bothering, I hope someone finds this post usefull in the future,
Pablo
PS: setting the verbose-security on was of great help in order to
address this issue
Pablo Ziliani wrote:
Hello,
I am having a very tough time with permissions after I have upgraded
to 2.8.4 from 2.8.1, and I would really appreciate some help as I have
exhausted my imagination trying to figure what's wrong.
I have the following structure in my zope instance:
zope root
| sites
|| admin
|| website
Inside the folder admin I have some templates using a macro named
"page" in a sibling template.
The folder "sites" has some checks marked in the security tab, but
this is supposed to be ineffective since all the permissions are also
acquiring from the root folder.
The folder "admin" has the default permissions but for the "View" and
"Access Content Information", which I only made available for Managers
and some other irrelevant roles.
Pages inside admin (i.e.: "users.html") have additional security
configurations, but in all cases Managers are explicitly allowed.
The "website" folder is the virtual domain, so when I call
http://mywebsite.com/admin I am in fact acquiring the folder from
above the site root (website). However, this doesn't seem to be the
problem: the same occurs if I move admin inside website.
My user is defined in the zope root and although there's another
acl_folder in "sites" there's no user there with my same id.
The odd thing is that if I (also) check all the "Acquire permissions
settings" checkbox in admin, I will be able to access the macro but
then the macro page won't be able to access some methods
i.e."template/title_or_id". I think this should not happen, Managers
are always (explicitly!) allowed all along the path from the root to
each page.
As said, this was working fine in 2.8.1.
Any help or hint would be greatly appreciated,
TIA, Pablo
PS: this is the traceback:
Request URL http://mywebsite.com/admin/users.html
Exception Type Unauthorized
Exception Value Not authorized to access binding: context
Traceback (innermost last):
* Module ZPublisher.Publish, line 113, in publish
* Module ZPublisher.mapply, line 88, in mapply
* Module ZPublisher.Publish, line 40, in call_object
* Module Shared.DC.Scripts.Bindings, line 311, in __call__
* Module Shared.DC.Scripts.Bindings, line 348, in _bindAndExec
* Module Products.PageTemplates.ZopePageTemplate, line 256, in _exec
* Module Products.PageTemplates.PageTemplate, line 104, in pt_render
* Module TAL.TALInterpreter, line 206, in __call__
* Module TAL.TALInterpreter, line 250, in interpret
* Module TAL.TALInterpreter, line 697, in do_useMacro
* Module Products.PageTemplates.TALES, line 221, in evaluate
URL: /sites/admin/users.html
Line 4, Column 0
Expression: standard:'here/template_admin.html/macros/page'
Names:
{'container': ,
'context': ,
'default': ,
'here': ,
'loop': ,
'modules': instance at 0xb7528b4c>,
'nothing': None,
'options': {'args': ()},
'repeat': 0xb3ee062c>,
'request': http://mywebsite.com/admin/users.html>,
'root': ,
'template': ,
'traverse_subpath': [],
'user': pablo}
* Module Products.PageTemplates.Expressions, line 185, in __call__
* Module Products.PageTemplates.Expressions, line 173, in _eval
* Module Products.PageTemplates.Expressions, line 127, in _eval
__traceback_info__: here
* Module Products.PageTemplates.Expressions, line 284, in
restrictedTraverse
__traceback_info__: {'path': ['template_admin.html', 'macros',
'page'], 'TraversalRequestNameStack': ['page', 'macros']}
* Module Shared.DC.Scripts.Bindings, line 180, in __getattr__
* Module Shared.DC.Scripts.Bindings, line 187, in __you_lose
Unauthorized: Not authorized to access binding: context
___
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] session variables in the presence of conflicts
On Sun, 2005-11-13 at 01:39 -0800, Dennis Allison wrote: > Zope 2.8.4 > ZEO 3.4.2 > ZODB 3.4.2 > Python 2.4.2 or 2.3.5 > MySQL 4.0.20 > MySQL-Python 1.2.0 > MYSQLDA 2.0.9 > > We have just moved from Zope 2.7.6 to Zope 2.8.4 motivated, in part, but > the ability to avoid read conflicts under ZODB 3.4.2. We have been having > a lot of problems: more conflict errors, release of unreleased locks in > MySQL transactions, loss of session variables, and others. That sounds unfortunate. > We use session variables and MySQL very heavily. Our MySQL tables are > MyISAM and are not transactional. That also sounds unfortunate. ;-) > ZODB3 3.4.1 introduce some changes to the conflict resolution which ^ 3.4.2 I think you mean. > appears to be a logical improvement but also appears to have acerbated > our problems. In the ZODB# 3.4.2 system, if a commit fails, an exception > is raised and the transaction is aborted. Zope then attempts to reschedule > the transaction. The abort needs to roll back MySQL transactions that are > part of the conflicting ZODB and the Session Variable Store so the > restart is clean. Yes. Of course with MyISAM tables, this not really possible as you note below. > In our case, we have been using MyISAM tables, which are not > transactional. The rollbacks fail and the locking in the database adapter > gets confused. Changing the table type from MyISAM to Innodb, which is > transactional, should resolve the MySQL problems, although it has yet to > be tested. FWIW, InnoDB tables are a good idea in any case. But I'm suprised that a rollback which includes MyISAM tables actually causes failure. In my experience with the most recent version of Andy's MySQL database adapter, rollbacks don't actually do anything but they don't cause any failures either. This is also with a fairly recent MySQL (4.1.something). > Conflict errors also arise through the session variables. Since we have a > multi-Zope system configuration sharing a single ZEO, the session > variables are stored in a Temporary Storage object on the ZEO host. When > a conflict occurs, a number of things, none good, apparently can happen. > Session variable transactions cannot be rolled back (as the temporary > storage mechanism is not transactional). That is actually not true. The tempstorage mechanism is transactional, meaning that changes to a tempstorage will be committed or thrown out at transaction boundaries depending on the result of the participating data manager vote which determines whether a transaction should be committed or aborted. It is not undoable like FileStorage is, meaning you can't go back and selectively choose states to roll back to past the current database state, but it is indeed transactional. > And, at a different level, > session variable persistence requires that transactions require a > copy-out/copy-in mechanism to identify those changes which have been > changed and need to persisted; an aborted transaction may not be marked as > persistent and so will disappear at some apparently random time in the > future when the temporary store is packed and cruft removed. The temporary storage does not need to be packed unless there are cycles in the data. It is a "packless" storage in this regard. However, the sessioning machinery does do its own garbage collection of old data, which removes old data from the storage. But this machinery operates (logically) independently of whatever storage implementation you happen to be using to keep your session data manager. If you see session data disappear "randomly", this is a bug. However, if it can be explained by the inability of a particular transaction to commit due to bugs in participating data managers, it's not. > Some refactoring of the programming can help minimize the potential for > session variable conflicts, but they cannot be eliminated. > > If systems stability in the face of session variable conflicts is > important, > > 1. Does the store for session variable need to be transactional > and support rollbacks? It already is. > > and > > 2. What Temporary Storage object provides the right mechanism to > manage session variables with rollback efficiently? There is only one, and it is coded in such a way that it should provide this. You might need to provide some additional information about what kinds of errors you're experiencing; optimally you could provide a reproducible test case but experience has shown that with sessioning this is not always easy. Before doing much more investigation on the Zope end, you may want to get yourself to a place where you have recent versions of MySQL software and Andy's DA. - C ___ 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
