[rules-dev] KnowlegeAgent Tests
Mark Proctor
mproctor at codehaus.org
Sat Dec 4 13:11:55 EST 2010
I have done an initial commit in which I improved KnowledgeAgentTest,
starting on the other test classes now. I made a jira for it:
https://jira.jboss.org/browse/JBRULES-2817
If you are doing anything over weekend, feel free to review/improve or
move over the other tests. Also Creating a standalone unit test that is
purely for ResourceScannerImpl would be a nice thing. That it tests
purely the scan method, using mocks (mockito maybe?) to check the
propagations and that it tests the interval scanners and confgurations
there, meaning they don't need to be part of any other tests.
We also need to move all of these deamon service threads to use the
standardised Thread management api that edson did.
Mark
On 04/12/2010 15:27, Mark Proctor wrote:
> 1) the scanner's time doesn't really need to be part of the unit
> tests, as that can be tested separately and we know it'll work. So we
> can just call scan() instead. See code in 2)
>
> 2) I've also moved it to use a CountDownLatch on a
> afterChangeSetApplied event.
> private void scan(KnowledgeAgent kagent) {
> // Calls the Resource Scanner and sets up a listener and a
> latch so we can wait until it's finished processing, instead of using
> timers
> final CountDownLatch latch = new CountDownLatch( 1 );
>
> KnowledgeAgentEventListener l = new
> KnowledgeAgentEventListener() {
> ...
>
> public void
> afterChangeSetApplied(AfterChangeSetAppliedEvent event) {
> latch.countDown();
> }
> };
>
> kagent.addEventListener( l );
>
> this.scanner.scan();
>
> try {
> latch.await( 10, TimeUnit.SECONDS );
> } catch ( InterruptedException e ) {
> throw new RuntimeException( "Unable to wait for latch
> countdown", e);
> }
>
> if ( latch.getCount() > 0 ) {
> throw new RuntimeException( "Event for KnowlegeBase
> update, due to scan, was never received" );
> }
>
> kagent.removeEventListener( l );
> }
>
> 3) All file deletes go through the FileManager. I always do multiple
> attempts at deleting a file and throw an exception if it was not
> successfuly
> public boolean deleteFile(File file) {
> // This will attempt to delete a file 5 times, calling GC and
> Sleep between each iteration
> // Sometimes windows takes a while to release a lock on a file
> if ( !file.delete() ) {
> int count = 0;
> while ( !file.delete() && count++ < 5 ) {
> System.gc();
> try {
> Thread.sleep( 250 );
> } catch ( InterruptedException e ) {
> throw new RuntimeException( "This should never
> happen" );
> }
> }
> }
>
> return !file.exists();
>
> }
>
> 3) File writting always waits 1000ms when the file already exists
> (http and linux round to nearest second) so it ensures lastmodified is
> always atleast 1000ms after lastread. See code in 4)
>
> 4) All file writting goes via the FileManager where I know attempt to
> write any file 5 times, calling GC and wait between each iteration.
> public void write(File f,
> String text) throws IOException {
> if ( f.exists() ) {
> // we want to make sure there is a time difference for
> lastModified and lastRead checks as Linux and http often round to seconds
> //
> http://saloon.javaranch.com/cgi-bin/ubb/ultimatebb.cgi?ubb=get_topic&f=1&t=019789
> try {
> Thread.sleep( 1000 );
> } catch ( Exception e ) {
> throw new RuntimeException( "Unable to sleep" );
> }
> }
>
> // Attempt to write the file
> BufferedWriter output = new BufferedWriter( new FileWriter( f ) );
> output.write( text );
> output.close();
>
> // Now check the file was written and re-attempt if it was not
> // Need to do this for testing, to ensure the texts are read
> the same way, otherwise sometimes you get tail \n sometimes you don't
> String t1 = StringUtils.toString( new StringReader( text ) );
>
> int count = 0;
> while ( !t1.equals( StringUtils.toString( new BufferedReader(
> new FileReader( f ) ) ) ) && count < 5 ) {
> // The file failed to write, try 5 times, calling GC and
> sleep between each iteration
> // Sometimes windows takes a while to release a lock on a
> file
> System.gc();
> try {
> Thread.sleep( 250 );
> } catch ( InterruptedException e ) {
> throw new RuntimeException( "This should never happen" );
> }
> output = new BufferedWriter( new FileWriter( f ) );
> output.write( text );
> output.close();
> count++;
> }
>
> if ( count == 5 ) {
> throw new IOException( "Unable to write to file:" +
> f.getCanonicalPath() );
> }
> }
>
> So far between those things the code is now more robust, it's just
> taking time to move it all across :)
>
> We should probably make separate unit tests specifically for
> ResourceScannerImpl, on it's own separate from the rest of hte stack.
>
> Mark
> On 04/12/2010 13:26, Esteban Aliverti wrote:
>> Mark, let me know if you need some help since this is one of the task
>> in my (almost eternal) TODO list. You can take a look
>> at KnowledgeAgentEventListenerTest.java. Using
>> KnowledgeAgentEventListener, you can be notified when the rule base
>> is recreated and there is no need to wait for x seconds anymore.
>> Take a look at the waitUntilChangeSetApplied() method there.
>>
>> Best,
>>
>> XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
>>
>> Esteban Aliverti
>> - Developer @ http://www.plugtree.com <http://www.plugtree.com>
>> - Blog @ http://ilesteban.wordpress.com
>>
>>
>> On Sat, Dec 4, 2010 at 6:38 AM, Mark Proctor <mproctor at codehaus.org
>> <mailto:mproctor at codehaus.org>> wrote:
>>
>> The KnowlegeAgent tests have been fragile for a while, related to
>> "wait"
>> code and file issues, particularly on windows. Something has changed
>> recently and now they aren't working on the linux hudson server
>> either.
>>
>> So I'm now in the process of refactoring the tests to make them more
>> robust, and they will hopefully run faster too, as I'll use call
>> backs
>> when something has finished instead of waiting for X seconds in
>> the hope
>> that something has finished.
>>
>> Mark
>>
>> _______________________________________________
>> rules-dev mailing list
>> rules-dev at lists.jboss.org <mailto:rules-dev at lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/rules-dev
>>
>>
>>
>> _______________________________________________
>> rules-dev mailing list
>> rules-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/rules-dev
>
>
> _______________________________________________
> rules-dev mailing list
> rules-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-dev/attachments/20101204/ee0065ce/attachment.html
More information about the rules-dev
mailing list