From: SourceForge.net <no...@so...> - 2003-01-31 14:03:18
|
Patches item #678129, was opened at 2003-01-31 16:08 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=304866&aid=678129&group_id=4866 Category: WebKit Group: None Status: Open Resolution: None Priority: 5 Submitted By: Oleg Noga (oleg_noga) Assigned to: Nobody/Anonymous (nobody) Summary: Report original exception for session unpickle error Initial Comment: The purpose of this patch is to provide the original session unpickle exception instead of KeyError exception. --- Since we have no corrupted sessions on the disk, the Session KeyError is still appears. KeyError appears if SessionFileStore can't unpickle session while loading it from disk. Session can't be unpickled only if it has objects, with have buggy implemented unpickling feature. Developer, who works under webkit, would like to fix unpickling for his session. So, match better for developer to see the original exception instead of KeyError. --- This patch was made on Webware0.8b1. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=304866&aid=678129&group_id=4866 |
From: SourceForge.net <no...@so...> - 2003-01-31 14:07:36
|
Patches item #678129, was opened at 2003-01-31 16:08 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=304866&aid=678129&group_id=4866 Category: WebKit Group: None Status: Open Resolution: None Priority: 5 Submitted By: Oleg Noga (oleg_noga) >Assigned to: Stuart Donaldson (stuartd) Summary: Report original exception for session unpickle error Initial Comment: The purpose of this patch is to provide the original session unpickle exception instead of KeyError exception. --- Since we have no corrupted sessions on the disk, the Session KeyError is still appears. KeyError appears if SessionFileStore can't unpickle session while loading it from disk. Session can't be unpickled only if it has objects, with have buggy implemented unpickling feature. Developer, who works under webkit, would like to fix unpickling for his session. So, match better for developer to see the original exception instead of KeyError. --- This patch was made on Webware0.8b1. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=304866&aid=678129&group_id=4866 |
From: SourceForge.net <no...@so...> - 2003-02-04 18:10:59
|
Patches item #678129, was opened at 2003-01-31 09:08 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=304866&aid=678129&group_id=4866 Category: WebKit Group: None Status: Open Resolution: None Priority: 5 Submitted By: Oleg Noga (oleg_noga) Assigned to: Stuart Donaldson (stuartd) Summary: Report original exception for session unpickle error Initial Comment: The purpose of this patch is to provide the original session unpickle exception instead of KeyError exception. --- Since we have no corrupted sessions on the disk, the Session KeyError is still appears. KeyError appears if SessionFileStore can't unpickle session while loading it from disk. Session can't be unpickled only if it has objects, with have buggy implemented unpickling feature. Developer, who works under webkit, would like to fix unpickling for his session. So, match better for developer to see the original exception instead of KeyError. --- This patch was made on Webware0.8b1. ---------------------------------------------------------------------- >Comment By: Geoff Talvola (gtalvola) Date: 2003-02-04 13:16 Message: Logged In: YES user_id=88162 Wouldn't this part of the patch be easier if we just said "raise"? raise with no arguments re-raises the latest exception. There's no need to rebuild it from sys.exc_info(). + e = sys.exc_info() + raise e[0], e[1], e[2] # raise the exception again, so developers can look on it ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=304866&aid=678129&group_id=4866 |
From: SourceForge.net <no...@so...> - 2003-02-04 18:13:10
|
Patches item #678129, was opened at 2003-01-31 09:08 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=304866&aid=678129&group_id=4866 Category: WebKit Group: None Status: Open Resolution: None Priority: 5 Submitted By: Oleg Noga (oleg_noga) Assigned to: Stuart Donaldson (stuartd) Summary: Report original exception for session unpickle error Initial Comment: The purpose of this patch is to provide the original session unpickle exception instead of KeyError exception. --- Since we have no corrupted sessions on the disk, the Session KeyError is still appears. KeyError appears if SessionFileStore can't unpickle session while loading it from disk. Session can't be unpickled only if it has objects, with have buggy implemented unpickling feature. Developer, who works under webkit, would like to fix unpickling for his session. So, match better for developer to see the original exception instead of KeyError. --- This patch was made on Webware0.8b1. ---------------------------------------------------------------------- >Comment By: Geoff Talvola (gtalvola) Date: 2003-02-04 13:19 Message: Logged In: YES user_id=88162 I'm not sure it's a good idea to re-raise the unpickling exception here. It may be better to _print_ the unpickling exception and possibly email it to the administrator, but still raise KeyError so that the application can treat this as a missing session and possibly recover more gracefully. ---------------------------------------------------------------------- Comment By: Geoff Talvola (gtalvola) Date: 2003-02-04 13:16 Message: Logged In: YES user_id=88162 Wouldn't this part of the patch be easier if we just said "raise"? raise with no arguments re-raises the latest exception. There's no need to rebuild it from sys.exc_info(). + e = sys.exc_info() + raise e[0], e[1], e[2] # raise the exception again, so developers can look on it ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=304866&aid=678129&group_id=4866 |
From: SourceForge.net <no...@so...> - 2003-02-04 22:05:58
|
Patches item #678129, was opened at 2003-01-31 16:08 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=304866&aid=678129&group_id=4866 Category: WebKit Group: None Status: Open Resolution: None Priority: 5 Submitted By: Oleg Noga (oleg_noga) Assigned to: Stuart Donaldson (stuartd) Summary: Report original exception for session unpickle error Initial Comment: The purpose of this patch is to provide the original session unpickle exception instead of KeyError exception. --- Since we have no corrupted sessions on the disk, the Session KeyError is still appears. KeyError appears if SessionFileStore can't unpickle session while loading it from disk. Session can't be unpickled only if it has objects, with have buggy implemented unpickling feature. Developer, who works under webkit, would like to fix unpickling for his session. So, match better for developer to see the original exception instead of KeyError. --- This patch was made on Webware0.8b1. ---------------------------------------------------------------------- >Comment By: Oleg Noga (oleg_noga) Date: 2003-02-05 00:11 Message: Logged In: YES user_id=551440 Here is KeyError traceback: Traceback (most recent call last): File ".\WebKit\Application.py", line 368, in dispatchRequest elif self.isSessionIdProblematic(request): File ".\WebKit\Application.py", line 466, in isSessionIdProblematic if (time()-request.session().lastAccessTime()) >= request.session().timeout(): File ".\WebKit\HTTPRequest.py", line 225, in session return self._transaction.session() File ".\WebKit\Transaction.py", line 67, in session self._session = self._application.createSessionForTransaction(self) File ".\WebKit\Application.py", line 889, in createSessionForTransaction session = self.session(sessId) File ".\WebKit\Application.py", line 725, in session return self._sessions[sessionId] File ".\WebKit\SessionDynamicStore.py", line 72, in __getitem__ self.MovetoMemory(key) File ".\WebKit\SessionDynamicStore.py", line 135, in MovetoMemory self._memoryStore[key] = self._fileStore[key] File ".\WebKit\SessionFileStore.py", line 55, in __getitem__ raise KeyError, key KeyError: 20030204232946- b46a22352890568b1a899c361d816933 Seems that KeyError have thrown out of awake-respond-sleep cycle (before it), so servlet can’t perform any gracefull recoveries. Maybe application must recover the same way as when session can’t be pickled? To remove unpickable session file, to create new session, and not to throw any exception at all? Any way, it usefull to see original exception report – in console/log, or in http exception report. --- I have raised exception like “raise e[0], e[1], e[2]” just to preserve original traceback. If original traceback has no helpful information, we can simple “raise <original exception instance>” The simplest patch is to remove try/except at all :) ---------------------------------------------------------------------- Comment By: Geoff Talvola (gtalvola) Date: 2003-02-04 20:19 Message: Logged In: YES user_id=88162 I'm not sure it's a good idea to re-raise the unpickling exception here. It may be better to _print_ the unpickling exception and possibly email it to the administrator, but still raise KeyError so that the application can treat this as a missing session and possibly recover more gracefully. ---------------------------------------------------------------------- Comment By: Geoff Talvola (gtalvola) Date: 2003-02-04 20:16 Message: Logged In: YES user_id=88162 Wouldn't this part of the patch be easier if we just said "raise"? raise with no arguments re-raises the latest exception. There's no need to rebuild it from sys.exc_info(). + e = sys.exc_info() + raise e[0], e[1], e[2] # raise the exception again, so developers can look on it ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=304866&aid=678129&group_id=4866 |
From: SourceForge.net <no...@so...> - 2003-02-05 07:59:42
|
Patches item #678129, was opened at 2003-01-31 06:08 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=304866&aid=678129&group_id=4866 Category: WebKit Group: None Status: Open Resolution: None Priority: 5 Submitted By: Oleg Noga (oleg_noga) Assigned to: Stuart Donaldson (stuartd) Summary: Report original exception for session unpickle error Initial Comment: The purpose of this patch is to provide the original session unpickle exception instead of KeyError exception. --- Since we have no corrupted sessions on the disk, the Session KeyError is still appears. KeyError appears if SessionFileStore can't unpickle session while loading it from disk. Session can't be unpickled only if it has objects, with have buggy implemented unpickling feature. Developer, who works under webkit, would like to fix unpickling for his session. So, match better for developer to see the original exception instead of KeyError. --- This patch was made on Webware0.8b1. ---------------------------------------------------------------------- >Comment By: Stuart Donaldson (stuartd) Date: 2003-02-05 00:05 Message: Logged In: YES user_id=326269 The original traceback is preserved if you just do "raise" without any arguments. It just re-raises the existing exception along with existing traceback information. From a consistency point of view, raising a KeyError for problems retrieving a session seems to be pretty common. While I think this specific case is not caught, there are other cases where a session stores __getitem__ throws a KeyError that does get caught. From a users point of view, shouldn't this just appear as a missing session file? From a developers view, you would want to see what the unpickling error was. If these two assumptions are correct, then perhaps a solution like this: - catch KeyError in Application.createSessionForTransaction, and treat it like there was no session. - have the decoding exception raise a key error as it does now, but also print out a the stack trace for a developer, possibly calling handleException() to log the exceptino as well. ---------------------------------------------------------------------- Comment By: Oleg Noga (oleg_noga) Date: 2003-02-04 14:11 Message: Logged In: YES user_id=551440 Here is KeyError traceback: Traceback (most recent call last): File ".\WebKit\Application.py", line 368, in dispatchRequest elif self.isSessionIdProblematic(request): File ".\WebKit\Application.py", line 466, in isSessionIdProblematic if (time()-request.session().lastAccessTime()) >= request.session().timeout(): File ".\WebKit\HTTPRequest.py", line 225, in session return self._transaction.session() File ".\WebKit\Transaction.py", line 67, in session self._session = self._application.createSessionForTransaction(self) File ".\WebKit\Application.py", line 889, in createSessionForTransaction session = self.session(sessId) File ".\WebKit\Application.py", line 725, in session return self._sessions[sessionId] File ".\WebKit\SessionDynamicStore.py", line 72, in __getitem__ self.MovetoMemory(key) File ".\WebKit\SessionDynamicStore.py", line 135, in MovetoMemory self._memoryStore[key] = self._fileStore[key] File ".\WebKit\SessionFileStore.py", line 55, in __getitem__ raise KeyError, key KeyError: 20030204232946- b46a22352890568b1a899c361d816933 Seems that KeyError have thrown out of awake-respond-sleep cycle (before it), so servlet can’t perform any gracefull recoveries. Maybe application must recover the same way as when session can’t be pickled? To remove unpickable session file, to create new session, and not to throw any exception at all? Any way, it usefull to see original exception report – in console/log, or in http exception report. --- I have raised exception like “raise e[0], e[1], e[2]” just to preserve original traceback. If original traceback has no helpful information, we can simple “raise <original exception instance>” The simplest patch is to remove try/except at all :) ---------------------------------------------------------------------- Comment By: Geoff Talvola (gtalvola) Date: 2003-02-04 10:19 Message: Logged In: YES user_id=88162 I'm not sure it's a good idea to re-raise the unpickling exception here. It may be better to _print_ the unpickling exception and possibly email it to the administrator, but still raise KeyError so that the application can treat this as a missing session and possibly recover more gracefully. ---------------------------------------------------------------------- Comment By: Geoff Talvola (gtalvola) Date: 2003-02-04 10:16 Message: Logged In: YES user_id=88162 Wouldn't this part of the patch be easier if we just said "raise"? raise with no arguments re-raises the latest exception. There's no need to rebuild it from sys.exc_info(). + e = sys.exc_info() + raise e[0], e[1], e[2] # raise the exception again, so developers can look on it ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=304866&aid=678129&group_id=4866 |
From: SourceForge.net <no...@so...> - 2003-02-05 12:47:50
|
Patches item #678129, was opened at 2003-01-31 16:08 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=304866&aid=678129&group_id=4866 Category: WebKit Group: None Status: Open Resolution: None Priority: 5 Submitted By: Oleg Noga (oleg_noga) Assigned to: Stuart Donaldson (stuartd) Summary: Report original exception for session unpickle error Initial Comment: The purpose of this patch is to provide the original session unpickle exception instead of KeyError exception. --- Since we have no corrupted sessions on the disk, the Session KeyError is still appears. KeyError appears if SessionFileStore can't unpickle session while loading it from disk. Session can't be unpickled only if it has objects, with have buggy implemented unpickling feature. Developer, who works under webkit, would like to fix unpickling for his session. So, match better for developer to see the original exception instead of KeyError. --- This patch was made on Webware0.8b1. ---------------------------------------------------------------------- >Comment By: Oleg Noga (oleg_noga) Date: 2003-02-05 14:53 Message: Logged In: YES user_id=551440 So I've produced patches: for Application: Application.diff for SessionfileStore.diff in SessionFileStore.__getitem__: * close session file finally (seems like bug fix) in case of session unpicling error: 1. remove session file 2. call Application.handleException() 3. raise KeyError in Application.createSessionForTransaction: 1. catch KeyError 2. create new session if it was not loaded from store ---------------------------------------------------------------------- Comment By: Stuart Donaldson (stuartd) Date: 2003-02-05 10:05 Message: Logged In: YES user_id=326269 The original traceback is preserved if you just do "raise" without any arguments. It just re-raises the existing exception along with existing traceback information. From a consistency point of view, raising a KeyError for problems retrieving a session seems to be pretty common. While I think this specific case is not caught, there are other cases where a session stores __getitem__ throws a KeyError that does get caught. From a users point of view, shouldn't this just appear as a missing session file? From a developers view, you would want to see what the unpickling error was. If these two assumptions are correct, then perhaps a solution like this: - catch KeyError in Application.createSessionForTransaction, and treat it like there was no session. - have the decoding exception raise a key error as it does now, but also print out a the stack trace for a developer, possibly calling handleException() to log the exceptino as well. ---------------------------------------------------------------------- Comment By: Oleg Noga (oleg_noga) Date: 2003-02-05 00:11 Message: Logged In: YES user_id=551440 Here is KeyError traceback: Traceback (most recent call last): File ".\WebKit\Application.py", line 368, in dispatchRequest elif self.isSessionIdProblematic(request): File ".\WebKit\Application.py", line 466, in isSessionIdProblematic if (time()-request.session().lastAccessTime()) >= request.session().timeout(): File ".\WebKit\HTTPRequest.py", line 225, in session return self._transaction.session() File ".\WebKit\Transaction.py", line 67, in session self._session = self._application.createSessionForTransaction(self) File ".\WebKit\Application.py", line 889, in createSessionForTransaction session = self.session(sessId) File ".\WebKit\Application.py", line 725, in session return self._sessions[sessionId] File ".\WebKit\SessionDynamicStore.py", line 72, in __getitem__ self.MovetoMemory(key) File ".\WebKit\SessionDynamicStore.py", line 135, in MovetoMemory self._memoryStore[key] = self._fileStore[key] File ".\WebKit\SessionFileStore.py", line 55, in __getitem__ raise KeyError, key KeyError: 20030204232946- b46a22352890568b1a899c361d816933 Seems that KeyError have thrown out of awake-respond-sleep cycle (before it), so servlet can’t perform any gracefull recoveries. Maybe application must recover the same way as when session can’t be pickled? To remove unpickable session file, to create new session, and not to throw any exception at all? Any way, it usefull to see original exception report – in console/log, or in http exception report. --- I have raised exception like “raise e[0], e[1], e[2]” just to preserve original traceback. If original traceback has no helpful information, we can simple “raise <original exception instance>” The simplest patch is to remove try/except at all :) ---------------------------------------------------------------------- Comment By: Geoff Talvola (gtalvola) Date: 2003-02-04 20:19 Message: Logged In: YES user_id=88162 I'm not sure it's a good idea to re-raise the unpickling exception here. It may be better to _print_ the unpickling exception and possibly email it to the administrator, but still raise KeyError so that the application can treat this as a missing session and possibly recover more gracefully. ---------------------------------------------------------------------- Comment By: Geoff Talvola (gtalvola) Date: 2003-02-04 20:16 Message: Logged In: YES user_id=88162 Wouldn't this part of the patch be easier if we just said "raise"? raise with no arguments re-raises the latest exception. There's no need to rebuild it from sys.exc_info(). + e = sys.exc_info() + raise e[0], e[1], e[2] # raise the exception again, so developers can look on it ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=304866&aid=678129&group_id=4866 |
From: SourceForge.net <no...@so...> - 2003-02-14 10:18:32
|
Patches item #678129, was opened at 2003-01-31 06:08 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=304866&aid=678129&group_id=4866 Category: WebKit Group: None Status: Open Resolution: None Priority: 5 Submitted By: Oleg Noga (oleg_noga) Assigned to: Stuart Donaldson (stuartd) Summary: Report original exception for session unpickle error Initial Comment: The purpose of this patch is to provide the original session unpickle exception instead of KeyError exception. --- Since we have no corrupted sessions on the disk, the Session KeyError is still appears. KeyError appears if SessionFileStore can't unpickle session while loading it from disk. Session can't be unpickled only if it has objects, with have buggy implemented unpickling feature. Developer, who works under webkit, would like to fix unpickling for his session. So, match better for developer to see the original exception instead of KeyError. --- This patch was made on Webware0.8b1. ---------------------------------------------------------------------- >Comment By: Stuart Donaldson (stuartd) Date: 2003-02-14 02:26 Message: Logged In: YES user_id=326269 Check out the revised Application2.diff I am uploading. This places the catch of the KeyError in isSessionIdProblematic() which is called specifically to see if a session ID is valid when processing dispatchRequest(). If it fails (typically because the sesion has expired) it marks the session as expired so the servlet can check and handle the situation. It has the advantage of cleaning up _SID_ cookies and fields on the request and going through handleInvalidSession which honors the setting 'IgnoreInvalidSession' Please advise if this solves your problem. Note it should be used in addition to the SessionFileStore.diff patch which raises the KeyError. ---------------------------------------------------------------------- Comment By: Oleg Noga (oleg_noga) Date: 2003-02-05 04:53 Message: Logged In: YES user_id=551440 So I've produced patches: for Application: Application.diff for SessionfileStore.diff in SessionFileStore.__getitem__: * close session file finally (seems like bug fix) in case of session unpicling error: 1. remove session file 2. call Application.handleException() 3. raise KeyError in Application.createSessionForTransaction: 1. catch KeyError 2. create new session if it was not loaded from store ---------------------------------------------------------------------- Comment By: Stuart Donaldson (stuartd) Date: 2003-02-05 00:05 Message: Logged In: YES user_id=326269 The original traceback is preserved if you just do "raise" without any arguments. It just re-raises the existing exception along with existing traceback information. From a consistency point of view, raising a KeyError for problems retrieving a session seems to be pretty common. While I think this specific case is not caught, there are other cases where a session stores __getitem__ throws a KeyError that does get caught. From a users point of view, shouldn't this just appear as a missing session file? From a developers view, you would want to see what the unpickling error was. If these two assumptions are correct, then perhaps a solution like this: - catch KeyError in Application.createSessionForTransaction, and treat it like there was no session. - have the decoding exception raise a key error as it does now, but also print out a the stack trace for a developer, possibly calling handleException() to log the exceptino as well. ---------------------------------------------------------------------- Comment By: Oleg Noga (oleg_noga) Date: 2003-02-04 14:11 Message: Logged In: YES user_id=551440 Here is KeyError traceback: Traceback (most recent call last): File ".\WebKit\Application.py", line 368, in dispatchRequest elif self.isSessionIdProblematic(request): File ".\WebKit\Application.py", line 466, in isSessionIdProblematic if (time()-request.session().lastAccessTime()) >= request.session().timeout(): File ".\WebKit\HTTPRequest.py", line 225, in session return self._transaction.session() File ".\WebKit\Transaction.py", line 67, in session self._session = self._application.createSessionForTransaction(self) File ".\WebKit\Application.py", line 889, in createSessionForTransaction session = self.session(sessId) File ".\WebKit\Application.py", line 725, in session return self._sessions[sessionId] File ".\WebKit\SessionDynamicStore.py", line 72, in __getitem__ self.MovetoMemory(key) File ".\WebKit\SessionDynamicStore.py", line 135, in MovetoMemory self._memoryStore[key] = self._fileStore[key] File ".\WebKit\SessionFileStore.py", line 55, in __getitem__ raise KeyError, key KeyError: 20030204232946- b46a22352890568b1a899c361d816933 Seems that KeyError have thrown out of awake-respond-sleep cycle (before it), so servlet can’t perform any gracefull recoveries. Maybe application must recover the same way as when session can’t be pickled? To remove unpickable session file, to create new session, and not to throw any exception at all? Any way, it usefull to see original exception report – in console/log, or in http exception report. --- I have raised exception like “raise e[0], e[1], e[2]” just to preserve original traceback. If original traceback has no helpful information, we can simple “raise <original exception instance>” The simplest patch is to remove try/except at all :) ---------------------------------------------------------------------- Comment By: Geoff Talvola (gtalvola) Date: 2003-02-04 10:19 Message: Logged In: YES user_id=88162 I'm not sure it's a good idea to re-raise the unpickling exception here. It may be better to _print_ the unpickling exception and possibly email it to the administrator, but still raise KeyError so that the application can treat this as a missing session and possibly recover more gracefully. ---------------------------------------------------------------------- Comment By: Geoff Talvola (gtalvola) Date: 2003-02-04 10:16 Message: Logged In: YES user_id=88162 Wouldn't this part of the patch be easier if we just said "raise"? raise with no arguments re-raises the latest exception. There's no need to rebuild it from sys.exc_info(). + e = sys.exc_info() + raise e[0], e[1], e[2] # raise the exception again, so developers can look on it ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=304866&aid=678129&group_id=4866 |
From: SourceForge.net <no...@so...> - 2003-02-14 13:49:00
|
Patches item #678129, was opened at 2003-01-31 16:08 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=304866&aid=678129&group_id=4866 Category: WebKit Group: None Status: Open Resolution: None Priority: 5 Submitted By: Oleg Noga (oleg_noga) Assigned to: Stuart Donaldson (stuartd) Summary: Report original exception for session unpickle error Initial Comment: The purpose of this patch is to provide the original session unpickle exception instead of KeyError exception. --- Since we have no corrupted sessions on the disk, the Session KeyError is still appears. KeyError appears if SessionFileStore can't unpickle session while loading it from disk. Session can't be unpickled only if it has objects, with have buggy implemented unpickling feature. Developer, who works under webkit, would like to fix unpickling for his session. So, match better for developer to see the original exception instead of KeyError. --- This patch was made on Webware0.8b1. ---------------------------------------------------------------------- >Comment By: Oleg Noga (oleg_noga) Date: 2003-02-14 15:56 Message: Logged In: YES user_id=551440 Aplication2.diff in couple with SessionFileStore.diff seems works fine. Request reports like session expired if session had unpickle problems. And we haveoriginal traceback in console. Thanks. ---------------------------------------------------------------------- Comment By: Stuart Donaldson (stuartd) Date: 2003-02-14 12:26 Message: Logged In: YES user_id=326269 Check out the revised Application2.diff I am uploading. This places the catch of the KeyError in isSessionIdProblematic() which is called specifically to see if a session ID is valid when processing dispatchRequest(). If it fails (typically because the sesion has expired) it marks the session as expired so the servlet can check and handle the situation. It has the advantage of cleaning up _SID_ cookies and fields on the request and going through handleInvalidSession which honors the setting 'IgnoreInvalidSession' Please advise if this solves your problem. Note it should be used in addition to the SessionFileStore.diff patch which raises the KeyError. ---------------------------------------------------------------------- Comment By: Oleg Noga (oleg_noga) Date: 2003-02-05 14:53 Message: Logged In: YES user_id=551440 So I've produced patches: for Application: Application.diff for SessionfileStore.diff in SessionFileStore.__getitem__: * close session file finally (seems like bug fix) in case of session unpicling error: 1. remove session file 2. call Application.handleException() 3. raise KeyError in Application.createSessionForTransaction: 1. catch KeyError 2. create new session if it was not loaded from store ---------------------------------------------------------------------- Comment By: Stuart Donaldson (stuartd) Date: 2003-02-05 10:05 Message: Logged In: YES user_id=326269 The original traceback is preserved if you just do "raise" without any arguments. It just re-raises the existing exception along with existing traceback information. From a consistency point of view, raising a KeyError for problems retrieving a session seems to be pretty common. While I think this specific case is not caught, there are other cases where a session stores __getitem__ throws a KeyError that does get caught. From a users point of view, shouldn't this just appear as a missing session file? From a developers view, you would want to see what the unpickling error was. If these two assumptions are correct, then perhaps a solution like this: - catch KeyError in Application.createSessionForTransaction, and treat it like there was no session. - have the decoding exception raise a key error as it does now, but also print out a the stack trace for a developer, possibly calling handleException() to log the exceptino as well. ---------------------------------------------------------------------- Comment By: Oleg Noga (oleg_noga) Date: 2003-02-05 00:11 Message: Logged In: YES user_id=551440 Here is KeyError traceback: Traceback (most recent call last): File ".\WebKit\Application.py", line 368, in dispatchRequest elif self.isSessionIdProblematic(request): File ".\WebKit\Application.py", line 466, in isSessionIdProblematic if (time()-request.session().lastAccessTime()) >= request.session().timeout(): File ".\WebKit\HTTPRequest.py", line 225, in session return self._transaction.session() File ".\WebKit\Transaction.py", line 67, in session self._session = self._application.createSessionForTransaction(self) File ".\WebKit\Application.py", line 889, in createSessionForTransaction session = self.session(sessId) File ".\WebKit\Application.py", line 725, in session return self._sessions[sessionId] File ".\WebKit\SessionDynamicStore.py", line 72, in __getitem__ self.MovetoMemory(key) File ".\WebKit\SessionDynamicStore.py", line 135, in MovetoMemory self._memoryStore[key] = self._fileStore[key] File ".\WebKit\SessionFileStore.py", line 55, in __getitem__ raise KeyError, key KeyError: 20030204232946- b46a22352890568b1a899c361d816933 Seems that KeyError have thrown out of awake-respond-sleep cycle (before it), so servlet can’t perform any gracefull recoveries. Maybe application must recover the same way as when session can’t be pickled? To remove unpickable session file, to create new session, and not to throw any exception at all? Any way, it usefull to see original exception report – in console/log, or in http exception report. --- I have raised exception like “raise e[0], e[1], e[2]” just to preserve original traceback. If original traceback has no helpful information, we can simple “raise <original exception instance>” The simplest patch is to remove try/except at all :) ---------------------------------------------------------------------- Comment By: Geoff Talvola (gtalvola) Date: 2003-02-04 20:19 Message: Logged In: YES user_id=88162 I'm not sure it's a good idea to re-raise the unpickling exception here. It may be better to _print_ the unpickling exception and possibly email it to the administrator, but still raise KeyError so that the application can treat this as a missing session and possibly recover more gracefully. ---------------------------------------------------------------------- Comment By: Geoff Talvola (gtalvola) Date: 2003-02-04 20:16 Message: Logged In: YES user_id=88162 Wouldn't this part of the patch be easier if we just said "raise"? raise with no arguments re-raises the latest exception. There's no need to rebuild it from sys.exc_info(). + e = sys.exc_info() + raise e[0], e[1], e[2] # raise the exception again, so developers can look on it ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=304866&aid=678129&group_id=4866 |
From: SourceForge.net <no...@so...> - 2003-02-18 05:41:31
|
Patches item #678129, was opened at 2003-01-31 06:08 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=304866&aid=678129&group_id=4866 Category: WebKit Group: None >Status: Closed Resolution: None Priority: 5 Submitted By: Oleg Noga (oleg_noga) Assigned to: Stuart Donaldson (stuartd) Summary: Report original exception for session unpickle error Initial Comment: The purpose of this patch is to provide the original session unpickle exception instead of KeyError exception. --- Since we have no corrupted sessions on the disk, the Session KeyError is still appears. KeyError appears if SessionFileStore can't unpickle session while loading it from disk. Session can't be unpickled only if it has objects, with have buggy implemented unpickling feature. Developer, who works under webkit, would like to fix unpickling for his session. So, match better for developer to see the original exception instead of KeyError. --- This patch was made on Webware0.8b1. ---------------------------------------------------------------------- >Comment By: Stuart Donaldson (stuartd) Date: 2003-02-17 21:49 Message: Logged In: YES user_id=326269 Committed fix to CVS. ---------------------------------------------------------------------- Comment By: Oleg Noga (oleg_noga) Date: 2003-02-14 05:56 Message: Logged In: YES user_id=551440 Aplication2.diff in couple with SessionFileStore.diff seems works fine. Request reports like session expired if session had unpickle problems. And we haveoriginal traceback in console. Thanks. ---------------------------------------------------------------------- Comment By: Stuart Donaldson (stuartd) Date: 2003-02-14 02:26 Message: Logged In: YES user_id=326269 Check out the revised Application2.diff I am uploading. This places the catch of the KeyError in isSessionIdProblematic() which is called specifically to see if a session ID is valid when processing dispatchRequest(). If it fails (typically because the sesion has expired) it marks the session as expired so the servlet can check and handle the situation. It has the advantage of cleaning up _SID_ cookies and fields on the request and going through handleInvalidSession which honors the setting 'IgnoreInvalidSession' Please advise if this solves your problem. Note it should be used in addition to the SessionFileStore.diff patch which raises the KeyError. ---------------------------------------------------------------------- Comment By: Oleg Noga (oleg_noga) Date: 2003-02-05 04:53 Message: Logged In: YES user_id=551440 So I've produced patches: for Application: Application.diff for SessionfileStore.diff in SessionFileStore.__getitem__: * close session file finally (seems like bug fix) in case of session unpicling error: 1. remove session file 2. call Application.handleException() 3. raise KeyError in Application.createSessionForTransaction: 1. catch KeyError 2. create new session if it was not loaded from store ---------------------------------------------------------------------- Comment By: Stuart Donaldson (stuartd) Date: 2003-02-05 00:05 Message: Logged In: YES user_id=326269 The original traceback is preserved if you just do "raise" without any arguments. It just re-raises the existing exception along with existing traceback information. From a consistency point of view, raising a KeyError for problems retrieving a session seems to be pretty common. While I think this specific case is not caught, there are other cases where a session stores __getitem__ throws a KeyError that does get caught. From a users point of view, shouldn't this just appear as a missing session file? From a developers view, you would want to see what the unpickling error was. If these two assumptions are correct, then perhaps a solution like this: - catch KeyError in Application.createSessionForTransaction, and treat it like there was no session. - have the decoding exception raise a key error as it does now, but also print out a the stack trace for a developer, possibly calling handleException() to log the exceptino as well. ---------------------------------------------------------------------- Comment By: Oleg Noga (oleg_noga) Date: 2003-02-04 14:11 Message: Logged In: YES user_id=551440 Here is KeyError traceback: Traceback (most recent call last): File ".\WebKit\Application.py", line 368, in dispatchRequest elif self.isSessionIdProblematic(request): File ".\WebKit\Application.py", line 466, in isSessionIdProblematic if (time()-request.session().lastAccessTime()) >= request.session().timeout(): File ".\WebKit\HTTPRequest.py", line 225, in session return self._transaction.session() File ".\WebKit\Transaction.py", line 67, in session self._session = self._application.createSessionForTransaction(self) File ".\WebKit\Application.py", line 889, in createSessionForTransaction session = self.session(sessId) File ".\WebKit\Application.py", line 725, in session return self._sessions[sessionId] File ".\WebKit\SessionDynamicStore.py", line 72, in __getitem__ self.MovetoMemory(key) File ".\WebKit\SessionDynamicStore.py", line 135, in MovetoMemory self._memoryStore[key] = self._fileStore[key] File ".\WebKit\SessionFileStore.py", line 55, in __getitem__ raise KeyError, key KeyError: 20030204232946- b46a22352890568b1a899c361d816933 Seems that KeyError have thrown out of awake-respond-sleep cycle (before it), so servlet can’t perform any gracefull recoveries. Maybe application must recover the same way as when session can’t be pickled? To remove unpickable session file, to create new session, and not to throw any exception at all? Any way, it usefull to see original exception report – in console/log, or in http exception report. --- I have raised exception like “raise e[0], e[1], e[2]” just to preserve original traceback. If original traceback has no helpful information, we can simple “raise <original exception instance>” The simplest patch is to remove try/except at all :) ---------------------------------------------------------------------- Comment By: Geoff Talvola (gtalvola) Date: 2003-02-04 10:19 Message: Logged In: YES user_id=88162 I'm not sure it's a good idea to re-raise the unpickling exception here. It may be better to _print_ the unpickling exception and possibly email it to the administrator, but still raise KeyError so that the application can treat this as a missing session and possibly recover more gracefully. ---------------------------------------------------------------------- Comment By: Geoff Talvola (gtalvola) Date: 2003-02-04 10:16 Message: Logged In: YES user_id=88162 Wouldn't this part of the patch be easier if we just said "raise"? raise with no arguments re-raises the latest exception. There's no need to rebuild it from sys.exc_info(). + e = sys.exc_info() + raise e[0], e[1], e[2] # raise the exception again, so developers can look on it ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=304866&aid=678129&group_id=4866 |