DO NOT REPLY [Bug 5829] New: - StandardManager needs to cope with sessions throwing exception in read/write

[bu...@apache.org]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5829>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5829

StandardManager needs to cope with sessions throwing exception in read/write

           Summary: StandardManager needs to cope with sessions throwing
                    exception in read/write
           Product: Tomcat 4
           Version: 4.0.1 Final
          Platform: Other
        OS/Version: Other
            Status: NEW
          Severity: Major
          Priority: Other
         Component: Catalina
        AssignedTo: tomcat-dev@jakarta.apache.org
        ReportedBy: dsl@ts.com


In StandardManager, where all sessions are written into the same file
(SESSIONS.ser) during shutdown..

If an attribute claims to be serializable but yet throws an exception when you
attempt to do so (for example a HashMap containing some non-serializable values)
then this messes things up.  The object output stream is then in a messed up
state for a read; eg. the attribute which is a HashMap will read beyond the end
of the data that it wrote in attempting to repopulate its value.., this then
effectively makes the file garbage for the following sessions that are written.
ie. if one session breaks it, the rest of the sessions will fail..

Furthermore, if you try to reload some attribute for which an IOException
is thrown during the reloading (eg. Externalizable attributes with
protected/private constructors) then the resulting exception also halts the
reload of the remaining sessions in this context..

Thus, each session needs to store its state in a separate file, and the write
and read of each session needs to be wrapped up in some better exception
catching.  

I've a patch for this..

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>