It's running and working okay, but every so often, when running it, I get: 2001-04-27T09:15:23 PANIC(300) ZODB A storage error occurred in the last phase o f a two-phase commit. This shouldn't happen. The application may be in a hosed state, so transactions will not be allowed to commit until the site/storage is r eset by a restart. Traceback (innermost last): File E:\Zope\23CF7D~1.2B2\lib\python\ZODB\Transaction.py, line 335, in commit File E:\Zope\23CF7D~1.2B2\lib\python\ZODB\Connection.py, line 657, in tpc_fini sh File E:\Zope\23CF7D~1.2B2\lib\python\ZODB\BaseStorage.py, line 219, in tpc_fin ish (Object: SessionStorage) error: release unlocked lock The relevant bit of code is: path = self.getSessionDataContainerPath() timeout_mins = self.getInternalDCTimeoutMins() onstart = self.getOnStartPath() onend = self.getOnEndPath() container = self.aq_parent ob = SessionDataManager(id, path, title, timeout_mins, onstart, onend) container.manage_delObjects(ids=[id]) container._setObject(id, ob) Any ideas? cheers, Chris
Chris Withers wrote:
It's running and working okay, but every so often, when running it, I get:
2001-04-27T09:15:23 PANIC(300) ZODB A storage error occurred in the last phase o
I stopped the above by wrapping the code as follows: get_transaction().begin()
path = self.getSessionDataContainerPath() timeout_mins = self.getInternalDCTimeoutMins() onstart = self.getOnStartPath() onend = self.getOnEndPath()
container = self.aq_parent ob = SessionDataManager(id, path, title, timeout_mins, onstart, onend) container.manage_delObjects(ids=[id]) container._setObject(id, ob)
get_transaction().note("Done '%s'" % notepath) get_transaction().commit() I wonder why it's necessary? Something to do with the weirdy mounted internal session data container? cheers, Chris
Chris Withers wrote:
Chris Withers wrote:
It's running and working okay, but every so often, when running it, I get:
2001-04-27T09:15:23 PANIC(300) ZODB A storage error occurred in the last phase o
I stopped the above by wrapping the code as follows:
Unfortunately, it still sometimes hangs on certain instances :-S No error, no crash, just stops doing what it's doing (and Zope drops right of 'top' IUKWIM) Playing with this, I noticed that Zope doesn't stop processing a request if the browser goes away. Is that a bad thing? I would have thought so if you inadvertantly set an expensive method off (like recataloging several big catalogs all in one go ;-) and then want to back out... help appreciated as always :-) Chris
Unfortunately, it still sometimes hangs on certain instances :-S No error, no crash, just stops doing what it's doing (and Zope drops right of 'top' IUKWIM)
Playing with this, I noticed that Zope doesn't stop processing a request if the browser goes away. Is that a bad thing? I would have thought so if you inadvertantly set an expensive method off (like recataloging several big catalogs all in one go ;-) and then want to back out...
This is due to the relationship between ZServer and the publisher. Sometimes it can be a bad thing... especially when there's an expensive method that folks fire off that takes a long time.. nothing comes back to their browser, so they press stop and hit the page again... etc. etc. So you have a number of threads hung. Sometimes it can be a good thing, however, such as when you want to go to Slashdot after you fire off a 'pack'. ;-)
Chris McDonough wrote:
This is due to the relationship between ZServer and the publisher. Sometimes it can be a bad thing... especially when there's an expensive method that folks fire off that takes a long time.. nothing comes back to their browser, so they press stop and hit the page again... etc. etc. So you have a number of threads hung.
Sometimes it can be a good thing, however, such as when you want to go to Slashdot after you fire off a 'pack'. ;-)
Hmmm... does make for some pretty simple and very effective DOS attacks though :-S What would it take to fix it? cheers, Chris PS: Your Slashdot viewing is easily solved; open another browser window ;-)
Hmmm... does make for some pretty simple and very effective DOS attacks though :-S
What would it take to fix it?
That depends on if you think it's broken... ;-) But to make it happen you'd need ZPublisher to support a callback from ZServer when a connection was terminated. Since I know little about either, I'm not entirely confident I can be more specific.
Chris McDonough wrote:
But to make it happen you'd need ZPublisher to support a callback from ZServer when a connection was terminated. Since I know little about either, I'm not entirely confident I can be more specific.
yeah, well, even I was impressed how high above my head that flew, so I think I'll leave it be in terms on trying to implement it. ;-) cheers, Chris
I stopped the above by wrapping the code as follows:
<snip> Cool!
I wonder why it's necessary? Something to do with the weirdy mounted internal session data container?
As Colonel Klink says so well, "I see nussing!"
Darn. No idea. If you can boil it down to an always-fails test, I can probably fix it. ----- Original Message ----- From: "Chris Withers" <chrisw@nipltd.com> To: <chrism@digicool.com> Cc: <zope-dev@zope.org> Sent: Friday, April 27, 2001 5:18 AM Subject: [Zope-dev] Waagh! More fun & games with the CST 0.8 Updater
It's running and working okay, but every so often, when running it, I get:
2001-04-27T09:15:23 PANIC(300) ZODB A storage error occurred in the last phase o f a two-phase commit. This shouldn't happen. The application may be in a hosed state, so transactions will not be allowed to commit until the site/storage is r eset by a restart. Traceback (innermost last): File E:\Zope\23CF7D~1.2B2\lib\python\ZODB\Transaction.py, line 335, in commit File E:\Zope\23CF7D~1.2B2\lib\python\ZODB\Connection.py, line 657, in tpc_fini sh File E:\Zope\23CF7D~1.2B2\lib\python\ZODB\BaseStorage.py, line 219, in tpc_fin ish (Object: SessionStorage) error: release unlocked lock
The relevant bit of code is:
path = self.getSessionDataContainerPath() timeout_mins = self.getInternalDCTimeoutMins() onstart = self.getOnStartPath() onend = self.getOnEndPath()
container = self.aq_parent ob = SessionDataManager(id, path, title, timeout_mins, onstart, onend) container.manage_delObjects(ids=[id]) container._setObject(id, ob)
Any ideas?
cheers,
Chris
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Chris McDonough wrote:
Darn. No idea. If you can boil it down to an always-fails test, I can probably fix it.
It was quicker just to go through them all by hand :-( Mindyou, I wonder if this isn't another data point on the 'WTF are those "None has no attribute load" errors' graph. Chris
participants (2)
-
Chris McDonough -
Chris Withers