ConflictErrors cause "Shouldn't load state for?"

Bug #143593 reported by ChrisW
2
Affects Status Importance Assigned to Milestone
Zope 2
Invalid
Medium
Unassigned

Bug Description

Again, I'm the only one who sees these *schniff*
(and of the weirdies I've been reporting, these are the most frequent, still don't seem to cause much harm, but are a little disturbing)

------
2005-10-12T09:15:39 INFO(0) ZODB conflict error at
/VirtualHostBase/http/c_url (17 conflicts since startup at
2005-10-11T17:58:00)
------
2005-10-12T09:15:43 INFO(0) ZODB conflict error at
/VirtualHostBase/http/a_url \
(18 conflicts since startup at 2005-10-11T17:58:00)
------
2005-10-12T09:15:43 ERROR(200) ZODB Shouldn't load state for 0x9aaa86
when the connection is closed
------
2005-10-12T09:15:48 ERROR(200) ZODB Shouldn't load state for 0x9aaa86
when the connection is closed
------
2005-10-12T09:15:48 ERROR(200) ZODB Shouldn't load state for 0x660bab
when the connection is closed
------

Tags: bug database
Revision history for this message
Hanno Schlichting (hannosch) wrote :

I don't see anything in the report that suggests this is a Zope level problem and not application code.

Changed in zope2:
status: New → Incomplete
Revision history for this message
ChrisW (chris-simplistix) wrote :

Er, Hanno, while I appreciate your efforts to go through the bug tracker, please be aware that I wouldn't raise issues such as this without good reason.

How on earth could this be an "application level" problem?!

Revision history for this message
Hanno Schlichting (hannosch) wrote :

I only marked this as "incomplete" as it lacks any information that could be used to track down the problem. All cases of the "Shouldn't load state for ..." message I've seen were caused by application code. Like storing persistent objects in module scope variables, on the request or any other inappropriate places. Or sometimes by accessing persistent objects after the db connection was indeed closed, like sometimes in EndRequestEvent handlers or those request._held hooks.

Revision history for this message
ChrisW (chris-simplistix) wrote :

Yes, none of the above were being done in any code we had written...

Please can you change to a status other than incomplete so that this bug doesn't become expired?

Revision history for this message
Tres Seaver (tseaver) wrote : Re: [zope2-tracker] [Bug 143593] Re: ConflictErrors cause "Shouldn't load state for?"

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

ChrisW wrote:
> Yes, none of the above were being done in any code we had written...
>
> Please can you change to a status other than incomplete so that this bug
> doesn't become expired?

"Incomplete" means "we don't have enough information to reproduce or
diagnose the bug", which is pretty accurate AFAICT.

Tres.
- --
===================================================================
Tres Seaver +1 540-429-0999 <email address hidden>
Palladion Software "Excellence by Design" http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAku64t0ACgkQ+gerLs4ltQ5CawCfRnO4ntU+A0DNuZQPWqkIBfpK
WhMAoIkMrI4c6Suo2zipGNURkUFVriTG
=mGMa
-----END PGP SIGNATURE-----

Revision history for this message
ChrisW (chris-simplistix) wrote :

Tres Seaver wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> ChrisW wrote:
>> Yes, none of the above were being done in any code we had written...
>>
>> Please can you change to a status other than incomplete so that this bug
>> doesn't become expired?
>
> "Incomplete" means "we don't have enough information to reproduce or
> diagnose the bug", which is pretty accurate AFAICT.

Yeah, it's just annoying that, on Launchpad, that status also implies
'we will shortly delete your issue'...

Revision history for this message
Tres Seaver (tseaver) wrote : Re: [zope2-tracker] [Bug 143593] Re: ConflictErrors cause "Shouldn't load state for?"

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

ChrisW wrote:
> Tres Seaver wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> ChrisW wrote:
>>> Yes, none of the above were being done in any code we had written...
>>>
>>> Please can you change to a status other than incomplete so that this bug
>>> doesn't become expired?
>> "Incomplete" means "we don't have enough information to reproduce or
>> diagnose the bug", which is pretty accurate AFAICT.
>
> Yeah, it's just annoying that, on Launchpad, that status also implies
> 'we will shortly delete your issue'...

We do have ancient-but-incomplete bugs for Zope2:

https://bugs.launchpad.net/zope2/+bugs?field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE

