[z3-five] [Plone-Users] plone/zope conflict errors and <at> <at> plone attribute error
Alec Mitchell
apm13 at columbia.edu
Thu Sep 21 01:32:41 CEST 2006
On 9/19/06, Vanessa Evans <vanessa at linx.net> wrote:
>
>
> --On 19 September 2006 17:04:17 +0200 Philipp von Weitershausen
> <philipp at weitershausen.de> wrote:
>
> > Alec Mitchell wrote:
> ing I don't know.
> >>
> >> Yeah, for me it was a bad product. However, the fact that Five is
> >> automatically failing to lookup views on a post-ConflictError retry is
> >> a very very bad thing, IMO. It means that ConflictErrors, which were
> >> once relatively innocuous except in extreme cases are now guaranteed
> >> to cause an end-user visible failure. This is not at all acceptable,
> >> IMHO.
> >
> > Do we have proof that this is Five's fault, IOW, that the request is
> > *actually* missing IDefaultBrowserLayer? Or is this just an assumption?
> > Alec, is this a reasonably recent Zope 2.9 installation?
> >
> >
> > In general, the rule is that whoever creates the request also has to
> > apply the default skins. We modified the ZPublisher to do that. It could
> > be that due to the retry functionality that is invoked before
> > ConflictErrors occur, a new request w/o the default skin is created. In
> > that case the problem is within ZPublisher's retry functionality.
> >
> >
> > That's all I can say with the few information I know so far. Whoever is
> > experiencing the ConflictError should debug the problem further to check
> > where the AttributeError is actually coming from.
>
>
> I am happy to share any information with you. Unfortunately without some
> guidance I don't think I will be able to troubleshoot this meaningfully - I
> may fix it, but as someone who isn't really a Zope developer - more like a
> Zope wannabee, I'm lost on a lot of detail.
>
> Thus I've had to hire a consultant to investigate this from a Plone level
> just to make sure that it isn't something fixable from within Plone - an
> error that I've propogated.
>
> It is a real problem, It seems to happen on views for document_view,
> folder_listing, contentpanels_view. I've checked rechecked these files.
> There is no failure when working on the site with the port number and
> localhost. Sometimes the error goes away with appending a slash at the
> end, sometimes not - it requires hard refresh. I thought it was related to
> order in skin layers but it turns out that this is not the case. It goes
> through stages of failing on prefs_install and prefs_error as well as
> login_form. Apart from anything else it is a real ugly error message when
> delivered to the end user - not even delivered within Plone templating
> system. I even wondered if there was a way to 'catch it' and then force
> hard refresh.
>
> At one point I thought it may be masking a security problem but it isn't.
> If someone could help me out a bit or at least let me know what information
> may indicate the cause.....
There is now a fix in Zope 2.9/2.10/2.11 svn for the issue that was
causing ConflictErrors to result in view lookup problems (and
AttributeErrors). However, if you are seeing ConflictErrors on "read"
operations, it is a good idea to find out what is causing them.
Chances are you have something that's naughtily doing writes on read
operations. Looking at the object the conflict error triggers on will
give you a clue. It's probably some 3rd party product you have
installed.
Alec
More information about the z3-five
mailing list