Corrupting the files is not exactly what we are looking for. If you have currupted data files, you need will need to restore you data from backup. What we want to test is:
(1) that we are correctly flushing out our output to disk when we commit a transaction. All message are FULLY written to disk by the time the commit is issued. (2) that we do not attempt to recover messages from transaction that did not commit. (3) that we can deal with garbage at the end of out transaction logs. So would adding garbage at the end of a message log files or adding garbage message files simulate(2,3)?? Would HARD Killing the server after a commit test (2)??? How would we implement the HARD kill (JNI)?? Any other tests/ideas?? Regards, Hiram >From: Jason Dillon <[EMAIL PROTECTED]> >To: Loren Rosen <[EMAIL PROTECTED]> >CC: Hiram Chirino <[EMAIL PROTECTED]>, ><[EMAIL PROTECTED]> >Subject: Re: [JBoss-dev] jbossmq: persistence implementation questions >Date: Thu, 15 Nov 2001 15:07:23 -0800 (PST) > > > I'll look through the code more closely. But recovery is testable. What > > you have to do is create some corrupt data files (probably by using a > > byte-level editor to munge some existing data files). Then you need > > some scripts to start up the server with those files -- which doesn't > > fit so well with a pure-Java Junit-based test suite. (You could also > > create the files by making versions of the server which quit at > > various awkward places.) What this won't test so easily is recovery > > from failures during recovery. > >How about using JUnit to corrupt some files, then startup the component >which reads those files and test that is throws the proper exceptions? > >--jason > _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