Tres.
- --
===================================================================
Tres Seaver +1 540-429-0999 <email address hidden>
Palladion Software "Excellence by Design" http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAku7Ss8ACgkQ+gerLs4ltQ7LoQCfZG/jsXL7dMBa3apQ9Mo9vPcd
IPAAnigaztYhWb/YAyZAaFbcg8ApI8/A
=uA69
-----END PGP SIGNATURE-----

Revision history for this message
ChrisW (chris-simplistix) wrote :

Tres Seaver wrote:
>> Yeah, it's just annoying that, on Launchpad, that status also implies
>> 'we will shortly delete your issue'...
>
> We do have ancient-but-incomplete bugs for Zope2:
>
> https://bugs.launchpad.net/zope2/+bugs?field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE

Maybe they're in a different state?

I'm basing my comment on the note at the top of this issue in the web
interface:

"This bug report will be marked for expiration in 58 days if no further
activity occurs."

cheers,

Chris

--
Simplistix - Content Management, Batch Processing & Python Consulting
            - http://www.simplistix.co.uk

Revision history for this message
Lennart Regebro (regebro-gmail) wrote : Re: [zope2-tracker] [Bug 143593] Re: ConflictErrors cause "Shouldn't load state for?"

On Thu, Apr 8, 2010 at 10:20, ChrisW <email address hidden> wrote:
> "This bug report will be marked for expiration in 58 days if no further
> activity occurs."

Sounds fair to me. More info on how to reproduce the bug should be
forthcoming withing 58 days then, we hope? :-)
--
Lennart Regebro: Python, Zope, Plone, Grok
http://regebro.wordpress.com/
+33 661 58 14 64

Revision history for this message
ChrisW (chris-simplistix) wrote : Re: [zope2-tracker] [Bug 143593] Re: ConflictErrors cause "Shouldn't load state for?"

Lennart Regebro wrote:
> On Thu, Apr 8, 2010 at 10:20, ChrisW <email address hidden> wrote:
>> "This bug report will be marked for expiration in 58 days if no further
>> activity occurs."
>
> Sounds fair to me. More info on how to reproduce the bug should be
> forthcoming withing 58 days then, we hope? :-)

Actually, no. This was a hard-to-reproduce error that only occurred
under high load.

Closing it off will just mean that we start the process again, rather
than having this issue open and available as a container for the error
reports...

Chris

--
Simplistix - Content Management, Batch Processing & Python Consulting
             - http://www.simplistix.co.uk

Revision history for this message
Lennart Regebro (regebro-gmail) wrote : Re: [zope2-tracker] [Bug 143593] Re: ConflictErrors cause "Shouldn't load state for?"

On Thu, Apr 8, 2010 at 10:56, ChrisW <email address hidden> wrote:
> Actually, no. This was a hard-to-reproduce error that only occurred
> under high load.
>
> Closing it off will just mean that we start the process again, rather
> than having this issue open and available as a container for the error
> reports...

Can we have a state for "weird errors that can't be reproduced but
needs to be kept here for future reference"? I can see the use of
that, so we can keep track of whom it happens too and how often.

--
Lennart Regebro: Python, Zope, Plone, Grok
http://regebro.wordpress.com/
+33 661 58 14 64

Revision history for this message
Tres Seaver (tseaver) wrote : Re: [zope2-tracker] [Bug 143593] Re: ConflictErrors cause "Shouldn't load state for?"

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Lennart Regebro wrote:
> On Thu, Apr 8, 2010 at 10:56, ChrisW <email address hidden> wrote:
>> Actually, no. This was a hard-to-reproduce error that only occurred
>> under high load.
>>
>> Closing it off will just mean that we start the process again, rather
>> than having this issue open and available as a container for the error
>> reports...
>
> Can we have a state for "weird errors that can't be reproduced but
> needs to be kept here for future reference"? I can see the use of
> that, so we can keep track of whom it happens too and how often.

The "triaged" state used by some projects on Launchpad is probably the
right fit, especially if we add a "weird-keep-for-future-reference" tag
as well.

Tres.
- --
===================================================================
Tres Seaver +1 540-429-0999 <email address hidden>
Palladion Software "Excellence by Design" http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkvAbpsACgkQ+gerLs4ltQ7xGgCfbXLrtj7EpanfrFMGC4QtQM4O
V5AAn0bWX00z6/2+2wNyMfWe8k2YI9xR
=dnRU
-----END PGP SIGNATURE-----

Revision history for this message
ChrisW (chris-simplistix) wrote :

