[jboss-dev-forums] [Design the new POJO MicroContainer] - Re: Performance - Update

mstruk do-not-reply at jboss.com
Sat Aug 2 16:49:04 EDT 2008


About 'file.getChild() -> getChildren() madness' ...

getChildren() is only getting called when no handler is found in handler's childCache for the given name. But that does happen a lot (WEB-INF probing ...) 

The reason getChildren() is being called is because of the specifics of how .vfslink mechanism works.

** How links mechanism works **

FileSystemContext supports a linking mechanism. You create a properties file and put it in a directory that's somewhere under a FileSystemContext root.
This properties file has to conform to a naming convention - something.vfslink.properties. The first part of the name ('something') is irrelevant - it plays no role.

An example content of this file:

  | vfs.link.name=extras
  | vfs.link.name.0=extra1.jar
  | vfs.link.target.0=${jboss.server.home.url}extra/extra1.jar
  | vfs.link.name.1=extra2.jar
  | vfs.link.target.1=${jboss.server.home.url}extra/extra2.jar
  | 

Let's say this file is inside 'deploy' directory. This would create a LinkHandler named 'extras' under 'deploy' FileHandler. And this LinkHandler will contain two children - 'extra1.jar' and 'extra2.jar'.

The result of placing this file are therefore the following additional virtual files:

  | deploy/extras
  | deploy/extras/extra1.jar
  | deploy/extras/extra2.jar
  | 


Detecting if LinkHandler (the virtual directory containing links) was removed

  Link handler can be removed by a) removing .vfslink.properties file that caused its creation, b) changing vfs.link.name property of this same file.


Detecting if link was added

  Link handler can be added by a) adding a new .vfslink.properties file, b) changing vfs.link.name property of existing .vfslink.properties file.


The main problem of this design is that there is no one-to-one mapping between LinkHandler name ('deploy/extras' in our example), and the properties file that created it ('something.vfslink.properties' in our example). If we want to determine the current configured state of links we _have to_ find all .vfslink.properties files in parent directory ('deploy' in our case), and process them. That's why getChildren() gets called. We could for example just check the file from which the link was created (LinkHandler contains that info) but that's not enough. This file may have disappeared due to being renamed into something else, which shouldn't affect links configuration - nothing substantial changed.

If we want to optimize this, we need to change the implementation. The simplest change would be to cancel vfs.link.name property and tie LinkHandler name to the first component of .vfslink.properties file - in our example it would have to be called extras.vfslink.properties.


This little change is enough to now be able to avoid having to call getChildren() on the parent in order to process all .vfslink.properties files in parent directory.

I've commited a fix along these lines.

- marko



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

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



More information about the jboss-dev-forums mailing list