[jboss-dev-forums] [Design the new POJO MicroContainer] - VFS HDScanner test

[mstruk]

The first reason this test is failing is because the default mode for vfszip is asynchronous lock reaping. That means the archive remains locked for 5 seconds after it was last used.

Also, this test forces archive reuse (and consequently a file lock) continuously in two ways:


a) MockProfileServiceRepository creates a new VFSContext on every deployment scan:

  |    VirtualFile deployDir = VFS.getRoot(applicationDir.toURI());
  | 
instead of holding on to one instance of root VirtualFile, thereby forcing reinitialization of arhive metadata on every scan, which causes a file lock to be acquired and also slows things down.


b) The test itself forces redeploy by continuously changing lastModified - again causing a file lock to be acquired.

Every time a file lock is acquired it takes 5 seconds (after no longer needed - which in most cases is a split second after it was acquired) for it to clear.



Possible solutions are:

1) put the following at the beginning of testDeleteWhileScanning() to activate synchronous lock release (access to archive entries becomes a bit slower).

  |    System.setProperty("jboss.vfs.forceNoReaper", "true");
  | 

2) Stop the scanner first, wait for 5 seconds and then do a delete (but I guess the whole purpose of the test is to do a delete while the scanner is still active)

3) Rewrite MockProfileServiceRepository to reuse deployDir VirtualFile.  Tweak scan, and wait periods to bigger values + try archive.delete() multiple times - to catch a window when archive is unlocked.


  |    VirtualFile deployDir = getDeploymentRoot(applicationDir.toURI());
  | 
  | ...
  | 
  |    private VirtualFile deploymentRoot;
  | 
  |    protected VirtualFile getDeploymentRoot(URI uri) throws IOException
  |    {
  |       if (deploymentRoot == null)
  |       {
  |          deploymentRoot = VFS.getRoot(uri);
  |       }
  |       return deploymentRoot;
  |    }
  | 

This approach relies on correct interplay of lastModified changes, and scanner and reaper periods which are internally hardcoded and can possibly change without notice - it's not a reliable approach.

I opted for approach one. It's commited.


Cheers,

- marko

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4160492#4160492

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4160492