Tres Seaver wrote:
> The "triaged" state used by some projects on Launchpad is probably the
> right fit, especially if we add a "weird-keep-for-future-reference" tag
> as well.

Good, lets got for that. Hopefully this issue can get into that state
before the gods of launchpad eat it ;-)

Chris

--
Simplistix - Content Management, Batch Processing & Python Consulting
             - http://www.simplistix.co.uk

Tres Seaver (tseaver)
Changed in zope2:
status: Incomplete → Triaged
Revision history for this message
khink (kees-fmf) wrote :
Download full text (4.2 KiB)

We frequently see these errors on our (Plone 4.2.5-based) site. I'm posting the latest one below. Please let me know if there is anything i can do to help.

1373455510.460.208596855217 http://www.freitag.de/autoren/der-freitag/anders-ist-moeglich/view
Traceback (innermost last):
  Module ZPublisher.Publish, line 60, in publish
  Module ZPublisher.mapply, line 77, in mapply
  Module ZPublisher.Publish, line 46, in call_object
  Module Products.Five.browser.metaconfigure, line 476, in __call__
  Module Products.Five.browser.pagetemplatefile, line 125, in __call__
  Module Products.Five.browser.pagetemplatefile, line 59, in __call__
  Module zope.pagetemplate.pagetemplate, line 132, in pt_render
  Module five.pt.engine, line 93, in __call__
  Module z3c.pt.pagetemplate, line 149, in render
  Module chameleon.zpt.template, line 257, in render
  Module chameleon.template, line 172, in render
  Module 188bdcb17a4cb1826f85386acb0b467337d38fe0.py, line 795, in render
  Module 1486c9887907e699789c256205144787bc0fb6df.py, line 1184, in render_master
  Module z3c.pt.expressions, line 61, in render_content_provider
  Module plone.app.viewletmanager.manager, line 155, in render
  Module plone.app.viewletmanager.manager, line 86, in render
  Module plone.app.layout.viewlets.common, line 50, in render
  Module Products.Five.browser.pagetemplatefile, line 125, in __call__
  Module Products.Five.browser.pagetemplatefile, line 59, in __call__
  Module zope.pagetemplate.pagetemplate, line 132, in pt_render
  Module five.pt.engine, line 93, in __call__
  Module z3c.pt.pagetemplate, line 149, in render
  Module chameleon.zpt.template, line 257, in render
  Module chameleon.template, line 190, in render
  Module chameleon.template, line 172, in render
  Module 1b5d719a7cf8b150468861e3c9f8f9f13ce418ad.py, line 94, in render
  Module five.pt.expressions, line 161, in __call__
  Module freitag.util.layout.viewlets.workflow, line 21, in display
  Module freitag.util.layout.viewlets.workflow, line 12, in transitions
  Module Products.CMFPlone.WorkflowTool, line 88, in getTransitionsFor
  Module Products.DCWorkflow.DCWorkflow, line 133, in _getWorkflowStateOf
  Module Products.CMFCore.WorkflowTool, line 331, in getStatusOf
  Module Products.CMFCore.WorkflowTool, line 324, in getHistoryOf
  Module ZODB.Connection, line 857, in setstate
ConnectionStateError: Shouldn't load state for 0x3defc7 when the connection is closed

 - Expression: "provider:freitag.util.layout.toolbar_local"
 - Filename: ... /layout/skins/freitag_util_layout_layer/main_template.pt
 - Location: (61:47)
 - Source: ... ="structure provider:freitag.util.layout.toolbar_local" />
                               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 - Expression: "view/display"
 - Filename: ... -1.14-py2.7.egg/freitag/util/layout/viewlets/workflow.pt
 - Location: (2:20)
 - Source: tal:condition="view/display"
                              ^^^^^^^^^^^^
 - Arguments: repeat: {...} (0)
               template: <ViewPageTemplateFile - at 0x7f9ad2a6fc10>
               views: <ViewMapper - at 0x7f9abae70f90>
               modules: <instance - at 0x1f6edd0>
               args: <tuple - at...

Read more...

Revision history for this message
Colin Watson (cjwatson) wrote :

The zope2 project on Launchpad has been archived at the request of the Zope developers (see https://answers.launchpad.net/launchpad/+question/683589 and https://answers.launchpad.net/launchpad/+question/685285). If this bug is still relevant, please refile it at https://github.com/zopefoundation/zope2.

Changed in zope2:
status: Triaged → Invalid
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.