Re: [Zope-dev] KeyError: 'URL' in HTTPRequest using zope2.7-py2.3.3
Brian Watson wrote at 2005-12-1 20:55 -0500: brian w. -------------------- Traceback (most recent call last): File "E:\NBCJEAP\Zope\lib\python\zExceptions\ExceptionFormatter.py", line 157, in formatLine result.extend(self.formatSupplement(supp, tb)) File "E:\NBCJEAP\Zope\lib\python\zExceptions\ExceptionFormatter.py", line 105, in formatSupplement extra = self.formatExtraInfo(supplement) File "E:\NBCJEAP\Zope\lib\python\zExceptions\ExceptionFormatter.py", line 231, in formatExtraInfo extra = getInfo(1) File "E:\NBCJEAP\Zope\lib\python\Products\PageTemplates\TALES.py", line 277, i n getInfo ... File "E:\NBCJEAP\Zope\lib\python\ZPublisher\HTTPRequest.py", line 1295, in __r epr__ return "<%s, URL=%s>" % (self.__class__.__name__, self['URL']) File "E:\NBCJEAP\Zope\lib\python\ZPublisher\HTTPRequest.py", line 1214, in __g etitem__ raise KeyError, key KeyError: 'URL'
The "request" in your PageTemplate context lacks an "URL".
"URL" is set in the "HTTPRequest"s constructor ("__init__"). If an "HTTPRequest" instance lacks "URL" this means either:
* the instance was created in a wrong way (contructor not called)
* "URL" was deleted after construction.
Unfortunately, the details you have provided does not allow to say more about this problem. -- Dieter
thanks for your reply. theres really not all that much info to go along with the error; is there anything i could try and include? i followed the error just like you said and see where theyre init'd, but the object just seems to be empty. i can str it and get your normal zope-style table of a request only it lacks the base#/url# attributes. its __dict__ seems normal, but .other and ._urls are both empty. i'm not sure how 'URL' could have been deleted or how the httprequest could have been instantiated wrong. it doesnt happen everytime, but when i open multiple browsers and click-crazy to tax it a bit it will happen in ~1-2mins, almost when it boggs down the server a little. afterward the server runs slower for a while until it seems to catch up. my items in plone are archetype-based and do a little db. it must be something wierd in my svr versions because the exact same thing happened here: http://mail.zope.org/pipermail/zope-dev/2003-November/020952.html and sort of here where they found the problem: http://mail.zope.org/pipermail/zope-dev/2004-February/021793.html but i've scoured my code/site for any similar name issues and cannot find any. i wish the guy who posted the first issue would've at least thrown me a hint, but he got pissed when i emailed him directly to ask. thanks again for your help, and please let me know if there are any other lists i should be in (not sure if this is really zope-dev related), brian w. -- ___________________________________________________ Play 100s of games for FREE! http://games.mail.com/
Brian Watson wrote at 2005-12-4 14:33 -0500:
...
raise KeyError, key KeyError: 'URL'
The "request" in your PageTemplate context lacks an "URL".
"URL" is set in the "HTTPRequest"s constructor ("__init__"). If an "HTTPRequest" instance lacks "URL" this means either:
* the instance was created in a wrong way (contructor not called)
* "URL" was deleted after construction.
... i can str it and get your normal zope-style table of a request only it lacks the base#/url# attributes. its __dict__ seems normal, but .other and ._urls are both empty.
The "URL" (and its derivatives) is maintained in "other". Thus, if "other" is cleared (it is not protected, normal application code can do it), then "URL" will disappear. "other" (and frieds) is cleared when the request is closed. But that should only happen when the request is no longer used.
i'm not sure how 'URL' could have been deleted or how the httprequest could have been instantiated wrong. it doesnt happen everytime, but when i open multiple browsers and click-crazy to tax it a bit it will happen in ~1-2mins, almost when it boggs down the server a little.
Can you have a lock into your logfile ("event.log"). Do you see any strange exceptions at about this time, maybe "ConflictError"? Maybe the problem occurs when a request is retried in case of a "ConflictError". -- Dieter
participants (2)
-
Brian Watson -
Dieter Maurer