[z3-five] [Plone-Users] plone/zope conflict errors and <at> <at> plone attribute error

[Philipp von Weitershausen]

Alec Mitchell wrote:
> On 9/19/06, Sasha Vincic <sasha.vincic at lovelysystems.com> wrote:
>>
>> On Sep 19, 2006, at 15:33, Alec Mitchell wrote:
>>
>> > On 9/19/06, Sasha Vincic <sasha.vincic at lovelysystems.com> wrote:
>> >> >>> gerry rodman <gerryrmail-pl at ...> writes:
>> >> >>>>
>> >> >>>> In about 5% of my read only operations I am getting and
>> >> >>>> attribute error
>> >> >>>> raised naming that attribute as   <at>  <at> plone.
>> >> >>>>
>> >>
>> >> The reason you get this error is due some error before. It can be an
>> >> unresolved ConflictError due some even third error or just some other
>> >> error and it's hidden as AttributeError: @@plone, please scroll back
>> >> in your event.log and try to find the errors before the ending
>> >> AttributeError: @@plone
>> >
>> > So why are conflict errors causing IDefaultBrowserLayer to not be
>> > applied to the request?  And why are conflict errors happening on read
>> > operations in zope 2.9?
>>
>> In my case it was that one of the products did some changes that had
>> to be written and sometimes they failed. So for the conflict error in
>> z2.9 (I didn't know they shouldn't appear in read only) i suspect
>> that there is a badly designed product and for IDefaultBrowserLayer
>> thing 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.